Skip to content
  1. Mar 13, 2014
    • Theodore Ts'o's avatar
      fs: push sync_filesystem() down to the file system's remount_fs() · 02b9984d
      Theodore Ts'o authored
      
      
      Previously, the no-op "mount -o mount /dev/xxx" operation when the
      file system is already mounted read-write causes an implied,
      unconditional syncfs().  This seems pretty stupid, and it's certainly
      documented or guaraunteed to do this, nor is it particularly useful,
      except in the case where the file system was mounted rw and is getting
      remounted read-only.
      
      However, it's possible that there might be some file systems that are
      actually depending on this behavior.  In most file systems, it's
      probably fine to only call sync_filesystem() when transitioning from
      read-write to read-only, and there are some file systems where this is
      not needed at all (for example, for a pseudo-filesystem or something
      like romfs).
      
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Artem Bityutskiy <dedekind1@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Cc: Jan Kara <jack@suse.cz>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Anders Larsen <al@alarsen.net>
      Cc: Phillip Lougher <phillip@squashfs.org.uk>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: xfs@oss.sgi.com
      Cc: linux-btrfs@vger.kernel.org
      Cc: linux-cifs@vger.kernel.org
      Cc: samba-technical@lists.samba.org
      Cc: codalist@coda.cs.cmu.edu
      Cc: linux-ext4@vger.kernel.org
      Cc: linux-f2fs-devel@lists.sourceforge.net
      Cc: fuse-devel@lists.sourceforge.net
      Cc: cluster-devel@redhat.com
      Cc: linux-mtd@lists.infradead.org
      Cc: jfs-discussion@lists.sourceforge.net
      Cc: linux-nfs@vger.kernel.org
      Cc: linux-nilfs@vger.kernel.org
      Cc: linux-ntfs-dev@lists.sourceforge.net
      Cc: ocfs2-devel@oss.oracle.com
      Cc: reiserfs-devel@vger.kernel.org
      02b9984d
  2. Feb 03, 2014
  3. Feb 01, 2014
  4. Jan 31, 2014
  5. Jan 30, 2014
  6. Jan 29, 2014
  7. Jan 28, 2014
  8. Jan 27, 2014
    • Jeff Layton's avatar
      sunrpc: turn warn_gssd() log message into a dprintk() · 0ea9de0e
      Jeff Layton authored
      
      
      The original printk() made sense when the GSSAPI codepaths were called
      only when sec=krb5* was explicitly requested. Now however, in many cases
      the nfs client will try to acquire GSSAPI credentials by default, even
      when it's not requested.
      
      Since we don't have a great mechanism to distinguish between the two
      cases, just turn the pr_warn into a dprintk instead. With this change we
      can also get rid of the ratelimiting.
      
      We do need to keep the EXPORT_SYMBOL(gssd_running) in place since
      auth_gss.ko needs it and sunrpc.ko provides it. We can however,
      eliminate the gssd_running call in the nfs code since that's a bit of a
      layering violation.
      
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      0ea9de0e
    • Jeff Layton's avatar
      NFS: fix the handling of NFS_INO_INVALID_DATA flag in nfs_revalidate_mapping · d529ef83
      Jeff Layton authored
      
      
      There is a possible race in how the nfs_invalidate_mapping function is
      handled.  Currently, we go and invalidate the pages in the file and then
      clear NFS_INO_INVALID_DATA.
      
      The problem is that it's possible for a stale page to creep into the
      mapping after the page was invalidated (i.e., via readahead). If another
      writer comes along and sets the flag after that happens but before
      invalidate_inode_pages2 returns then we could clear the flag
      without the cache having been properly invalidated.
      
      So, we must clear the flag first and then invalidate the pages. Doing
      this however, opens another race:
      
      It's possible to have two concurrent read() calls that end up in
      nfs_revalidate_mapping at the same time. The first one clears the
      NFS_INO_INVALID_DATA flag and then goes to call nfs_invalidate_mapping.
      
      Just before calling that though, the other task races in, checks the
      flag and finds it cleared. At that point, it trusts that the mapping is
      good and gets the lock on the page, allowing the read() to be satisfied
      from the cache even though the data is no longer valid.
      
      These effects are easily manifested by running diotest3 from the LTP
      test suite on NFS. That program does a series of DIO writes and buffered
      reads. The operations are serialized and page-aligned but the existing
      code fails the test since it occasionally allows a read to come out of
      the cache incorrectly. While mixing direct and buffered I/O isn't
      recommended, I believe it's possible to hit this in other ways that just
      use buffered I/O, though that situation is much harder to reproduce.
      
      The problem is that the checking/clearing of that flag and the
      invalidation of the mapping really need to be atomic. Fix this by
      serializing concurrent invalidations with a bitlock.
      
      At the same time, we also need to allow other places that check
      NFS_INO_INVALID_DATA to check whether we might be in the middle of
      invalidating the file, so fix up a couple of places that do that
      to look for the new NFS_INO_INVALIDATING flag.
      
      Doing this requires us to be careful not to set the bitlock
      unnecessarily, so this code only does that if it believes it will
      be doing an invalidation.
      
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      d529ef83
    • Malahal Naineni's avatar
      nfs: handle servers that support only ALLOW ACE type. · 7dd7d959
      Malahal Naineni authored
      
      
      Currently we support ACLs if the NFS server file system supports both
      ALLOW and DENY ACE types. This patch makes the Linux client work with
      ACLs even if the server supports only 'ALLOW' ACE type.
      
      Signed-off-by: default avatarMalahal Naineni <malahal@us.ibm.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      7dd7d959
  9. Jan 26, 2014
  10. Jan 23, 2014
    • Boaz Harrosh's avatar
      pnfs: Proper delay for NFS4ERR_RECALLCONFLICT in layout_get_done · ed7e5423
      Boaz Harrosh authored
      
      
      An NFS4ERR_RECALLCONFLICT is returned by server from a GET_LAYOUT
      only when a Server Sent a RECALL do to that GET_LAYOUT, or
      the RECALL and GET_LAYOUT crossed on the wire.
      In any way this means we want to wait at most until in-flight IO
      is finished and the RECALL can be satisfied.
      
      So a proper wait here is more like 1/10 of a second, not 15 seconds
      like we have now. In case of a server bug we delay exponentially
      longer on each retry.
      
      Current code totally craps out performance of very large files on
      most pnfs-objects layouts, because of how the map changes when the
      file has grown into the next raid group.
      
      [Stable: This will patch back to 3.9. If there are earlier still
       maintained trees, please tell me I'll send a patch]
      
      CC: Stable Tree <stable@vger.kernel.org>
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      ed7e5423
  11. Jan 21, 2014
    • Weston Andros Adamson's avatar
      pnfs: fix BUG in filelayout_recover_commit_reqs · 471252cd
      Weston Andros Adamson authored
      
      
      cond_resched_lock(cinfo->lock) is called everywhere else while holding
      the cinfo->lock spinlock.  Not holding this lock while calling
      transfer_commit_list in filelayout_recover_commit_reqs causes the BUG
      below.
      
      It's true that we can't hold this lock while calling pnfs_put_lseg,
      because that might try to lock the inode lock - which might be the
      same lock as cinfo->lock.
      
      To reproduce, mount a 2 DS pynfs server and run an O_DIRECT command
      that crosses a stripe boundary and is not page aligned, such as:
      
       dd if=/dev/zero of=/mnt/f bs=17000 count=1 oflag=direct
      
      BUG: sleeping function called from invalid context at linux/fs/nfs/nfs4filelayout.c:1161
      in_atomic(): 0, irqs_disabled(): 0, pid: 27, name: kworker/0:1
      2 locks held by kworker/0:1/27:
       #0:  (events){.+.+.+}, at: [<ffffffff810501d7>] process_one_work+0x175/0x3a5
       #1:  ((&dreq->work)){+.+...}, at: [<ffffffff810501d7>] process_one_work+0x175/0x3a5
      CPU: 0 PID: 27 Comm: kworker/0:1 Not tainted 3.13.0-rc3-branch-dros_testing+ #21
      Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
      Workqueue: events nfs_direct_write_schedule_work [nfs]
       0000000000000000 ffff88007a39bbb8 ffffffff81491256 ffff88007b87a130  ffff88007a39bbd8 ffffffff8105f103 ffff880079614000 ffff880079617d40  ffff88007a39bc20 ffffffffa011603e ffff880078988b98 0000000000000000
      Call Trace:
       [<ffffffff81491256>] dump_stack+0x4d/0x66
       [<ffffffff8105f103>] __might_sleep+0x100/0x105
       [<ffffffffa011603e>] transfer_commit_list+0x94/0xf1 [nfs_layout_nfsv41_files]
       [<ffffffffa01160d6>] filelayout_recover_commit_reqs+0x3b/0x68 [nfs_layout_nfsv41_files]
       [<ffffffffa00ba53a>] nfs_direct_write_reschedule+0x9f/0x1d6 [nfs]
       [<ffffffff810705df>] ? mark_lock+0x1df/0x224
       [<ffffffff8106e617>] ? trace_hardirqs_off_caller+0x37/0xa4
       [<ffffffff8106e691>] ? trace_hardirqs_off+0xd/0xf
       [<ffffffffa00ba8f8>] nfs_direct_write_schedule_work+0x9d/0xb7 [nfs]
       [<ffffffff810501d7>] ? process_one_work+0x175/0x3a5
       [<ffffffff81050258>] process_one_work+0x1f6/0x3a5
       [<ffffffff810501d7>] ? process_one_work+0x175/0x3a5
       [<ffffffff8105187e>] worker_thread+0x149/0x1f5
       [<ffffffff81051735>] ? rescuer_thread+0x28d/0x28d
       [<ffffffff81056d74>] kthread+0xd2/0xda
       [<ffffffff81056ca2>] ? __kthread_parkme+0x61/0x61
       [<ffffffff8149e66c>] ret_from_fork+0x7c/0xb0
       [<ffffffff81056ca2>] ? __kthread_parkme+0x61/0x61
      
      Signed-off-by: default avatarWeston Andros Adamson <dros@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      471252cd
  12. Jan 20, 2014
  13. Jan 19, 2014
  14. Jan 17, 2014
  15. Jan 13, 2014
  16. Jan 05, 2014
  17. Dec 06, 2013
  18. Dec 04, 2013
    • Helge Deller's avatar
      nfs: fix do_div() warning by instead using sector_div() · 3873d064
      Helge Deller authored
      
      
      When compiling a 32bit kernel with CONFIG_LBDAF=n the compiler complains like
      shown below.  Fix this warning by instead using sector_div() which is provided
      by the kernel.h header file.
      
      fs/nfs/blocklayout/extents.c: In function ‘normalize’:
      include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default]
      fs/nfs/blocklayout/extents.c:47:13: note: in expansion of macro ‘do_div’
      nfs/blocklayout/extents.c:47:2: warning: right shift count >= width of type [enabled by default]
      fs/nfs/blocklayout/extents.c:47:2: warning: passing argument 1 of ‘__div64_32’ from incompatible pointer type [enabled by default]
      include/asm-generic/div64.h:35:17: note: expected ‘uint64_t *’ but argument is of type ‘sector_t *’
       extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
      
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      3873d064
Loading