1. 26 Oct, 2016 1 commit
    • Charlie Jacobsen's avatar
      Major overhaul of build process. · 8198c2fb
      Charlie Jacobsen authored
      Full kernel build no longer required. Yay! This should
      cut down on dev time a lot.
      
      I moved all of the LCD source into $(kernel-src)/lcd-domains/,
      so it's all in one spot. There is now a top-level makefile in
      there that triggers building liblcd, the microkernel, and the
      examples. This is built as an *external* build now, even
      though the directory is in the kernel source. The build now takes
      under a minute to do everything LCD related.
      
      This should also make verification easier in the future (e.g.
      building with clang) if we aren't ensnared in the kernel
      source.
      
      Of course, to use the microkernel and examples, you have to
      build the patched kernel and install it. But now when you
      make a few lines of changes in e.g. an example, you don't have
      to trigger a top-level kernel build to rebuild it. Running
      the full kernel build takes on average about 3 - 4 minutes
      (some files are generated everytime, linking is done, and so
      on), and can take upwards of 30 minutes for a full build if you
      re-config'd.
      
      Which brings me to my other change: no more config for LCDs
      in menuconfig. If we create menu entries for every example
      and so on, we end up changing the config too often, and this
      triggers full kernel rebuilds == waste of time. We can use
      macros by setting them via compiler flags (e.g., -DSOME_FLAG).
      Furthermore, it wasn't making sense to me to do conditional
      compilation for LCD support (we always want to compile for that).
      Yes, changes aren't clearly delineated with macros, but you can
      see changes made by just doing 'git diff v3.10.14 some-file-or-dir'.
      
      The wiki has been fully updated with instructions for building,
      and other relevant parts (updated paths to files).
      
      I also took the opportunity to clean up some old stuff lying around
      that is dead (like lcdguest). I incorporated all of the documentation
      in Documentation/lcd-domains into the wiki so it's all in one
      spot now (including some helpful debug tips).
      8198c2fb
  2. 25 Oct, 2016 4 commits
  3. 22 Oct, 2016 22 commits
    • David Howells's avatar
      cachefiles: Fix attempt to read i_blocks after deleting file [ver #2] · 336f2e1e
      David Howells authored
      commit a818101d7b92e76db2f9a597e4830734767473b9 upstream.
      
      An NULL-pointer dereference happens in cachefiles_mark_object_inactive()
      when it tries to read i_blocks so that it can tell the cachefilesd daemon
      how much space it's making available.
      
      The problem is that cachefiles_drop_object() calls
      cachefiles_mark_object_inactive() after calling cachefiles_delete_object()
      because the object being marked active staves off attempts to (re-)use the
      file at that filename until after it has been deleted.  This means that
      d_inode is NULL by the time we come to try to access it.
      
      To fix the problem, have the caller of cachefiles_mark_object_inactive()
      supply the number of blocks freed up.
      
      Without this, the following oops may occur:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
      IP: [<ffffffffa06c5cc1>] cachefiles_mark_object_inactive+0x61/0xb0 [cachefiles]
      ...
      CPU: 11 PID: 527 Comm: kworker/u64:4 Tainted: G          I    ------------   3.10.0-470.el7.x86_64 #1
      Hardware name: Hewlett-Packard HP Z600 Workstation/0B54h, BIOS 786G4 v03.19 03/11/2011
      Workqueue: fscache_object fscache_object_work_func [fscache]
      task: ffff880035edaf10 ti: ffff8800b77c0000 task.ti: ffff8800b77c0000
      RIP: 0010:[<ffffffffa06c5cc1>] cachefiles_mark_object_inactive+0x61/0xb0 [cachefiles]
      RSP: 0018:ffff8800b77c3d70  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff8800bf6cc400 RCX: 0000000000000034
      RDX: 0000000000000000 RSI: ffff880090ffc710 RDI: ffff8800bf761ef8
      RBP: ffff8800b77c3d88 R08: 2000000000000000 R09: 0090ffc710000000
      R10: ff51005d2ff1c400 R11: 0000000000000000 R12: ffff880090ffc600
      R13: ffff8800bf6cc520 R14: ffff8800bf6cc400 R15: ffff8800bf6cc498
      FS:  0000000000000000(0000) GS:ffff8800bb8c0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000098 CR3: 00000000019ba000 CR4: 00000000000007e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Stack:
       ffff880090ffc600 ffff8800bf6cc400 ffff8800867df140 ffff8800b77c3db0
       ffffffffa06c48cb ffff880090ffc600 ffff880090ffc180 ffff880090ffc658
       ffff8800b77c3df0 ffffffffa085d846 ffff8800a96b8150 ffff880090ffc600
      Call Trace:
       [<ffffffffa06c48cb>] cachefiles_drop_object+0x6b/0xf0 [cachefiles]
       [<ffffffffa085d846>] fscache_drop_object+0xd6/0x1e0 [fscache]
       [<ffffffffa085d615>] fscache_object_work_func+0xa5/0x200 [fscache]
       [<ffffffff810a605b>] process_one_work+0x17b/0x470
       [<ffffffff810a6e96>] worker_thread+0x126/0x410
       [<ffffffff810a6d70>] ? rescuer_thread+0x460/0x460
       [<ffffffff810ae64f>] kthread+0xcf/0xe0
       [<ffffffff810ae580>] ? kthread_create_on_node+0x140/0x140
       [<ffffffff81695418>] ret_from_fork+0x58/0x90
       [<ffffffff810ae580>] ? kthread_create_on_node+0x140/0x140
      
      The oopsing code shows:
      
      	callq  0xffffffff810af6a0 <wake_up_bit>
      	mov    0xf8(%r12),%rax
      	mov    0x30(%rax),%rax
      	mov    0x98(%rax),%rax   <---- oops here
      	lock add %rax,0x130(%rbx)
      
      where this is:
      
      	d_backing_inode(object->dentry)->i_blocks
      
      Fixes: a5b3a80b (CacheFiles: Provide read-and-reset release counters for cachefilesd)
      Reported-by: default avatarJianhong Yin <jiyin@redhat.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Reviewed-by: default avatarSteve Dickson <steved@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      336f2e1e
    • Miklos Szeredi's avatar
      vfs: move permission checking into notify_change() for utimes(NULL) · 7bf99896
      Miklos Szeredi authored
      commit f2b20f6ee842313a0d681dbbf7f87b70291a6a3b upstream.
      
      This fixes a bug where the permission was not properly checked in
      overlayfs.  The testcase is ltp/utimensat01.
      
      It is also cleaner and safer to do the permission checking in the vfs
      helper instead of the caller.
      
      This patch introduces an additional ia_valid flag ATTR_TOUCH (since
      touch(1) is the most obvious user of utimes(NULL)) that is passed into
      notify_change whenever the conditions for this special permission checking
      mode are met.
      Reported-by: default avatarAihua Zhang <zhangaihua1@huawei.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Tested-by: default avatarAihua Zhang <zhangaihua1@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bf99896
    • Marcelo Ricardo Leitner's avatar
      dlm: free workqueues after the connections · 6b746940
      Marcelo Ricardo Leitner authored
      commit 3a8db79889ce16930aff19b818f5b09651bb7644 upstream.
      
      After backporting commit ee44b4bc ("dlm: use sctp 1-to-1 API")
      series to a kernel with an older workqueue which didn't use RCU yet, it
      was noticed that we are freeing the workqueues in dlm_lowcomms_stop()
      too early as free_conn() will try to access that memory for canceling
      the queued works if any.
      
      This issue was introduced by commit 0d737a8c as before it such
      attempt to cancel the queued works wasn't performed, so the issue was
      not present.
      
      This patch fixes it by simply inverting the free order.
      
      Fixes: 0d737a8c ("dlm: fix race while closing connections")
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b746940
    • Jan Kara's avatar
      ext4: unmap metadata when zeroing blocks · fb13b62a
      Jan Kara authored
      commit 9b623df614576680cadeaa4d7e0b5884de8f7c17 upstream.
      
      When zeroing blocks for DAX allocations, we also have to unmap aliases
      in the block device mappings.  Otherwise writeback can overwrite zeros
      with stale data from block device page cache.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb13b62a
    • gmail's avatar
      ext4: release bh in make_indexed_dir · ff50a724
      gmail authored
      commit e81d44778d1d57bbaef9e24c4eac7c8a7a401d40 upstream.
      
      The commit 6050d47a: "ext4: bail out from make_indexed_dir() on
      first error" could end up leaking bh2 in the error path.
      
      [ Also avoid renaming bh2 to bh, which just confuses things --tytso ]
      Signed-off-by: default avataryangsheng <yngsion@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff50a724
    • Ross Zwisler's avatar
      ext4: allow DAX writeback for hole punch · 99fa4c50
      Ross Zwisler authored
      commit cca32b7eeb4ea24fa6596650e06279ad9130af98 upstream.
      
      Currently when doing a DAX hole punch with ext4 we fail to do a writeback.
      This is because the logic around filemap_write_and_wait_range() in
      ext4_punch_hole() only looks for dirty page cache pages in the radix tree,
      not for dirty DAX exceptional entries.
      Signed-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99fa4c50
    • Eric Biggers's avatar
      ext4: fix memory leak when symlink decryption fails · 5373f6cc
      Eric Biggers authored
      commit dcce7a46c6f28f41447272fb44348ead8f584573 upstream.
      
      This bug was introduced in v4.8-rc1.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5373f6cc
    • Fabian Frederick's avatar
      ext4: fix memory leak in ext4_insert_range() · 7a689387
      Fabian Frederick authored
      commit edf15aa180d7b98fe16bd3eda42f9dd0e60dee20 upstream.
      
      Running xfstests generic/013 with kmemleak gives the following:
      
      unreferenced object 0xffff8801d3d27de0 (size 96):
        comm "fsstress", pid 4941, jiffies 4294860168 (age 53.485s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff818eaaf3>] kmemleak_alloc+0x23/0x40
          [<ffffffff81179805>] __kmalloc+0xf5/0x1d0
          [<ffffffff8122ef5c>] ext4_find_extent+0x1ec/0x2f0
          [<ffffffff8123530c>] ext4_insert_range+0x34c/0x4a0
          [<ffffffff81235942>] ext4_fallocate+0x4e2/0x8b0
          [<ffffffff81181334>] vfs_fallocate+0x134/0x210
          [<ffffffff8118203f>] SyS_fallocate+0x3f/0x60
          [<ffffffff818efa9b>] entry_SYSCALL_64_fastpath+0x13/0x8f
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      Problem seems mitigated by dropping refs and freeing path
      when there's no path[depth].p_ext
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a689387
    • wangguang's avatar
      ext4: bugfix for mmaped pages in mpage_release_unused_pages() · 30ac674a
      wangguang authored
      commit 4e800c0359d9a53e6bf0ab216954971b2515247f upstream.
      
      Pages clear buffers after ext4 delayed block allocation failed,
      However, it does not clean its pte_dirty flag.
      if the pages unmap ,in cording to the pte_dirty ,
      unmap_page_range may try to call __set_page_dirty,
      
      which may lead to the bugon at
      mpage_prepare_extent_to_map:head = page_buffers(page);.
      
      This patch just call clear_page_dirty_for_io to clean pte_dirty
      at mpage_release_unused_pages for pages mmaped.
      
      Steps to reproduce the bug:
      
      (1) mmap a file in ext4
      	addr = (char *)mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED,
      	       	            fd, 0);
      	memset(addr, 'i', 4096);
      
      (2) return EIO at
      
      	ext4_writepages->mpage_map_and_submit_extent->mpage_map_one_extent
      
      which causes this log message to be print:
      
                      ext4_msg(sb, KERN_CRIT,
                              "Delayed block allocation failed for "
                              "inode %lu at logical offset %llu with"
                              " max blocks %u with error %d",
                              inode->i_ino,
                              (unsigned long long)map->m_lblk,
                              (unsigned)map->m_len, -err);
      
      (3)Unmap the addr cause warning at
      
      	__set_page_dirty:WARN_ON_ONCE(warn && !PageUptodate(page));
      
      (4) wait for a minute,then bugon happen.
      Signed-off-by: default avatarwangguang <wangguang03@zte.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30ac674a
    • Daeho Jeong's avatar
      ext4: reinforce check of i_dtime when clearing high fields of uid and gid · eac6c9e4
      Daeho Jeong authored
      commit 93e3b4e6631d2a74a8cf7429138096862ff9f452 upstream.
      
      Now, ext4_do_update_inode() clears high 16-bit fields of uid/gid
      of deleted and evicted inode to fix up interoperability with old
      kernels. However, it checks only i_dtime of an inode to determine
      whether the inode was deleted and evicted, and this is very risky,
      because i_dtime can be used for the pointer maintaining orphan inode
      list, too. We need to further check whether the i_dtime is being
      used for the orphan inode list even if the i_dtime is not NULL.
      
      We found that high 16-bit fields of uid/gid of inode are unintentionally
      and permanently cleared when the inode truncation is just triggered,
      but not finished, and the inode metadata, whose high uid/gid bits are
      cleared, is written on disk, and the sudden power-off follows that
      in order.
      Signed-off-by: default avatarDaeho Jeong <daeho.jeong@samsung.com>
      Signed-off-by: default avatarHobin Woo <hobin.woo@samsung.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eac6c9e4
    • Eric Whitney's avatar
      ext4: enforce online defrag restriction for encrypted files · ddcd9969
      Eric Whitney authored
      commit 14fbd4aa613bd5110556c281799ce36dc6f3ba97 upstream.
      
      Online defragging of encrypted files is not currently implemented.
      However, the move extent ioctl can still return successfully when
      called.  For example, this occurs when xfstest ext4/020 is run on an
      encrypted file system, resulting in a corrupted test file and a
      corresponding test failure.
      
      Until the proper functionality is implemented, fail the move extent
      ioctl if either the original or donor file is encrypted.
      Signed-off-by: default avatarEric Whitney <enwlinux@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ddcd9969
    • Jan Kara's avatar
      jbd2: fix lockdep annotation in add_transaction_credits() · 4cd2546a
      Jan Kara authored
      commit e03a9976afce6634826d56c33531dd10bb9a9166 upstream.
      
      Thomas has reported a lockdep splat hitting in
      add_transaction_credits(). The problem is that that function calls
      jbd2_might_wait_for_commit() while holding j_state_lock which is wrong
      (we do not really wait for transaction commit while holding that lock).
      
      Fix the problem by moving jbd2_might_wait_for_commit() into places where
      we are ready to wait for transaction commit and thus j_state_lock is
      unlocked.
      
      Fixes: 1eaa566dReported-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4cd2546a
    • Eric W. Biederman's avatar
      autofs: Fix automounts by using current_real_cred()->uid · 2f9aa718
      Eric W. Biederman authored
      commit 069d5ac9ae0d271903cc4607890616418118379a upstream.
      
      Seth Forshee reports that in 4.8-rcN some automounts are failing
      because the requesting the automount changed.
      
      The relevant call path is:
      follow_automount()
          ->d_automount
          autofs4_d_automount
             autofs4_mount_wait
                 autofs4_wait
      
      In autofs4_wait wq_uid and wq_gid are set to current_uid() and
      current_gid respectively.  With follow_automount now overriding creds
      uid that we export to userspace changes and that breaks existing
      setups.
      
      To remove the regression set wq_uid and wq_gid from
      current_real_cred()->uid and current_real_cred()->gid respectively.
      This restores the current behavior as current->real_cred is identical
      to current->cred except when override creds are used.
      
      Fixes: aeaa4a79 ("fs: Call d_automount with the filesystems creds")
      Reported-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Tested-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f9aa718
    • Mike Galbraith's avatar
      reiserfs: Unlock superblock before calling reiserfs_quota_on_mount() · 5c55afa3
      Mike Galbraith authored
      commit 420902c9d086848a7548c83e0a49021514bd71b7 upstream.
      
      If we hold the superblock lock while calling reiserfs_quota_on_mount(), we can
      deadlock our own worker - mount blocks kworker/3:2, sleeps forever more.
      
      crash> ps|grep UN
          715      2   3  ffff880220734d30  UN   0.0       0      0  [kworker/3:2]
         9369   9341   2  ffff88021ffb7560  UN   1.3  493404 123184  Xorg
         9665   9664   3  ffff880225b92ab0  UN   0.0   47368    812  udisks-daemon
        10635  10403   3  ffff880222f22c70  UN   0.0   14904    936  mount
      crash> bt ffff880220734d30
      PID: 715    TASK: ffff880220734d30  CPU: 3   COMMAND: "kworker/3:2"
       #0 [ffff8802244c3c20] schedule at ffffffff8144584b
       #1 [ffff8802244c3cc8] __rt_mutex_slowlock at ffffffff814472b3
       #2 [ffff8802244c3d28] rt_mutex_slowlock at ffffffff814473f5
       #3 [ffff8802244c3dc8] reiserfs_write_lock at ffffffffa05f28fd [reiserfs]
       #4 [ffff8802244c3de8] flush_async_commits at ffffffffa05ec91d [reiserfs]
       #5 [ffff8802244c3e08] process_one_work at ffffffff81073726
       #6 [ffff8802244c3e68] worker_thread at ffffffff81073eba
       #7 [ffff8802244c3ec8] kthread at ffffffff810782e0
       #8 [ffff8802244c3f48] kernel_thread_helper at ffffffff81450064
      crash> rd ffff8802244c3cc8 10
      ffff8802244c3cc8:  ffffffff814472b3 ffff880222f23250   .rD.....P2."....
      ffff8802244c3cd8:  0000000000000000 0000000000000286   ................
      ffff8802244c3ce8:  ffff8802244c3d30 ffff880220734d80   0=L$.....Ms ....
      ffff8802244c3cf8:  ffff880222e8f628 0000000000000000   (.."............
      ffff8802244c3d08:  0000000000000000 0000000000000002   ................
      crash> struct rt_mutex ffff880222e8f628
      struct rt_mutex {
        wait_lock = {
          raw_lock = {
            slock = 65537
          }
        },
        wait_list = {
          node_list = {
            next = 0xffff8802244c3d48,
            prev = 0xffff8802244c3d48
          }
        },
        owner = 0xffff880222f22c71,
        save_state = 0
      }
      crash> bt 0xffff880222f22c70
      PID: 10635  TASK: ffff880222f22c70  CPU: 3   COMMAND: "mount"
       #0 [ffff8802216a9868] schedule at ffffffff8144584b
       #1 [ffff8802216a9910] schedule_timeout at ffffffff81446865
       #2 [ffff8802216a99a0] wait_for_common at ffffffff81445f74
       #3 [ffff8802216a9a30] flush_work at ffffffff810712d3
       #4 [ffff8802216a9ab0] schedule_on_each_cpu at ffffffff81074463
       #5 [ffff8802216a9ae0] invalidate_bdev at ffffffff81178aba
       #6 [ffff8802216a9af0] vfs_load_quota_inode at ffffffff811a3632
       #7 [ffff8802216a9b50] dquot_quota_on_mount at ffffffff811a375c
       #8 [ffff8802216a9b80] finish_unfinished at ffffffffa05dd8b0 [reiserfs]
       #9 [ffff8802216a9cc0] reiserfs_fill_super at ffffffffa05de825 [reiserfs]
          RIP: 00007f7b9303997a  RSP: 00007ffff443c7a8  RFLAGS: 00010202
          RAX: 00000000000000a5  RBX: ffffffff8144ef12  RCX: 00007f7b932e9ee0
          RDX: 00007f7b93d9a400  RSI: 00007f7b93d9a3e0  RDI: 00007f7b93d9a3c0
          RBP: 00007f7b93d9a2c0   R8: 00007f7b93d9a550   R9: 0000000000000001
          R10: ffffffffc0ed040e  R11: 0000000000000202  R12: 000000000000040e
          R13: 0000000000000000  R14: 00000000c0ed040e  R15: 00007ffff443ca20
          ORIG_RAX: 00000000000000a5  CS: 0033  SS: 002b
      Signed-off-by: default avatarMike Galbraith <efault@gmx.de>
      Acked-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarMike Galbraith <mgalbraith@suse.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5c55afa3
    • Miklos Szeredi's avatar
      fuse: fix killing s[ug]id in setattr · 0e2993ef
      Miklos Szeredi authored
      commit a09f99eddef44035ec764075a37bace8181bec38 upstream.
      
      Fuse allowed VFS to set mode in setattr in order to clear suid/sgid on
      chown and truncate, and (since writeback_cache) write.  The problem with
      this is that it'll potentially restore a stale mode.
      
      The poper fix would be to let the filesystems do the suid/sgid clearing on
      the relevant operations.  Possibly some are already doing it but there's no
      way we can detect this.
      
      So fix this by refreshing and recalculating the mode.  Do this only if
      ATTR_KILL_S[UG]ID is set to not destroy performance for writes.  This is
      still racy but the size of the window is reduced.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e2993ef
    • Miklos Szeredi's avatar
      fuse: invalidate dir dentry after chmod · f72bae37
      Miklos Szeredi authored
      commit 5e2b8828ff3d79aca8c3a1730652758753205b61 upstream.
      
      Without "default_permissions" the userspace filesystem's lookup operation
      needs to perform the check for search permission on the directory.
      
      If directory does not allow search for everyone (this is quite rare) then
      userspace filesystem has to set entry timeout to zero to make sure
      permissions are always performed.
      
      Changing the mode bits of the directory should also invalidate the
      (previously cached) dentry to make sure the next lookup will have a chance
      of updating the timeout, if needed.
      Reported-by: default avatarJean-Pierre André <jean-pierre.andre@wanadoo.fr>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f72bae37
    • Miklos Szeredi's avatar
      fuse: listxattr: verify xattr list · 66b8e7fc
      Miklos Szeredi authored
      commit cb3ae6d25a5471be62bfe6ac1fccc0e91edeaba0 upstream.
      
      Make sure userspace filesystem is returning a well formed list of xattr
      names (zero or more nonzero length, null terminated strings).
      
      [Michael Theall: only verify in the nonzero size case]
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66b8e7fc
    • Junjie Mao's avatar
      btrfs: assign error values to the correct bio structs · f22a8a5c
      Junjie Mao authored
      commit 14155cafeadda946376260e2ad5d39a0528a332f upstream.
      
      Fixes: 4246a0b6 ("block: add a bi_error field to struct bio")
      Signed-off-by: default avatarJunjie Mao <junjie.mao@enight.me>
      Acked-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f22a8a5c
    • Omar Sandoval's avatar
      Btrfs: catch invalid free space trees · 1092e303
      Omar Sandoval authored
      commit 6675df311db87aa2107a04ef97e19420953cbace upstream.
      
      There are two separate issues that can lead to corrupted free space
      trees.
      
      1. The free space tree bitmaps had an endianness issue on big-endian
         systems which is fixed by an earlier patch in this series.
      2. btrfs-progs before v4.7.3 modified filesystems without updating the
         free space tree.
      
      To catch both of these issues at once, we need to force the free space
      tree to be rebuilt. To do so, add a FREE_SPACE_TREE_VALID compat_ro bit.
      If the bit isn't set, we know that it was either produced by a broken
      big-endian kernel or may have been corrupted by btrfs-progs.
      
      This also provides us with a way to add rudimentary read-write support
      for the free space tree to btrfs-progs: it can just clear this bit and
      have the kernel rebuild the free space tree.
      Tested-by: default avatarHolger Hoffstätte <holger@applied-asynchrony.com>
      Tested-by: default avatarChandan Rajendra <chandan@linux.vnet.ibm.com>
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1092e303
    • Omar Sandoval's avatar
      Btrfs: fix mount -o clear_cache,space_cache=v2 · 6691ebee
      Omar Sandoval authored
      commit f8d468a15c22b954b379aa0c74914d5068448fb1 upstream.
      
      We moved the code for creating the free space tree the first time that
      it's enabled, but didn't move the clearing code along with it. This
      breaks my (undocumented) intention that `mount -o
      clear_cache,space_cache=v2` would clear the free space tree and then
      recreate it.
      
      Fixes: 511711af ("btrfs: don't run delayed references while we are creating the free space tree")
      Tested-by: default avatarHolger Hoffstätte <holger@applied-asynchrony.com>
      Tested-by: default avatarChandan Rajendra <chandan@linux.vnet.ibm.com>
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6691ebee
    • Omar Sandoval's avatar
      Btrfs: fix free space tree bitmaps on big-endian systems · 1ff6341b
      Omar Sandoval authored
      commit 2fe1d55134fce05c17ea118a2e37a4af771887bc upstream.
      
      In convert_free_space_to_{bitmaps,extents}(), we buffer the free space
      bitmaps in memory and copy them directly to/from the extent buffers with
      {read,write}_extent_buffer(). The extent buffer bitmap helpers use byte
      granularity, which is equivalent to a little-endian bitmap. This means
      that on big-endian systems, the in-memory bitmaps will be written to
      disk byte-swapped. To fix this, use byte-granularity for the bitmaps in
      memory.
      
      Fixes: a5ed9182 ("Btrfs: implement the free space B-tree")
      Tested-by: default avatarHolger Hoffstätte <holger@applied-asynchrony.com>
      Tested-by: default avatarChandan Rajendra <chandan@linux.vnet.ibm.com>
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ff6341b
    • Christian Lamparter's avatar
      debugfs: introduce a public file_operations accessor · 7c646634
      Christian Lamparter authored
      commit 86f0e06767dda7863d6d2a8f0b3b857e6ea876a0 upstream.
      
      This patch introduces an accessor which can be used
      by the users of debugfs (drivers, fs, ...) to get the
      original file_operations struct. It also removes the
      REAL_FOPS_DEREF macro in file.c and converts the code
      to use the public version.
      
      Previously, REAL_FOPS_DEREF was only available within
      the file.c of debugfs. But having a public getter
      available for debugfs users is important as some
      drivers (carl9170 and b43) use the pointer of the
      original file_operations in conjunction with container_of()
      within their debugfs implementations.
      Reviewed-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c646634
  4. 20 Oct, 2016 1 commit
    • Artem Savkov's avatar
      Make __xfs_xattr_put_listen preperly report errors. · 0312017c
      Artem Savkov authored
      commit 791cc43b36eb1f88166c8505900cad1b43c7fe1a upstream.
      
      Commit 2a6fba6d "xfs: only return -errno or success from attr ->put_listent"
      changes the returnvalue of __xfs_xattr_put_listen to 0 in case when there is
      insufficient space in the buffer assuming that setting context->count to -1
      would be enough, but all of the ->put_listent callers only check seen_enough.
      This results in a failed assertion:
      XFS: Assertion failed: context->count >= 0, file: fs/xfs/xfs_xattr.c, line: 175
      in insufficient buffer size case.
      
      This is only reproducible with at least 2 xattrs and only when the buffer
      gets depleted before the last one.
      
      Furthermore if buffersize is such that it is enough to hold the last xattr's
      name, but not enough to hold the sum of preceeding xattr names listxattr won't
      fail with ERANGE, but will suceed returning last xattr's name without the
      first character. The first character end's up overwriting data stored at
      (context->alist - 1).
      Signed-off-by: default avatarArtem Savkov <asavkov@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Cc: Eric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0312017c
  5. 30 Sep, 2016 1 commit
    • Eric Ren's avatar
      ocfs2: fix deadlock on mmapped page in ocfs2_write_begin_nolock() · c33f0785
      Eric Ren authored
      The testcase "mmaptruncate" of ocfs2-test deadlocks occasionally.
      
      In this testcase, we create a 2*CLUSTER_SIZE file and mmap() on it;
      there are 2 process repeatedly performing the following operations
      respectively: one is doing memset(mmaped_addr + 2*CLUSTER_SIZE - 1, 'a',
      1), while the another is playing ftruncate(fd, 2*CLUSTER_SIZE) and then
      ftruncate(fd, CLUSTER_SIZE) again and again.
      
      This is the backtrace when the deadlock happens:
      
         __wait_on_bit_lock+0x50/0xa0
         __lock_page+0xb7/0xc0
         ocfs2_write_begin_nolock+0x163f/0x1790 [ocfs2]
         ocfs2_page_mkwrite+0x1c7/0x2a0 [ocfs2]
         do_page_mkwrite+0x66/0xc0
         handle_mm_fault+0x685/0x1350
         __do_page_fault+0x1d8/0x4d0
         trace_do_page_fault+0x37/0xf0
         do_async_page_fault+0x19/0x70
         async_page_fault+0x28/0x30
      
      In ocfs2_write_begin_nolock(), we first grab the pages and then allocate
      disk space for this write; ocfs2_try_to_free_truncate_log() will be
      called if -ENOSPC is returned; if we're lucky to get enough clusters,
      which is usually the case, we start over again.
      
      But in ocfs2_free_write_ctxt() the target page isn't unlocked, so we
      will deadlock when trying to grab the target page again.
      
      Also, -ENOMEM might be returned in ocfs2_grab_pages_for_write().
      Another deadlock will happen in __do_page_mkwrite() if
      ocfs2_page_mkwrite() returns non-VM_FAULT_LOCKED, and along with a
      locked target page.
      
      These two errors fail on the same path, so fix them by unlocking the
      target page manually before ocfs2_free_write_ctxt().
      
      Jan Kara helps me clear out the JBD2 part, and suggest the hint for root
      cause.
      
      Changes since v1:
      1. Also put ENOMEM error case into consideration.
      
      Link: http://lkml.kernel.org/r/1474173902-32075-1-git-send-email-zren@suse.comSigned-off-by: default avatarEric Ren <zren@suse.com>
      Reviewed-by: default avatarHe Gang <ghe@suse.com>
      Acked-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c33f0785
  6. 21 Sep, 2016 2 commits
  7. 20 Sep, 2016 2 commits
  8. 19 Sep, 2016 7 commits
    • Junxiao Bi's avatar
      Revert "ocfs2: bump up o2cb network protocol version" · 63b52c49
      Junxiao Bi authored
      This reverts commit 38b52efd ("ocfs2: bump up o2cb network protocol
      version").
      
      This commit made rolling upgrade fail.  When one node is upgraded to new
      version with this commit, the remaining nodes will fail to establish
      connections to it, then the application like VMs on the remaining nodes
      can't be live migrated to the upgraded one.  This will cause an outage.
      Since negotiate hb timeout behavior didn't change without this commit,
      so revert it.
      
      Fixes: 38b52efd ("ocfs2: bump up o2cb network protocol version")
      Link: http://lkml.kernel.org/r/1471396924-10375-1-git-send-email-junxiao.bi@oracle.comSigned-off-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Joseph Qi <joseph.qi@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      63b52c49
    • Ashish Samant's avatar
      ocfs2: fix start offset to ocfs2_zero_range_for_truncate() · d21c353d
      Ashish Samant authored
      If we punch a hole on a reflink such that following conditions are met:
      
      1. start offset is on a cluster boundary
      2. end offset is not on a cluster boundary
      3. (end offset is somewhere in another extent) or
         (hole range > MAX_CONTIG_BYTES(1MB)),
      
      we dont COW the first cluster starting at the start offset.  But in this
      case, we were wrongly passing this cluster to
      ocfs2_zero_range_for_truncate() to zero out.  This will modify the
      cluster in place and zero it in the source too.
      
      Fix this by skipping this cluster in such a scenario.
      
      To reproduce:
      
      1. Create a random file of say 10 MB
           xfs_io -c 'pwrite -b 4k 0 10M' -f 10MBfile
      2. Reflink  it
           reflink -f 10MBfile reflnktest
      3. Punch a hole at starting at cluster boundary  with range greater that
      1MB. You can also use a range that will put the end offset in another
      extent.
           fallocate -p -o 0 -l 1048615 reflnktest
      4. sync
      5. Check the  first cluster in the source file. (It will be zeroed out).
          dd if=10MBfile iflag=direct bs=<cluster size> count=1 | hexdump -C
      
      Link: http://lkml.kernel.org/r/1470957147-14185-1-git-send-email-ashish.samant@oracle.comSigned-off-by: default avatarAshish Samant <ashish.samant@oracle.com>
      Reported-by: default avatarSaar Maoz <saar.maoz@oracle.com>
      Reviewed-by: default avatarSrinivas Eeda <srinivas.eeda@oracle.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <joseph.qi@huawei.com>
      Cc: Eric Ren <zren@suse.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d21c353d
    • Joseph Qi's avatar
      ocfs2: fix double unlock in case retry after free truncate log · 3bb8b653
      Joseph Qi authored
      If ocfs2_reserve_cluster_bitmap_bits() fails with ENOSPC, it will try to
      free truncate log and then retry.  Since ocfs2_try_to_free_truncate_log
      will lock/unlock global bitmap inode, we have to unlock it before
      calling this function.  But when retry reserve and it fails with no
      global bitmap inode lock taken, it will unlock again in error handling
      branch and BUG.
      
      This issue also exists if no need retry and then ocfs2_inode_lock fails.
      So fix it.
      
      Fixes: 2070ad1a ("ocfs2: retry on ENOSPC if sufficient space in truncate log")
      Link: http://lkml.kernel.org/r/57D91939.6030809@huawei.comSigned-off-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Signed-off-by: default avatarJiufei Xue <xuejiufei@huawei.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3bb8b653
    • Jan Kara's avatar
      fanotify: fix list corruption in fanotify_get_response() · 96d41019
      Jan Kara authored
      fanotify_get_response() calls fsnotify_remove_event() when it finds that
      group is being released from fanotify_release() (bypass_perm is set).
      
      However the event it removes need not be only in the group's notification
      queue but it can have already moved to access_list (userspace read the
      event before closing the fanotify instance fd) which is protected by a
      different lock.  Thus when fsnotify_remove_event() races with
      fanotify_release() operating on access_list, the list can get corrupted.
      
      Fix the problem by moving all the logic removing permission events from
      the lists to one place - fanotify_release().
      
      Fixes: 5838d444 ("fanotify: fix double free of pending permission events")
      Link: http://lkml.kernel.org/r/1473797711-14111-3-git-send-email-jack@suse.czSigned-off-by: default avatarJan Kara <jack@suse.cz>
      Reported-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Tested-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Reviewed-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      96d41019
    • Jan Kara's avatar
      fsnotify: add a way to stop queueing events on group shutdown · 12703dbf
      Jan Kara authored
      Implement a function that can be called when a group is being shutdown
      to stop queueing new events to the group.  Fanotify will use this.
      
      Fixes: 5838d444 ("fanotify: fix double free of pending permission events")
      Link: http://lkml.kernel.org/r/1473797711-14111-2-git-send-email-jack@suse.czSigned-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      12703dbf
    • Junxiao Bi's avatar
      ocfs2: fix trans extend while free cached blocks · d5bf1418
      Junxiao Bi authored
      The root cause of this issue is the same with the one fixed by the last
      patch, but this time credits for allocator inode and group descriptor
      may not be consumed before trans extend.
      
      The following error was caught:
      
        WARNING: CPU: 0 PID: 2037 at fs/jbd2/transaction.c:269 start_this_handle+0x4c3/0x510 [jbd2]()
        Modules linked in: ocfs2 nfsd lockd grace nfs_acl auth_rpcgss sunrpc autofs4 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sd_mod sg ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ppdev xen_kbdfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_netfront parport_pc parport pcspkr i2c_piix4 i2c_core acpi_cpufreq ext4 jbd2 mbcache xen_blkfront floppy pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod
        CPU: 0 PID: 2037 Comm: rm Tainted: G        W       4.1.12-37.6.3.el6uek.bug24573128v2.x86_64 #2
        Hardware name: Xen HVM domU, BIOS 4.4.4OVM 02/11/2016
        Call Trace:
          dump_stack+0x48/0x5c
          warn_slowpath_common+0x95/0xe0
          warn_slowpath_null+0x1a/0x20
          start_this_handle+0x4c3/0x510 [jbd2]
          jbd2__journal_restart+0x161/0x1b0 [jbd2]
          jbd2_journal_restart+0x13/0x20 [jbd2]
          ocfs2_extend_trans+0x74/0x220 [ocfs2]
          ocfs2_free_cached_blocks+0x16b/0x4e0 [ocfs2]
          ocfs2_run_deallocs+0x70/0x270 [ocfs2]
          ocfs2_commit_truncate+0x474/0x6f0 [ocfs2]
          ocfs2_truncate_for_delete+0xbd/0x380 [ocfs2]
          ocfs2_wipe_inode+0x136/0x6a0 [ocfs2]
          ocfs2_delete_inode+0x2a2/0x3e0 [ocfs2]
          ocfs2_evict_inode+0x28/0x60 [ocfs2]
          evict+0xab/0x1a0
          iput_final+0xf6/0x190
          iput+0xc8/0xe0
          do_unlinkat+0x1b7/0x310
          SyS_unlinkat+0x22/0x40
          system_call_fastpath+0x12/0x71
        ---[ end trace a62437cb060baa71 ]---
        JBD2: rm wants too many credits (149 > 128)
      
      Link: http://lkml.kernel.org/r/1473674623-11810-2-git-send-email-junxiao.bi@oracle.comSigned-off-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d5bf1418
    • Junxiao Bi's avatar
      ocfs2: fix trans extend while flush truncate log · 2b0ad008
      Junxiao Bi authored
      Every time, ocfs2_extend_trans() included a credit for truncate log
      inode, but as that inode had been managed by jbd2 running transaction
      first time, it will not consume that credit until
      jbd2_journal_restart().
      
      Since total credits to extend always included the un-consumed ones,
      there will be more and more un-consumed credit, at last
      jbd2_journal_restart() will fail due to credit number over the half of
      max transction credit.
      
      The following error was caught when unlinking a large file with many
      extents:
      
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 13626 at fs/jbd2/transaction.c:269 start_this_handle+0x4c3/0x510 [jbd2]()
        Modules linked in: ocfs2 nfsd lockd grace nfs_acl auth_rpcgss sunrpc autofs4 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sd_mod sg ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ppdev xen_kbdfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea parport_pc parport pcspkr i2c_piix4 i2c_core acpi_cpufreq ext4 jbd2 mbcache xen_blkfront floppy pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod
        CPU: 0 PID: 13626 Comm: unlink Tainted: G        W       4.1.12-37.6.3.el6uek.x86_64 #2
        Hardware name: Xen HVM domU, BIOS 4.4.4OVM 02/11/2016
        Call Trace:
          dump_stack+0x48/0x5c
          warn_slowpath_common+0x95/0xe0
          warn_slowpath_null+0x1a/0x20
          start_this_handle+0x4c3/0x510 [jbd2]
          jbd2__journal_restart+0x161/0x1b0 [jbd2]
          jbd2_journal_restart+0x13/0x20 [jbd2]
          ocfs2_extend_trans+0x74/0x220 [ocfs2]
          ocfs2_replay_truncate_records+0x93/0x360 [ocfs2]
          __ocfs2_flush_truncate_log+0x13e/0x3a0 [ocfs2]
          ocfs2_remove_btree_range+0x458/0x7f0 [ocfs2]
          ocfs2_commit_truncate+0x1b3/0x6f0 [ocfs2]
          ocfs2_truncate_for_delete+0xbd/0x380 [ocfs2]
          ocfs2_wipe_inode+0x136/0x6a0 [ocfs2]
          ocfs2_delete_inode+0x2a2/0x3e0 [ocfs2]
          ocfs2_evict_inode+0x28/0x60 [ocfs2]
          evict+0xab/0x1a0
          iput_final+0xf6/0x190
          iput+0xc8/0xe0
          do_unlinkat+0x1b7/0x310
          SyS_unlink+0x16/0x20
          system_call_fastpath+0x12/0x71
        ---[ end trace 28aa7410e69369cf ]---
        JBD2: unlink wants too many credits (251 > 128)
      
      Link: http://lkml.kernel.org/r/1473674623-11810-1-git-send-email-junxiao.bi@oracle.comSigned-off-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2b0ad008