• Kent Overstreet's avatar
    bcachefs: Fix snapshot_create_lock lock ordering · e0cb5722
    Kent Overstreet authored
    ======================================================
    WARNING: possible circular locking dependency detected
    6.10.0-rc2-ktest-00018-gebd1d148b278 #144 Not tainted
    ------------------------------------------------------
    fio/1345 is trying to acquire lock:
    ffff88813e200ab8 (&c->snapshot_create_lock){++++}-{3:3}, at: bch2_truncate+0x76/0xf0
    
    but task is already holding lock:
    ffff888105a1fa38 (&sb->s_type->i_mutex_key#13){+.+.}-{3:3}, at: do_truncate+0x7b/0xc0
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 (&sb->s_type->i_mutex_key#13){+.+.}-{3:3}:
           down_write+0x3d/0xd0
           bch2_write_iter+0x1c0/0x10f0
           vfs_write+0x24a/0x560
           __x64_sys_pwrite64+0x77/0xb0
           x64_sys_call+0x17e5/0x1ab0
           do_syscall_64+0x68/0x130
           entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    -> #1 (sb_writers#10){.+.+}-{0:0}:
           mnt_want_write+0x4a/0x1d0
           filename_create+0x69/0x1a0
           user_path_create+0x38/0x50
           bch2_fs_file_ioctl+0x315/0xbf0
           __x64_sys_ioctl+0x297/0xaf0
           x64_sys_call+0x10cb/0x1ab0
           do_syscall_64+0x68/0x130
           entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    -> #0 (&c->snapshot_create_lock){++++}-{3:3}:
           __lock_acquire+0x1445/0x25b0
           lock_acquire+0xbd/0x2b0
           down_read+0x40/0x180
           bch2_truncate+0x76/0xf0
           bchfs_truncate+0x240/0x3f0
           bch2_setattr+0x7b/0xb0
           notify_change+0x322/0x4b0
           do_truncate+0x8b/0xc0
           do_ftruncate+0x110/0x270
           __x64_sys_ftruncate+0x43/0x80
           x64_sys_call+0x1373/0x1ab0
           do_syscall_64+0x68/0x130
           entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    other info that might help us debug this:
    
    Chain exists of:
      &c->snapshot_create_lock --> sb_writers#10 --> &sb->s_type->i_mutex_key#13
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&sb->s_type->i_mutex_key#13);
                                   lock(sb_writers#10);
                                   lock(&sb->s_type->i_mutex_key#13);
      rlock(&c->snapshot_create_lock);
    
     *** DEADLOCK ***
    Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
    e0cb5722
fs-ioctl.c 12.4 KB