• Kees Cook's avatar
    pstore: Solve lockdep warning by moving inode locks · 3a7d2fd1
    Kees Cook authored
    Lockdep complains about a possible deadlock between mount and unlink
    (which is technically impossible), but fixing this improves possible
    future multiple-backend support, and keeps locking in the right order.
    
    The lockdep warning could be triggered by unlinking a file in the
    pstore filesystem:
    
      -> #1 (&sb->s_type->i_mutex_key#14){++++++}:
             lock_acquire+0xc9/0x220
             down_write+0x3f/0x70
             pstore_mkfile+0x1f4/0x460
             pstore_get_records+0x17a/0x320
             pstore_fill_super+0xa4/0xc0
             mount_single+0x89/0xb0
             pstore_mount+0x13/0x20
             mount_fs+0xf/0x90
             vfs_kern_mount+0x66/0x170
             do_mount+0x190/0xd50
             SyS_mount+0x90/0xd0
             entry_SYSCALL_64_fastpath+0x1c/0xb1
    
      -> #0 (&psinfo->read_mutex){+.+.+.}:
             __lock_acquire+0x1ac0/0x1bb0
             lock_acquire+0xc9/0x220
             __mutex_lock+0x6e/0x990
             mutex_lock_nested+0x16/0x20
             pstore_unlink+0x3f/0xa0
             vfs_unlink+0xb5/0x190
             do_unlinkat+0x24c/0x2a0
             SyS_unlinkat+0x16/0x30
             entry_SYSCALL_64_fastpath+0x1c/0xb1
    
      Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(&sb->s_type->i_mutex_key#14);
                                    lock(&psinfo->read_mutex);
                                    lock(&sb->s_type->i_mutex_key#14);
       lock(&psinfo->read_mutex);
    Reported-by: default avatarMarta Lofstedt <marta.lofstedt@intel.com>
    Reported-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: default avatarKees Cook <keescook@chromium.org>
    Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
    3a7d2fd1
inode.c 11.9 KB