05 Jan, 2011

4 commits


31 Jul, 2010

1 commit


30 Jul, 2010

1 commit

  • Fixes at least one real minor bug: the nfs4 recovery dir sysctl
    would not return its status properly.

    Also I finished Al's 1e41568d7378d ("Take ima_path_check() in nfsd
    past dentry_open() in nfsd_open()") commit, it moved the IMA
    code, but left the old path initializer in there.

    The rest is just dead code removed I think, although I was not
    fully sure about the "is_borc" stuff. Some more review
    would be still good.

    Found by gcc 4.6's new warnings.

    Signed-off-by: Andi Kleen
    Cc: Al Viro
    Cc: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: J. Bruce Fields

    Andi Kleen
     

16 Dec, 2009

1 commit


15 Dec, 2009

2 commits


14 Nov, 2009

1 commit


29 Sep, 2009

1 commit

  • We really shouldn't hit this case at all, and forthcoming kernel and
    nfs-utils changes should eliminate this case; if it does happen,
    consider it a bug rather than reporting an error that doesn't really
    make sense for the operation (since there's no reason for a server to be
    accepting v4 traffic yet have no root filehandle).

    Also move some exp_pseudoroot code into a helper function while we're
    here.

    Signed-off-by: J. Bruce Fields

    J. Bruce Fields
     

16 Jun, 2009

1 commit

  • kill off obscure macro 'PROC' of NFSv2&3 in order to make the code more clear.

    Among other things, this makes it simpler to grep for callers of these
    functions--something which has frequently caused confusion among nfs
    developers.

    Signed-off-by: Yu Zhiguo
    Signed-off-by: J. Bruce Fields

    Yu Zhiguo
     

19 Mar, 2009

1 commit

  • If a filesystem being written to via NFS returns a short write count
    (as opposed to an error) to nfsd, nfsd treats that as a success for
    the entire write, rather than the short count that actually succeeded.

    For example, given a 8192 byte write, if the underlying filesystem
    only writes 4096 bytes, nfsd will ack back to the nfs client that all
    8192 bytes were written. The nfs client does have retry logic for
    short writes, but this is never called as the client is told the
    complete write succeeded.

    There are probably other ways it could happen, but in my case it
    happened with a fuse (filesystem in userspace) filesystem which can
    rather easily have a partial write.

    Here is a patch to properly return the short write count to the
    client.

    Signed-off-by: David Shaw
    Signed-off-by: J. Bruce Fields

    David Shaw
     

08 Jan, 2009

1 commit


30 Sep, 2008

1 commit

  • RFC 2623 section 2.3.2 permits the server to bypass gss authentication
    checks for certain operations that a client may perform when mounting.
    In the case of a client that doesn't have some form of credentials
    available to it on boot, this allows it to perform the mount unattended.
    (Presumably real file access won't be needed until a user with
    credentials logs in.)

    Being slightly more lenient allows lots of old clients to access
    krb5-only exports, with the only loss being a small amount of
    information leaked about the root directory of the export.

    This affects only v2 and v3; v4 still requires authentication for all
    access.

    Thanks to Peter Staubach testing against a Solaris client, which
    suggesting addition of v3 getattr, to the list, and to Trond for noting
    that doing so exposes no additional information.

    Signed-off-by: J. Bruce Fields
    Cc: Peter Staubach
    Cc: Trond Myklebust

    J. Bruce Fields
     

24 Jun, 2008

2 commits

  • Rename nfsd_permission() specific MAY_* flags to NFSD_MAY_* to make it
    clear, that these are not used outside nfsd, and to avoid name and
    number space conflicts with the VFS.

    [comment from hch: rename MAY_READ, MAY_WRITE and MAY_EXEC as well]

    Signed-off-by: Miklos Szeredi
    Signed-off-by: J. Bruce Fields

    Miklos Szeredi
     
  • OCFS2 can return -ERESTARTSYS from write requests (and possibly
    elsewhere) if there is a signal pending.

    If nfsd is shutdown (by sending a signal to each thread) while there
    is still an IO load from the client, each thread could handle one last
    request with a signal pending. This can result in -ERESTARTSYS
    which is not understood by nfserrno() and so is reflected back to
    the client as nfserr_io aka -EIO. This is wrong.

    Instead, interpret ERESTARTSYS to mean "try again later" by returning
    nfserr_jukebox. The client will resend and - if the server is
    restarted - the write will (hopefully) be successful and everyone will
    be happy.

    The symptom that I narrowed down to this was:
    copy a large file via NFS to an OCFS2 filesystem, and restart
    the nfs server during the copy.
    The 'cp' might get an -EIO, and the file will be corrupted -
    presumably holes in the middle where writes appeared to fail.

    Signed-off-by: Neil Brown
    Signed-off-by: J. Bruce Fields

    NeilBrown
     

15 Feb, 2008

