15 May, 2013

1 commit

  • Implement labeled NFS on the server: encoding and decoding, and writing
    and reading, of file labels.

    Enabled with CONFIG_NFSD_V4_SECURITY_LABEL.

    Signed-off-by: Matthew N. Dodd
    Signed-off-by: Miguel Rodel Felipe
    Signed-off-by: Phua Eu Gene
    Signed-off-by: Khin Mi Mi Aung
    Signed-off-by: J. Bruce Fields

    David Quigley
     

13 May, 2013

1 commit


26 Feb, 2013

1 commit


31 Jul, 2012

1 commit

  • When mnt_want_write() starts to handle freezing it will get a full lock
    semantics requiring proper lock ordering. So push mnt_want_write() call
    consistently outside of i_mutex.

    CC: linux-nfs@vger.kernel.org
    CC: "J. Bruce Fields"
    Signed-off-by: Jan Kara
    Signed-off-by: Al Viro

    Jan Kara
     

19 Mar, 2012

1 commit

  • Use 32-bit or 64-bit llseek() hashes for directory offsets depending on
    the NFS version. NFSv2 gets 32-bit hashes only.

    NOTE: This patch got rather complex as Christoph asked to set the
    filp->f_mode flag in the open call or immediatly after dentry_open()
    in nfsd_open() to avoid races.
    Personally I still do not see a reason for that and in my opinion
    FMODE_32BITHASH/FMODE_64BITHASH flags could be set nfsd_readdir(), as it
    follows directly after nfsd_open() without a chance of races.

    Signed-off-by: Bernd Schubert
    Signed-off-by: "Theodore Ts'o"
    Acked-by: J. Bruce Fields

    Bernd Schubert
     

04 Jan, 2012

2 commits


18 Oct, 2011

1 commit


28 Aug, 2011

2 commits

  • Acked-by: Jim Rees
    Signed-off-by: J. Bruce Fields

    J. Bruce Fields
     
  • A client that wants to execute a file must be able to read it. Read
    opens over nfs are therefore implicitly allowed for executable files
    even when those files are not readable.

    NFSv2/v3 get this right by using a passed-in NFSD_MAY_OWNER_OVERRIDE on
    read requests, but NFSv4 has gotten this wrong ever since
    dc730e173785e29b297aa605786c94adaffe2544 "nfsd4: fix owner-override on
    open", when we realized that the file owner shouldn't override
    permissions on non-reclaim NFSv4 opens.

    So we can't use NFSD_MAY_OWNER_OVERRIDE to tell nfsd_permission to allow
    reads of executable files.

    So, do the same thing we do whenever we encounter another weird NFS
    permission nit: define yet another NFSD_MAY_* flag.

    The industry's future standardization on 128-bit processors will be
    motivated primarily by the need for integers with enough bits for all
    the NFSD_MAY_* flags.

    Reported-by: Leonardo Borda
    Cc: stable@kernel.org
    Signed-off-by: J. Bruce Fields

    J. Bruce Fields
     

30 Apr, 2011

1 commit


11 Apr, 2011

2 commits


31 Jul, 2010

1 commit


23 Mar, 2010

1 commit

  • This is the second attempt to fix the problem whereby a COMMIT call
    causes a lease break and triggers a possible deadlock.

    The problem is that nfsd attempts to break a lease on a COMMIT call.
    This triggers a delegation recall if the lease is held for a delegation.
    If the client is the one holding the delegation and it's the same one on
    which it's issuing the COMMIT, then it can't return that delegation
    until the COMMIT is complete. But, nfsd won't complete the COMMIT until
    the delegation is returned. The client and server are essentially
    deadlocked until the state is marked bad (due to the client not
    responding on the callback channel).

    The first patch attempted to deal with this by eliminating the open of
    the file altogether and simply had nfsd_commit pass a NULL file pointer
    to the vfs_fsync_range. That would conflict with some work in progress
    by Christoph Hellwig to clean up the fsync interface, so this patch
    takes a different approach.

    This declares a new NFSD_MAY_NOT_BREAK_LEASE access flag that indicates
    to nfsd_open that it should not break any leases when opening the file,
    and has nfsd_commit set that flag on the nfsd_open call.

    For now, this patch leaves nfsd_commit opening the file with write
    access since I'm not clear on what sort of access would be more
    appropriate.

    Signed-off-by: Jeff Layton
    Cc: stable@kernel.org
    Signed-off-by: J. Bruce Fields

    Jeff Layton
     

16 Dec, 2009

2 commits


14 Nov, 2009

1 commit