Skip to content

L
linux-davinci
An error occurred fetching the project authors.
Switch branch/tag
  1. 15 Feb, 2008 1 commit
  3. 01 Feb, 2008 2 commits
    • Frank Filz's avatar
      nfsd: Allow AIX client to read dir containing mountpoints · 406a7ea9
      Frank Filz authored 
      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: default avatarFrank Filz <ffilzlnx@us.ibm.com>
Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      406a7ea9
    • J. Bruce Fields's avatar
      nfsd: Fix handling of negative lengths in read_buf() · ca2a05aa
      J. Bruce Fields authored 
      The length "nbytes" passed into read_buf should never be negative, but
we check only for too-large values of "nbytes", not for too-small
values.  Make nbytes unsigned, so it's clear that the former tests are
sufficient.  (Despite this read_buf() currently correctly returns an xdr
error in the case of a negative length, thanks to an unsigned
comparison with size_of() and bounds-checking in kmalloc().  This seems
very fragile, though.)
Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      ca2a05aa
  5. 09 Oct, 2007 3 commits
  7. 26 Jul, 2007 1 commit
  9. 17 Jul, 2007 3 commits
  11. 08 May, 2007 1 commit
  13. 16 Feb, 2007 3 commits
  15. 14 Feb, 2007 1 commit
  17. 26 Jan, 2007 1 commit
    • NeilBrown's avatar
      [PATCH] knfsd: Fix type mismatch with filldir_t used by nfsd · a0ad13ef
      NeilBrown authored 
      nfsd defines a type 'encode_dent_fn' which is much like 'filldir_t' except
that the first pointer is 'struct readdir_cd *' rather than 'void *'.  It
then casts encode_dent_fn points to 'filldir_t' as needed.  This hides any
other type mismatches between the two such as the fact that the 'ino' arg
recently changed from ino_t to u64.

So: get rid of 'encode_dent_fn', get rid of the cast of the function type,
change the first arg of various functions from 'struct readdir_cd *' to
'void *', and live with the fact that we have a little less type checking
on the calling of these functions now.  Less internal (to nfsd) checking
offset by more external checking, which is more important.

Thanks to Gabriel Paubert <paubert@iram.es> for discovering this and
providing an initial patch.
Signed-off-by: default avatarGabriel Paubert <paubert@iram.es>
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a0ad13ef
  19. 13 Dec, 2006 1 commit
  21. 20 Oct, 2006 4 commits
  23. 04 Oct, 2006 5 commits
  25. 03 Oct, 2006 1 commit
  27. 23 Jun, 2006 1 commit
  29. 11 Apr, 2006 3 commits
  31. 24 Mar, 2006 1 commit
  33. 19 Jan, 2006 2 commits
  35. 07 Nov, 2005 1 commit
  37. 08 Jul, 2005 3 commits
    • NeilBrown's avatar
      [PATCH] nfsd4: fix fh_expire_type · e34ac862
      NeilBrown authored 
      After discussion at the recent NFSv4 bake-a-thon, I realized that my
assumption that NFS4_FH_PERSISTENT required filehandles to persist was a
misreading of the spec.  This also fixes an interoperability problem with the
Solaris client.
Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: default avatarNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e34ac862
    • NeilBrown's avatar
      [PATCH] nfsd4: seqid comments · 7fb64cee
      NeilBrown authored 
      Add some comments on the use of so_seqid, in an attempt to avoid some of the
confusion outlined in the previous patch....
Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: default avatarNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7fb64cee
    • NeilBrown's avatar
      [PATCH] nfsd4: fix open_reclaim seqid · bd9aac52
      NeilBrown authored 
      The sequence number we store in the sequence id is the last one we received
from the client.  So on the next operation we'll check that the client gives
us the next higher number.

We increment sequence id's at the last moment, in encode, so that we're sure
of knowing the right error return.  (The decision to increment the sequence id
depends on the exact error returned.)

However on the *first* use of a sequence number, if we set the sequence number
to the one received from the client and then let the increment happen on
encode, we'll be left with a sequence number one to high.

For that reason, ENCODE_SEQID_OP_TAIL only increments the sequence id on
*confirmed* stateowners.

This creates a problem for open reclaims, which are confirmed on first use.
Therefore the open reclaim code, as a special exception, *decrements* the
sequence id, cancelling out the undesired increment on encode.  But this
prevents the sequence id from ever being incremented in the case where
multiple reclaims are sent with the same openowner.  Yuch!

We could add another exception to the open reclaim code, decrementing the
sequence id only if this is the first use of the open owner.

But it's simpler by far to modify the meaning of the op_seqid field: instead
of representing the previous value sent by the client, we take op_seqid, after
encoding, to represent the *next* sequence id that we expect from the client.
This eliminates the need for special-case handling of the first use of a
stateowner.
Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: default avatarNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      bd9aac52
  39. 24 Jun, 2005 2 commits