1 commit

  • I'm embedding struct path into struct svc_export.

    [akpm@linux-foundation.org: coding-style fixes]
    [ezk@cs.sunysb.edu: NFSD: fix wrong mnt_writer count in rename]
    Signed-off-by: Jan Blunck
    Acked-by: J. Bruce Fields
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Cc: "J. Bruce Fields"
    Cc: Neil Brown
    Cc: Trond Myklebust
    Signed-off-by: Erez Zadok
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Blunck
     

18 Jul, 2007

1 commit

  • Allow readonly access to vary depending on the pseudoflavor, using the flag
    passed with each pseudoflavor in the export downcall. The rest of the flags
    are ignored for now, though some day we might also allow id squashing to vary
    based on the flavor.

    Signed-off-by: "J. Bruce Fields"
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    J. Bruce Fields
     

10 May, 2007

1 commit

  • When the kernel calls svc_reserve to downsize the expected size of an RPC
    reply, it fails to account for the possibility of a checksum at the end of
    the packet. If a client mounts a NFSv2/3 with sec=krb5i/p, and does I/O
    then you'll generally see messages similar to this in the server's ring
    buffer:

    RPC request reserved 164 but used 208

    While I was never able to verify it, I suspect that this problem is also
    the root cause of some oopses I've seen under these conditions:

    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227726

    This is probably also a problem for other sec= types and for NFSv4. The
    large reserved size for NFSv4 compound packets seems to generally paper
    over the problem, however.

    This patch adds a wrapper for svc_reserve that accounts for the possibility
    of a checksum. It also fixes up the appropriate callers of svc_reserve to
    call the wrapper. For now, it just uses a hardcoded value that I
    determined via testing. That value may need to be revised upward as things
    change, or we may want to eventually add a new auth_op that attempts to
    calculate this somehow.

    Unfortunately, there doesn't seem to be a good way to reliably determine
    the expected checksum length prior to actually calculating it, particularly
    with schemes like spkm3.

    Signed-off-by: Jeff Layton
    Acked-by: Neil Brown
    Cc: Trond Myklebust
    Acked-by: J. Bruce Fields
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Layton
     

13 Feb, 2007

1 commit

  • There are loads of places where the RPC server assumes that the rq_addr fields
    contains an IPv4 address. Top among these are error and debugging messages
    that display the server's IP address.

    Let's refactor the address printing into a separate function that's smart
    enough to figure out the difference between IPv4 and IPv6 addresses.

    Signed-off-by: Chuck Lever
    Cc: Aurelien Charbon
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chuck Lever
     

21 Oct, 2006

3 commits


04 Oct, 2006

3 commits

  • The limit over UDP remains at 32K. Also, make some of the apparently
    arbitrary sizing constants clearer.

    The biggest change here involves replacing NFSSVC_MAXBLKSIZE by a function of
    the rqstp. This allows it to be different for different protocols (udp/tcp)
    and also allows it to depend on the servers declared sv_bufsiz.

    Note that we don't actually increase sv_bufsz for nfs yet. That comes next.

    Signed-off-by: Greg Banks
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Greg Banks
     
  • .. by allocating the array of 'kvec' in 'struct svc_rqst'.

    As we plan to increase RPCSVC_MAXPAGES from 8 upto 256, we can no longer
    allocate an array of this size on the stack. So we allocate it in 'struct
    svc_rqst'.

    However svc_rqst contains (indirectly) an array of the same type and size
    (actually several, but they are in a union). So rather than waste space, we
    move those arrays out of the separately allocated union and into svc_rqst to
    share with the kvec moved out of svc_tcp_recvfrom (various arrays are used at
    different times, so there is no conflict).

    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     
  • nfsv2 needs the I_MUTEX_PARENT on the directory when creating a file too.

    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     

11 Apr, 2006

1 commit

  • NFSd makes sure there is enough space to hold the maximum possible reply
    before accepting a request. The units for this maximum is (4byte) words.
    However in three places, particularly for read request, the number given is
    a number of bytes.

    This means too much space is reserved which is slightly wasteful.

    This is the sort of patch that could uncover a deeper bug, and it is not
    critical, so it would be best for it to spend a while in -mm before going
    in to mainline.

    (akpm: target 2.6.17-rc2, 2.6.16.3 (approx))

    Discovered-by: "Eivind Sarto"
    Signed-off-by: Neil Brown
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     

19 Jan, 2006

1 commit

  • A recent patch which checked the return status of vfs_getattr in nfsd,
    completely missed the nfsproc.c (NFSv2) part. Here is it.

    This patch moved the call to vfs_getattr from the xdr encoding (at which point
    it is too late to return an error) to the call handling. This means several
    calls to vfs_getattr are needed in nfsproc.c. Many are encapsulated in
    nfsd_return_attrs and nfsd_return_dirop.

    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Shaw
     

23 Jun, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds