Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 09 8月, 2008 1 次提交
    • A
      [NFSD] uninline nfsd4_op_name() · f1c7f79b
      由 Adrian Bunk 提交于 
      There doesn't seem to be a compelling reason why nfsd4_op_name() is
marked as "inline":

It's only used in a dprintk(), and as long as it has only one caller
non-ancient gcc versions anyway inline it automatically.

This patch fixes the following compile error with gcc 3.4:

  ...
    CC      fs/nfsd/nfs4proc.o
  nfs4proc.c: In function `nfsd4_proc_compound':
  nfs4proc.c:854: sorry, unimplemented: inlining failed in call to
  nfs4proc.c:897: sorry, unimplemented: called from here
  make[3]: *** [fs/nfsd/nfs4proc.o] Error 1
Reported-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
[ Also made it "const char *"  - Linus]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f1c7f79b
  3. 03 7月, 2008 1 次提交
  5. 24 6月, 2008 2 次提交
  7. 19 4月, 2008 1 次提交
  9. 02 2月, 2008 1 次提交
    • F
      nfsd: Allow AIX client to read dir containing mountpoints · 406a7ea9
      由 Frank Filz 提交于 
      This patch addresses a compatibility issue with a Linux NFS server and
AIX NFS client.

I have exported /export as fsid=0 with sec=krb5:krb5i
I have mount --bind /home onto /export/home
I have exported /export/home with sec=krb5i

The AIX client mounts / -o sec=krb5:krb5i onto /mnt

If I do an ls /mnt, the AIX client gets a permission error. Looking at
the network traceIwe see a READDIR looking for attributes
FATTR4_RDATTR_ERROR and FATTR4_MOUNTED_ON_FILEID. The response gives a
NFS4ERR_WRONGSEC which the AIX client is not expecting.

Since the AIX client is only asking for an attribute that is an
attribute of the parent file system (pseudo root in my example), it
seems reasonable that there should not be an error.

In discussing this issue with Bruce Fields, I initially proposed
ignoring the error in nfsd4_encode_dirent_fattr() if all that was being
asked for was FATTR4_RDATTR_ERROR and FATTR4_MOUNTED_ON_FILEID, however,
Bruce suggested that we avoid calling cross_mnt() if only these
attributes are requested.

The following patch implements bypassing cross_mnt() if only
FATTR4_RDATTR_ERROR and FATTR4_MOUNTED_ON_FILEID are called. Since there
is some complexity in the code in nfsd4_encode_fattr(), I didn't want to
duplicate code (and introduce a maintenance nightmare), so I added a
parameter to nfsd4_encode_fattr() that indicates whether it should
ignore cross mounts and simply fill in the attribute using the passed in
dentry as opposed to it's parent.
Signed-off-by: NFrank Filz <ffilzlnx@us.ibm.com>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      406a7ea9
  11. 10 10月, 2007 1 次提交
  13. 01 8月, 2007 1 次提交
  15. 18 7月, 2007 2 次提交
  17. 14 12月, 2006 9 次提交
  19. 09 11月, 2006 2 次提交
  21. 21 10月, 2006 4 次提交
  23. 17 10月, 2006 2 次提交
    • J
      [PATCH] knfsd: nfsd4: fix open permission checking · 9801d8a3
      由 J. Bruce Fields 提交于 
      We weren't actually checking for SHARE_ACCESS_WRITE, with the result that the
owner could open a non-writeable file for write!

Continue to allow DENY_WRITE only with write access.

Thanks to Jim Rees for reporting the bug.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9801d8a3
    • J
      [PATCH] knfsd: nfsd4: fix owner-override on open · dc730e17
      由 J. Bruce Fields 提交于 
      If a client creates a file using an open which sets the mode to 000, or if a
chmod changes permissions after a file is opened, then situations may arise
where an NFS client knows that some IO is permitted (because a process holds
the file open), but the NFS server does not (because it doesn't know about the
open, and only sees that the IO conflicts with the current mode of the file).

As a hack to solve this problem, NFS servers normally allow the owner to
override permissions on IO.  The client can still enforce correct
permissions-checking on open by performing an explicit access check.

In NFSv4 the client can rely on the explicit on-the-wire open instead of an
access check.

Therefore we should not be allowing the owner to override permissions on an
over-the-wire open!

However, we should still allow the owner to override permissions in the case
where the client is claiming an open that it already made either before a
reboot, or while it was holding a delegation.

Thanks to Jim Rees for reporting the bug.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dc730e17
  25. 04 10月, 2006 2 次提交
  27. 02 10月, 2006 1 次提交
  29. 11 7月, 2006 1 次提交
  31. 11 4月, 2006 2 次提交
  33. 08 2月, 2006 1 次提交
  35. 19 1月, 2006 5 次提交
  37. 13 9月, 2005 1 次提交