Re: [PATCH] vfs: stop shrinker while fs is freezed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dave,

On 12/15/19 8:09 PM, Dave Chinner wrote:
On Fri, Dec 13, 2019 at 02:24:40PM -0800, Junxiao Bi wrote:
Shrinker could be blocked by freeze while dropping the last reference of
some inode that had been removed. As "s_umount" lock was acquired by the
Shrinker before blocked, the thaw will hung by this lock. This caused a
deadlock.

  crash7latest> set 132
      PID: 132
  COMMAND: "kswapd0:0"
     TASK: ffff9cdc9dfb5f00  [THREAD_INFO: ffff9cdc9dfb5f00]
      CPU: 6
    STATE: TASK_UNINTERRUPTIBLE
  crash7latest> bt
  PID: 132    TASK: ffff9cdc9dfb5f00  CPU: 6   COMMAND: "kswapd0:0"
   #0 [ffffaa5d075bf900] __schedule at ffffffff8186487c
   #1 [ffffaa5d075bf998] schedule at ffffffff81864e96
   #2 [ffffaa5d075bf9b0] rwsem_down_read_failed at ffffffff818689ee
   #3 [ffffaa5d075bfa40] call_rwsem_down_read_failed at ffffffff81859308
   #4 [ffffaa5d075bfa90] __percpu_down_read at ffffffff810ebd38
   #5 [ffffaa5d075bfab0] __sb_start_write at ffffffff812859ef
   #6 [ffffaa5d075bfad0] xfs_trans_alloc at ffffffffc07ebe9c [xfs]
   #7 [ffffaa5d075bfb18] xfs_free_eofblocks at ffffffffc07c39d1 [xfs]
   #8 [ffffaa5d075bfb80] xfs_inactive at ffffffffc07de878 [xfs]
   #9 [ffffaa5d075bfba0] __dta_xfs_fs_destroy_inode_3543 at ffffffffc07e885e [xfs]
  #10 [ffffaa5d075bfbd0] destroy_inode at ffffffff812a25de
  #11 [ffffaa5d075bfbe8] evict at ffffffff812a2b73
  #12 [ffffaa5d075bfc10] dispose_list at ffffffff812a2c1d
  #13 [ffffaa5d075bfc38] prune_icache_sb at ffffffff812a421a
  #14 [ffffaa5d075bfc70] super_cache_scan at ffffffff812870a1
  #15 [ffffaa5d075bfcc8] shrink_slab at ffffffff811eebb3
  #16 [ffffaa5d075bfdb0] shrink_node at ffffffff811f4788
  #17 [ffffaa5d075bfe38] kswapd at ffffffff811f58c3
  #18 [ffffaa5d075bff08] kthread at ffffffff810b75d5
  #19 [ffffaa5d075bff50] ret_from_fork at ffffffff81a0035e
How did you get a file that needed EOF block trimming to be disposed
of when the filesystem is frozen?

Part of freezing the filesystem is tossing all the reclaimable
inodes out of the cache, which means all the inodes that might
require EOF block trimming should have already been removed from the
cache before the freeze goes into effect....

This issue happened only once, don't know how it was triggered.

I am not xfs developer, don't know what EOF block mean. But this seemed a generic issue, destroy inode will engage the transaction on non-EOF blocks?


  crash7latest> set 31060
      PID: 31060
  COMMAND: "safefreeze"
     TASK: ffff9cd292868000  [THREAD_INFO: ffff9cd292868000]
      CPU: 2
    STATE: TASK_UNINTERRUPTIBLE
  crash7latest> bt
  PID: 31060  TASK: ffff9cd292868000  CPU: 2   COMMAND: "safefreeze"
   #0 [ffffaa5d10047c90] __schedule at ffffffff8186487c
   #1 [ffffaa5d10047d28] schedule at ffffffff81864e96
   #2 [ffffaa5d10047d40] rwsem_down_write_failed at ffffffff81868f18
   #3 [ffffaa5d10047dd8] call_rwsem_down_write_failed at ffffffff81859367
   #4 [ffffaa5d10047e20] down_write at ffffffff81867cfd
   #5 [ffffaa5d10047e38] thaw_super at ffffffff81285d2d
   #6 [ffffaa5d10047e60] do_vfs_ioctl at ffffffff81299566
   #7 [ffffaa5d10047ee8] sys_ioctl at ffffffff81299709
   #8 [ffffaa5d10047f28] do_syscall_64 at ffffffff81003949
   #9 [ffffaa5d10047f50] entry_SYSCALL_64_after_hwframe at ffffffff81a001ad
      RIP: 0000000000453d67  RSP: 00007ffff9c1ce78  RFLAGS: 00000206
      RAX: ffffffffffffffda  RBX: 0000000001cbe92c  RCX: 0000000000453d67
      RDX: 0000000000000000  RSI: 00000000c0045878  RDI: 0000000000000014
      RBP: 00007ffff9c1cf80   R8: 0000000000000000   R9: 0000000000000012
      R10: 0000000000000008  R11: 0000000000000206  R12: 0000000000401fb0
      R13: 0000000000402040  R14: 0000000000000000  R15: 0000000000000000
      ORIG_RAX: 0000000000000010  CS: 0033  SS: 002b

Signed-off-by: Junxiao Bi <junxiao.bi@xxxxxxxxxx>
---
  fs/super.c | 5 +++++
  1 file changed, 5 insertions(+)

diff --git a/fs/super.c b/fs/super.c
index cfadab2cbf35..adc18652302b 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -80,6 +80,11 @@ static unsigned long super_cache_scan(struct shrinker *shrink,
  	if (!trylock_super(sb))
  		return SHRINK_STOP;
+ if (sb->s_writers.frozen != SB_UNFROZEN) {
+		up_read(&sb->s_umount);
+		return SHRINK_STOP;
+	}
Ah, no. Now go run a filesystem traversal over a filesystem with a
few tens of million files in it while the filesystem is frozen, and
what the dentry and inode cache grow and grow until you run out of
memory....
Yea, this is an issue.

THe shrinker *needs* to run while the filesystem is frozen, but it
should not be tripping over files that need modification on
eviction. Working out how we got a file that required truncation
during eviction is the first thing to do here so we can then
determine if a) we should have caught it at freeze time, b) whether
it can be caught at freeze time, c) whether it can safely be skipped
during a freeze, or d) something else....

will think about it, thank you.

Thanks,

Junxiao.


Cheers,

Dave.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux