1. 01 2月, 2017 5 次提交
  2. 28 1月, 2017 1 次提交
    • B
      xfs: prevent quotacheck from overloading inode lru · e0d76fa4
      Brian Foster 提交于
      Quotacheck runs at mount time in situations where quota accounting must
      be recalculated. In doing so, it uses bulkstat to visit every inode in
      the filesystem. Historically, every inode processed during quotacheck
      was released and immediately tagged for reclaim because quotacheck runs
      before the superblock is marked active by the VFS. In other words,
      the final iput() lead to an immediate ->destroy_inode() call, which
      allowed the XFS background reclaim worker to start reclaiming inodes.
      
      Commit 17c12bcd ("xfs: when replaying bmap operations, don't let
      unlinked inodes get reaped") marks the XFS superblock active sooner as
      part of the mount process to support caching inodes processed during log
      recovery. This occurs before quotacheck and thus means all inodes
      processed by quotacheck are inserted to the LRU on release.  The
      s_umount lock is held until the mount has completed and thus prevents
      the shrinkers from operating on the sb. This means that quotacheck can
      excessively populate the inode LRU and lead to OOM conditions on systems
      without sufficient RAM.
      
      Update the quotacheck bulkstat handler to set XFS_IGET_DONTCACHE on
      inodes processed by quotacheck. This causes ->drop_inode() to return 1
      and in turn causes iput_final() to evict the inode. This preserves the
      original quotacheck behavior and prevents it from overloading the LRU
      and running out of memory.
      
      CC: stable@vger.kernel.org # v4.9
      Reported-by: NMartin Svec <martin.svec@zoner.cz>
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NEric Sandeen <sandeen@redhat.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      e0d76fa4
  3. 27 1月, 2017 6 次提交
  4. 26 1月, 2017 2 次提交
    • D
      xfs: clear _XBF_PAGES from buffers when readahead page · 2aa6ba7b
      Darrick J. Wong 提交于
      If we try to allocate memory pages to back an xfs_buf that we're trying
      to read, it's possible that we'll be so short on memory that the page
      allocation fails.  For a blocking read we'll just wait, but for
      readahead we simply dump all the pages we've collected so far.
      
      Unfortunately, after dumping the pages we neglect to clear the
      _XBF_PAGES state, which means that the subsequent call to xfs_buf_free
      thinks that b_pages still points to pages we own.  It then double-frees
      the b_pages pages.
      
      This results in screaming about negative page refcounts from the memory
      manager, which xfs oughtn't be triggering.  To reproduce this case,
      mount a filesystem where the size of the inodes far outweighs the
      availalble memory (a ~500M inode filesystem on a VM with 300MB memory
      did the trick here) and run bulkstat in parallel with other memory
      eating processes to put a huge load on the system.  The "check summary"
      phase of xfs_scrub also works for this purpose.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NEric Sandeen <sandeen@redhat.com>
      2aa6ba7b
    • C
      xfs: extsize hints are not unlikely in xfs_bmap_btalloc · 493611eb
      Christoph Hellwig 提交于
      With COW files they are the hotpath, just like for files with the
      extent size hint attribute.  We really shouldn't micro-manage anything
      but failure cases with unlikely.
      
      Additionally Arnd Bergmann recently reported that one of these two
      unlikely annotations causes link failures together with an upcoming
      kernel instrumentation patch, so let's get rid of it ASAP.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      493611eb
  5. 25 1月, 2017 9 次提交
    • B
      xfs: remove racy hasattr check from attr ops · 5a93790d
      Brian Foster 提交于
      xfs_attr_[get|remove]() have unlocked attribute fork checks to optimize
      away a lock cycle in cases where the fork does not exist or is otherwise
      empty. This check is not safe, however, because an attribute fork short
      form to extent format conversion includes a transient state that causes
      the xfs_inode_hasattr() check to fail. Specifically,
      xfs_attr_shortform_to_leaf() creates an empty extent format attribute
      fork and then adds the existing shortform attributes to it.
      
      This means that lookup of an existing xattr can spuriously return
      -ENOATTR when racing against a setxattr that causes the associated
      format conversion. This was originally reproduced by an untar on a
      particularly configured glusterfs volume, but can also be reproduced on
      demand with properly crafted xattr requests.
      
      The format conversion occurs under the exclusive ilock. xfs_attr_get()
      and xfs_attr_remove() already have the proper locking and checks further
      down in the functions to handle this situation correctly. Drop the
      unlocked checks to avoid the spurious failure and rely on the existing
      logic.
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      5a93790d
    • C
      xfs: use per-AG reservations for the finobt · 76d771b4
      Christoph Hellwig 提交于
      Currently we try to rely on the global reserved block pool for block
      allocations for the free inode btree, but I have customer reports
      (fairly complex workload, need to find an easier reproducer) where that
      is not enough as the AG where we free an inode that requires a new
      finobt block is entirely full.  This causes us to cancel a dirty
      transaction and thus a file system shutdown.
      
      I think the right way to guard against this is to treat the finot the same
      way as the refcount btree and have a per-AG reservations for the possible
      worst case size of it, and the patch below implements that.
      
      Note that this could increase mount times with large finobt trees.  In
      an ideal world we would have added a field for the number of finobt
      fields to the AGI, similar to what we did for the refcount blocks.
      We should do add it next time we rev the AGI or AGF format by adding
      new fields.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      76d771b4
    • C
      xfs: only update mount/resv fields on success in __xfs_ag_resv_init · 4dfa2b84
      Christoph Hellwig 提交于
      Try to reserve the blocks first and only then update the fields in
      or hanging off the mount structure.  This way we can call __xfs_ag_resv_init
      again after a previous failure.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      4dfa2b84
    • C
      romfs: use different way to generate fsid for BLOCK or MTD · f598f82e
      Coly Li 提交于
      Commit 8a59f5d2 ("fs/romfs: return f_fsid for statfs(2)") generates
      a 64bit id from sb->s_bdev->bd_dev.  This is only correct when romfs is
      defined with CONFIG_ROMFS_ON_BLOCK.  If romfs is only defined with
      CONFIG_ROMFS_ON_MTD, sb->s_bdev is NULL, referencing sb->s_bdev->bd_dev
      will triger an oops.
      
      Richard Weinberger points out that when CONFIG_ROMFS_BACKED_BY_BOTH=y,
      both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD are defined.
      Therefore when calling huge_encode_dev() to generate a 64bit id, I use
      the follow order to choose parameter,
      
      - CONFIG_ROMFS_ON_BLOCK defined
        use sb->s_bdev->bd_dev
      - CONFIG_ROMFS_ON_BLOCK undefined and CONFIG_ROMFS_ON_MTD defined
        use sb->s_dev when,
      - both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD undefined
        leave id as 0
      
      When CONFIG_ROMFS_ON_MTD is defined and sb->s_mtd is not NULL, sb->s_dev
      is set to a device ID generated by MTD_BLOCK_MAJOR and mtd index,
      otherwise sb->s_dev is 0.
      
      This is a try-best effort to generate a uniq file system ID, if all the
      above conditions are not meet, f_fsid of this romfs instance will be 0.
      Generally only one romfs can be built on single MTD block device, this
      method is enough to identify multiple romfs instances in a computer.
      
      Link: http://lkml.kernel.org/r/1482928596-115155-1-git-send-email-colyli@suse.deSigned-off-by: NColy Li <colyli@suse.de>
      Reported-by: NNong Li <nongli1031@gmail.com>
      Tested-by: NNong Li <nongli1031@gmail.com>
      Cc: Richard Weinberger <richard.weinberger@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f598f82e
    • E
      proc: add a schedule point in proc_pid_readdir() · 3ba4bcee
      Eric Dumazet 提交于
      We have seen proc_pid_readdir() invocations holding cpu for more than 50
      ms.  Add a cond_resched() to be gentle with other tasks.
      
      [akpm@linux-foundation.org: coding style fix]
      Link: http://lkml.kernel.org/r/1484238380.15816.42.camel@edumazet-glaptop3.roam.corp.google.comSigned-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3ba4bcee
    • A
      userfaultfd: fix SIGBUS resulting from false rwsem wakeups · 15a77c6f
      Andrea Arcangeli 提交于
      With >=32 CPUs the userfaultfd selftest triggered a graceful but
      unexpected SIGBUS because VM_FAULT_RETRY was returned by
      handle_userfault() despite the UFFDIO_COPY wasn't completed.
      
      This seems caused by rwsem waking the thread blocked in
      handle_userfault() and we can't run up_read() before the wait_event
      sequence is complete.
      
      Keeping the wait_even sequence identical to the first one, would require
      running userfaultfd_must_wait() again to know if the loop should be
      repeated, and it would also require retaking the rwsem and revalidating
      the whole vma status.
      
      It seems simpler to wait the targeted wakeup so that if false wakeups
      materialize we still wait for our specific wakeup event, unless of
      course there are signals or the uffd was released.
      
      Debug code collecting the stack trace of the wakeup showed this:
      
        $ ./userfaultfd 100 99999
        nr_pages: 25600, nr_pages_per_cpu: 800
        bounces: 99998, mode: racing ver poll, userfaults: 32 35 90 232 30 138 69 82 34 30 139 40 40 31 20 19 43 13 15 28 27 38 21 43 56 22 1 17 31 8 4 2
        bounces: 99997, mode: rnd ver poll, Bus error (core dumped)
      
          save_stack_trace+0x2b/0x50
          try_to_wake_up+0x2a6/0x580
          wake_up_q+0x32/0x70
          rwsem_wake+0xe0/0x120
          call_rwsem_wake+0x1b/0x30
          up_write+0x3b/0x40
          vm_mmap_pgoff+0x9c/0xc0
          SyS_mmap_pgoff+0x1a9/0x240
          SyS_mmap+0x22/0x30
          entry_SYSCALL_64_fastpath+0x1f/0xbd
          0xffffffffffffffff
          FAULT_FLAG_ALLOW_RETRY missing 70
        CPU: 24 PID: 1054 Comm: userfaultfd Tainted: G        W       4.8.0+ #30
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
        Call Trace:
          dump_stack+0xb8/0x112
          handle_userfault+0x572/0x650
          handle_mm_fault+0x12cb/0x1520
          __do_page_fault+0x175/0x500
          trace_do_page_fault+0x61/0x270
          do_async_page_fault+0x19/0x90
          async_page_fault+0x25/0x30
      
      This always happens when the main userfault selftest thread is running
      clone() while glibc runs either mprotect or mmap (both taking mmap_sem
      down_write()) to allocate the thread stack of the background threads,
      while locking/userfault threads already run at full throttle and are
      susceptible to false wakeups that may cause handle_userfault() to return
      before than expected (which results in graceful SIGBUS at the next
      attempt).
      
      This was reproduced only with >=32 CPUs because the loop to start the
      thread where clone() is too quick with fewer CPUs, while with 32 CPUs
      there's already significant activity on ~32 locking and userfault
      threads when the last background threads are started with clone().
      
      This >=32 CPUs SMP race condition is likely reproducible only with the
      selftest because of the much heavier userfault load it generates if
      compared to real apps.
      
      We'll have to allow "one more" VM_FAULT_RETRY for the WP support and a
      patch floating around that provides it also hidden this problem but in
      reality only is successfully at hiding the problem.
      
      False wakeups could still happen again the second time
      handle_userfault() is invoked, even if it's a so rare race condition
      that getting false wakeups twice in a row is impossible to reproduce.
      This full fix is needed for correctness, the only alternative would be
      to allow VM_FAULT_RETRY to be returned infinitely.  With this fix the WP
      support can stick to a strict "one more" VM_FAULT_RETRY logic (no need
      of returning it infinite times to avoid the SIGBUS).
      
      Link: http://lkml.kernel.org/r/20170111005535.13832-2-aarcange@redhat.comSigned-off-by: NAndrea Arcangeli <aarcange@redhat.com>
      Reported-by: NShubham Kumar Sharma <shubham.kumar.sharma@oracle.com>
      Tested-by: NMike Kravetz <mike.kravetz@oracle.com>
      Acked-by: NHillf Danton <hillf.zj@alibaba-inc.com>
      Cc: Michael Rapoport <RAPOPORT@il.ibm.com>
      Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      15a77c6f
    • R
      dax: fix build warnings with FS_DAX and !FS_IOMAP · 6affb9d7
      Ross Zwisler 提交于
      As reported by Arnd:
      
        https://lkml.org/lkml/2017/1/10/756
      
      Compiling with the following configuration:
      
        # CONFIG_EXT2_FS is not set
        # CONFIG_EXT4_FS is not set
        # CONFIG_XFS_FS is not set
        # CONFIG_FS_IOMAP depends on the above filesystems, as is not set
        CONFIG_FS_DAX=y
      
      generates build warnings about unused functions in fs/dax.c:
      
        fs/dax.c:878:12: warning: `dax_insert_mapping' defined but not used [-Wunused-function]
         static int dax_insert_mapping(struct address_space *mapping,
                    ^~~~~~~~~~~~~~~~~~
        fs/dax.c:572:12: warning: `copy_user_dax' defined but not used [-Wunused-function]
         static int copy_user_dax(struct block_device *bdev, sector_t sector, size_t size,
                    ^~~~~~~~~~~~~
        fs/dax.c:542:12: warning: `dax_load_hole' defined but not used [-Wunused-function]
         static int dax_load_hole(struct address_space *mapping, void **entry,
                    ^~~~~~~~~~~~~
        fs/dax.c:312:14: warning: `grab_mapping_entry' defined but not used [-Wunused-function]
         static void *grab_mapping_entry(struct address_space *mapping, pgoff_t index,
                      ^~~~~~~~~~~~~~~~~~
      
      Now that the struct buffer_head based DAX fault paths and I/O path have
      been removed we really depend on iomap support being present for DAX.
      Make this explicit by selecting FS_IOMAP if we compile in DAX support.
      
      This allows us to remove conditional selections of FS_IOMAP when FS_DAX
      was present for ext2 and ext4, and to remove an #ifdef in fs/dax.c.
      
      Link: http://lkml.kernel.org/r/1484087383-29478-1-git-send-email-ross.zwisler@linux.intel.comSigned-off-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6affb9d7
    • D
      xfs: verify dirblocklog correctly · 83d230eb
      Darrick J. Wong 提交于
      sb_dirblklog is added to sb_blocklog to compute the directory block size
      in bytes.  Therefore, we must compare the sum of both those values
      against XFS_MAX_BLOCKSIZE_LOG, not just dirblklog.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NEric Sandeen <sandeen@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      83d230eb
    • B
      NFSv4.0: always send mode in SETATTR after EXCLUSIVE4 · a430607b
      Benjamin Coddington 提交于
      Some nfsv4.0 servers may return a mode for the verifier following an open
      with EXCLUSIVE4 createmode, but this does not mean the client should skip
      setting the mode in the following SETATTR.  It should only do that for
      EXCLUSIVE4_1 or UNGAURDED createmode.
      
      Fixes: 5334c5bd ("NFS: Send attributes in OPEN request for NFS4_CREATE_EXCLUSIVE4_1")
      Signed-off-by: NBenjamin Coddington <bcodding@redhat.com>
      Cc: stable@vger.kernel.org # v4.3+
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      a430607b
  6. 24 1月, 2017 3 次提交
  7. 20 1月, 2017 3 次提交
    • L
      Btrfs: fix truncate down when no_holes feature is enabled · 91298eec
      Liu Bo 提交于
      For such a file mapping,
      
      [0-4k][hole][8k-12k]
      
      In NO_HOLES mode, we don't have the [hole] extent any more.
      Commit c1aa4575 ("Btrfs: fix shrinking truncate when the no_holes feature is enabled")
       fixed disk isize not being updated in NO_HOLES mode when data is not flushed.
      
      However, even if data has been flushed, we can still have trouble
      in updating disk isize since we updated disk isize to 'start' of
      the last evicted extent.
      Reviewed-by: NChris Mason <clm@fb.com>
      Signed-off-by: NLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      91298eec
    • C
      Btrfs: Fix deadlock between direct IO and fast fsync · 97dcdea0
      Chandan Rajendra 提交于
      The following deadlock is seen when executing generic/113 test,
      
       ---------------------------------------------------------+----------------------------------------------------
        Direct I/O task                                           Fast fsync task
       ---------------------------------------------------------+----------------------------------------------------
        btrfs_direct_IO
          __blockdev_direct_IO
           do_blockdev_direct_IO
            do_direct_IO
             btrfs_get_blocks_direct
              while (blocks needs to written)
               get_more_blocks (first iteration)
                btrfs_get_blocks_direct
                 btrfs_create_dio_extent
                   down_read(&BTRFS_I(inode) >dio_sem)
                   Create and add extent map and ordered extent
                   up_read(&BTRFS_I(inode) >dio_sem)
                                                                  btrfs_sync_file
                                                                    btrfs_log_dentry_safe
                                                                     btrfs_log_inode_parent
                                                                      btrfs_log_inode
                                                                       btrfs_log_changed_extents
                                                                        down_write(&BTRFS_I(inode) >dio_sem)
                                                                         Collect new extent maps and ordered extents
                                                                          wait for ordered extent completion
               get_more_blocks (second iteration)
                btrfs_get_blocks_direct
                 btrfs_create_dio_extent
                   down_read(&BTRFS_I(inode) >dio_sem)
       --------------------------------------------------------------------------------------------------------------
      
      In the above description, Btrfs direct I/O code path has not yet started
      submitting bios for file range covered by the initial ordered
      extent. Meanwhile, The fast fsync task obtains the write semaphore and
      waits for I/O on the ordered extent to get completed. However, the
      Direct I/O task is now blocked on obtaining the read semaphore.
      
      To resolve the deadlock, this commit modifies the Direct I/O code path
      to obtain the read semaphore before invoking
      __blockdev_direct_IO(). The semaphore is then given up after
      __blockdev_direct_IO() returns. This allows the Direct I/O code to
      complete I/O on all the ordered extents it creates.
      Signed-off-by: NChandan Rajendra <chandan@linux.vnet.ibm.com>
      Reviewed-by: NFilipe Manana <fdmanana@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      97dcdea0
    • W
      btrfs: fix false enospc error when truncating heavily reflinked file · 47b5d646
      Wang Xiaoguang 提交于
      Below test script can reveal this bug:
          dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=100
          dev=$(losetup --show -f fs.img)
          mkdir -p /mnt/mntpoint
          mkfs.btrfs  -f $dev
          mount $dev /mnt/mntpoint
          cd /mnt/mntpoint
      
          echo "workdir is: /mnt/mntpoint"
          blocksize=$((128 * 1024))
          dd if=/dev/zero of=testfile bs=$blocksize count=1
          sync
          count=$((17*1024*1024*1024/blocksize))
          echo "file size is:" $((count*blocksize))
          for ((i = 1; i <= $count; i++)); do
              dst_offset=$((blocksize * i))
              xfs_io -f -c "reflink testfile 0 $dst_offset $blocksize"\
                      testfile > /dev/null
          done
          sync
          truncate --size 0 testfile
      
      The last truncate operation will fail for ENOSPC reason, but indeed
      it should not fail.
      
      In btrfs_truncate(), we use a temporary block_rsv to do truncate
      operation. With every btrfs_truncate_inode_items() call, we migrate space
      to this block_rsv, but forget to cleanup previous reservation, which
      will make this block_rsv's reserved bytes keep growing, and this reserved
      space will only be released in the end of btrfs_truncate(), this metadata
      leak will impact other's metadata reservation. In this case, it's
      "btrfs_start_transaction(root, 2);" fails for enospc error, which make
      this truncate operation fail.
      
      Call btrfs_block_rsv_release() to fix this bug.
      Signed-off-by: NWang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
      Reviewed-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      47b5d646
  8. 19 1月, 2017 5 次提交
  9. 18 1月, 2017 6 次提交