1. 07 Feb, 2010 1 commit
  2. 06 Jan, 2010 1 commit
  3. 16 Dec, 2009 2 commits
  4. 15 Dec, 2009 5 commits
  5. 14 Dec, 2009 2 commits
  6. 13 Nov, 2009 1 commit
  7. 28 Sep, 2009 2 commits
  8. 21 Sep, 2009 1 commit
  9. 02 Sep, 2009 1 commit
    • David Howells's avatar
      CRED: Add some configurable debugging [try #6] · e0e81739
      David Howells authored
      Add a config option (CONFIG_DEBUG_CREDENTIALS) to turn on some debug checking
      for credential management.  The additional code keeps track of the number of
      pointers from task_structs to any given cred struct, and checks to see that
      this number never exceeds the usage count of the cred struct (which includes
      all references, not just those from task_structs).
      Furthermore, if SELinux is enabled, the code also checks that the security
      pointer in the cred struct is never seen to be invalid.
      This attempts to catch the bug whereby inode_has_perm() faults in an nfsd
      kernel thread on seeing cred->security be a NULL pointer (it appears that the
      credential struct has been previously released):
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  10. 03 Jul, 2009 1 commit
    • David Howells's avatar
      NFSD: Don't hold unrefcounted creds over call to nfsd_setuser() · 033a666c
      David Howells authored
      nfsd_open() gets an unrefcounted pointer to the current process's effective
      credentials at the top of the function, then calls nfsd_setuser() via
      fh_verify() - which may replace and destroy the current process's effective
      credentials - and then passes the unrefcounted pointer to dentry_open() - but
      the credentials may have been destroyed by this point.
      Instead, the value from current_cred() should be passed directly to
      dentry_open() as one of its arguments, rather than being cached in a variable.
      Possibly fh_verify() should return the creds to use.
      This is a regression introduced by
       "CRED: Pass credentials through
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-and-Verified-By: default avatarSteve Dickson <steved@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
  11. 15 Jun, 2009 4 commits
  12. 11 Jun, 2009 4 commits
  13. 27 May, 2009 2 commits
    • Mimi Zohar's avatar
      integrity: nfsd imbalance bug fix · 14dba533
      Mimi Zohar authored
      An nfsd exported file is opened/closed by the kernel causing the
      integrity imbalance message.
      Before a file is opened, there normally is permission checking, which
      is done in inode_permission().  However, as integrity checking requires
      a dentry and mount point, which is not available in inode_permission(),
      the integrity (permission) checking must be called separately.
      In order to detect any missing integrity checking calls, we keep track
      of file open/closes.  ima_path_check() increments these counts and
      does the integrity (permission) checking. As a result, the number of
      calls to ima_path_check()/ima_file_free() should be balanced.  An extra
      call to fput(), indicates the file could have been accessed without first
      calling ima_path_check().
      In nfsv3 permission checking is done once, followed by multiple reads,
      which do an open/close for each read.  The integrity (permission) checking
      call should be in nfsd_permission() after the inode_permission() call, but
      as there is no correlation between the number of permission checking and
      open calls, the integrity checking call should not increment the counters,
      but defer it to when the file is actually opened.
      This patch adds:
      - integrity (permission) checking for nfsd exported files in nfsd_permission().
      - a call to increment counts for files opened by nfsd.
      This patch has been updated to return the nfs error types.
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    • Wei Yongjun's avatar
      nfsd: fix hung up of nfs client while sync write data to nfs server · a0d24b29
      Wei Yongjun authored
      Commit 'Short write in nfsd becomes a full write to the client'
      ) broken the sync write.
      With the following commands to reproduce:
        $ mount -t nfs -o sync /mnt
        $ cd /mnt
        $ echo aaaa > temp.txt
      Then nfs client is hung up.
      In SYNC mode the server alaways return the write count 0 to the
      client. This is because the value of host_err in nfsd_vfs_write()
      will be overwrite in SYNC mode by 'host_err=nfsd_sync(file);',
      and then we return host_err(which is now 0) as write count.
      This patch fixed the problem.
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
  14. 20 Apr, 2009 2 commits
    • David Woodhouse's avatar
      Fix i_mutex vs. readdir handling in nfsd · 2f9092e1
      David Woodhouse authored
      Commit 14f7dd63 ("Copy XFS readdir hack into nfsd code") introduced a
      bug to generic code which had been extant for a long time in the XFS
      version -- it started to call through into lookup_one_len() and hence
      into the file systems' ->lookup() methods without i_mutex held on the
      This patch fixes it by locking the directory's i_mutex again before
      calling the filldir functions. The original deadlocks which commit
      14f7dd63 was designed to avoid are still avoided, because they were due
      to fs-internal locking, not i_mutex.
      While we're at it, fix the return type of nfsd_buffered_readdir() which
      should be a __be32 not an int -- it's an NFS errno, not a Linux errno.
      And return nfserrno(-ENOMEM) when allocation fails, not just -ENOMEM.
      Sparse would have caught that, if it wasn't so busy bitching about
      Commit 05f4f678
       ("nfsd4: don't do lookup within readdir in recovery
      code") introduced a similar problem with calling lookup_one_len()
      without i_mutex, which this patch also addresses. To fix that, it was
      necessary to fix the called functions so that they expect i_mutex to be
      held; that part was done by J. Bruce Fields.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Umm-I-can-live-with-that-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Reported-by: default avatarJ. R. Okajima <hooanon05@yahoo.co.jp>
      Tested-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      LKML-Reference: <8036.1237474444@jrobl>
      Cc: stable@kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      Safer nfsd_cross_mnt() · 1644ccc8
      Al Viro authored
      AFAICS, we have a subtle bug there: if we have crossed mountpoint
      *and* it got mount --move'd away, we'll be holding only one
      reference to fs containing dentry - exp->ex_path.mnt.  IOW, we
      ought to dput() before exp_put().
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  15. 25 Mar, 2009 1 commit
  16. 18 Mar, 2009 3 commits
    • Sachin S. Prabhu's avatar
      Inconsistent setattr behaviour · 0953e620
      Sachin S. Prabhu authored
      There is an inconsistency seen in the behaviour of nfs compared to other local
      filesystems on linux when changing owner or group of a directory. If the
      directory has SUID/SGID flags set, on changing owner or group on the directory,
      the flags are stripped off on nfs. These flags are maintained on other
      filesystems such as ext3.
      To reproduce on a nfs share or local filesystem, run the following commands
      mkdir test; chmod +s+g test; chown user1 test; ls -ld test
      On the nfs share, the flags are stripped and the output seen is
      drwxr-xr-x 2 user1 root 4096 Feb 23  2009 test
      On other local filesystems(ex: ext3), the flags are not stripped and the output
      seen is
      drwsr-sr-x 2 user1 root 4096 Feb 23 13:57 test
      chown_common() called from sys_chown() will only strip the flags if the inode is
      not a directory.
      static int chown_common(struct dentry * dentry, uid_t user, gid_t group)
              if (!S_ISDIR(inode->i_mode))
                      newattrs.ia_valid |=
                              ATTR_KILL_SUID | ATTR_KILL_SGID | ATTR_KILL_PRIV;
      See: http://www.opengroup.org/onlinepubs/7990989775/xsh/chown.html
      "If the path argument refers to a regular file, the set-user-ID (S_ISUID) and
      set-group-ID (S_ISGID) bits of the file mode are cleared upon successful return
      from chown(), unless the call is made by a process with appropriate privileges,
      in which case it is implementation-dependent whether these bits are altered. If
      chown() is successfully invoked on a file that is not a regular file, these
      bits may be cleared. These bits are defined in <sys/stat.h>."
      The behaviour as it stands does not appear to violate POSIX.  However the
      actions performed are inconsistent when comparing ext3 and nfs.
      Signed-off-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      Acked-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
    • David Shaw's avatar
      Short write in nfsd becomes a full write to the client · 31dec253
      David Shaw authored
      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
      Signed-off-by: default avatarDavid Shaw <dshaw@jabberwocky.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
    • wengang wang's avatar
      nfsd(v2/v3): fix the failure of creation from HPUX client · 4ac35c2f
      wengang wang authored
      sometimes HPUX nfs client sends a create request to linux nfs server(v2/v3).
      the dump of the request is like:
              mode: value follows
                  set_it: value follows (1)
                  mode: 00
              uid: no value
                  set_it: no value (0)
              gid: value follows
                  set_it: value follows (1)
                  gid: 8030
              size: value follows
                  set_it: value follows (1)
                  size: 0
              atime: don't change
                  set_it: don't change (0)
              mtime: don't change
                  set_it: don't change (0)
      note that mode is 00(havs no rwx privilege even for the owner) and it requires
      to set size to 0.
      as current nfsd(v2/v3) implementation, the server does mainly 2 steps:
      1) creates the file in mode specified by calling vfs_create().
      2) sets attributes for the file by calling nfsd_setattr().
      at step 2), it finally calls file system specific setattr() function which may
      fail when checking permission because changing size needs WRITE privilege but
      it has none since mode is 000.
      for this case, a new file created, we may simply ignore the request of
      setting size to 0, so that WRITE privilege is not needed and the open
      Signed-off-by: default avatarWengang Wang <wen.gang.wang@oracle.com>
       vfs.c |   19 +++++++++++++++++++
       1 file changed, 19 insertions(+)
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
  17. 16 Mar, 2009 1 commit
    • Jonathan Corbet's avatar
      Use f_lock to protect f_flags · db1dd4d3
      Jonathan Corbet authored
      Traditionally, changes to struct file->f_flags have been done under BKL
      protection, or with no protection at all.  This patch causes all f_flags
      changes after file open/creation time to be done under protection of
      f_lock.  This allows the removal of some BKL usage and fixes a number of
      longstanding (if microscopic) races.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
  18. 07 Jan, 2009 1 commit
    • J. Bruce Fields's avatar
      nfsd: fix double-locks of directory mutex · 9a8d248e
      J. Bruce Fields authored
      A number of nfsd operations depend on the i_mutex to cover more code
      than just the fsync, so the approach of 4c728ef5
       "add a vfs_fsync
      helper" doesn't work for nfsd.  Revert the parts of those patches that
      touch nfsd.
      Note: we can't, however, remove the logic from vfs_fsync that was needed
      only for the special case of nfsd, because a vfs_fsync(NULL,...) call
      can still result indirectly from a stackable filesystem that was called
      by nfsd.  (Thanks to Christoph Hellwig for pointing this out.)
      Reported-by: default avatarEric Sesterhenn <snakebyte@gmx.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
  19. 05 Jan, 2009 2 commits
    • Christoph Hellwig's avatar
      add a vfs_fsync helper · 4c728ef5
      Christoph Hellwig authored
      Fsync currently has a fdatawrite/fdatawait pair around the method call,
      and a mutex_lock/unlock of the inode mutex.  All callers of fsync have
      to duplicate this, but we have a few and most of them don't quite get
      it right.  This patch adds a new vfs_fsync that takes care of this.
      It's a little more complicated as usual as ->fsync might get a NULL file
      pointer and just a dentry from nfsd, but otherwise gets afile and we
      want to take the mapping and file operations from it when it is there.
      Notes on the fsync callers:
       - ecryptfs wasn't calling filemap_fdatawrite / filemap_fdatawait on the
         	lower file
       - coda wasn't calling filemap_fdatawrite / filemap_fdatawait on the host
      	file, and returning 0 when ->fsync was missing
       - shm wasn't calling either filemap_fdatawrite / filemap_fdatawait nor
         taking i_mutex.  Now given that shared memory doesn't have disk
         backing not doing anything in fsync seems fine and I left it out of
         the vfs_fsync conversion for now, but in that case we might just
         not pass it through to the lower file at all but just call the no-op
         simple_sync_file directly.
      [and now actually export vfs_fsync]
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      inode->i_op is never NULL · acfa4380
      Al Viro authored
      We used to have rather schizophrenic set of checks for NULL ->i_op even
      though it had been eliminated years ago.  You'd need to go out of your
      way to set it to NULL explicitly _and_ a bunch of code would die on
      such inodes anyway.  After killing two remaining places that still
      did that bogosity, all that crap can go away.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  20. 13 Nov, 2008 2 commits
  21. 09 Nov, 2008 1 commit
    • Doug Nazar's avatar
      Fix nfsd truncation of readdir results · b726e923
      Doug Nazar authored
      Commit 8d7c4203 "nfsd: fix failure to set eof in readdir in some
      situations" introduced a bug: on a directory in an exported ext3
      filesystem with dir_index unset, a READDIR will only return about 250
      entries, even if the directory was larger.
      Bisected it back to this commit; reverting it fixes the problem.
      It turns out that in this case ext3 reads a block at a time, then
      returns from readdir, which means we can end up with buf.full==0 but
      with more entries in the directory still to be read.  Before 8d7c4203
      (but after c002a6c7 "Optimise NFS readdir hack slightly"), this would
      cause us to return the READDIR result immediately, but with the eof bit
      unset.  That could cause a performance regression (because the client
      would need more roundtrips to the server to read the whole directory),
      but no loss in correctness, since the cleared eof bit caused the client
      to send another readdir.  After 8d7c4203
      , the setting of the eof bit
      made this a correctness problem.
      So, move nfserr_eof into the loop and remove the buf.full check so that
      we loop until buf.used==0.  The following seems to do the right thing
      and reduces the network traffic since we don't return a READDIR result
      until the buffer is full.
      Tested on an empty directory & large directory; eof is properly sent and
      there are no more short buffers.
      Signed-off-by: default avatarDoug Nazar <nazard@dragoninc.ca>
      Cc: David Woodhouse <David.Woodhouse@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>