linux-kernel - Re: [PATCH 02/32] ext4: fix lockdep warning about recursive inode locking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 21 Jun 2017 21:18:34 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Tahsin Erdogan <tahsin@...gle.com>
Cc:     Andreas Dilger <adilger@...ger.ca>,
        "Darrick J . Wong" <darrick.wong@...cle.com>,
        Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/32] ext4: fix lockdep warning about recursive inode
 locking

On Wed, Jun 21, 2017 at 02:21:12PM -0700, Tahsin Erdogan wrote:
> Setting a large xattr value may require writing the attribute contents
> to an external inode. In this case we may need to lock the xattr inode
> along with the parent inode. This doesn't pose a deadlock risk because
> xattr inodes are not directly visible to the user and their access is
> restricted.
> 
> Assign a lockdep subclass to xattr inode's lock.
> 
>  ============================================
>  WARNING: possible recursive locking detected
>  4.12.0-rc1+ #740 Not tainted
>  --------------------------------------------
>  python/1822 is trying to acquire lock:
>   (&sb->s_type->i_mutex_key#15){+.+...}, at: [<ffffffff804912ca>] ext4_xattr_set_entry+0x65a/0x7b0
> 
>  but task is already holding lock:
>   (&sb->s_type->i_mutex_key#15){+.+...}, at: [<ffffffff803d6687>] vfs_setxattr+0x57/0xb0
> 
>  other info that might help us debug this:
>   Possible unsafe locking scenario:
> 
>         CPU0
>         ----
>    lock(&sb->s_type->i_mutex_key#15);
>    lock(&sb->s_type->i_mutex_key#15);
> 
>   *** DEADLOCK ***
> 
>   May be due to missing lock nesting notation
> 
>  4 locks held by python/1822:
>   #0:  (sb_writers#10){.+.+.+}, at: [<ffffffff803d0eef>] mnt_want_write+0x1f/0x50
>   #1:  (&sb->s_type->i_mutex_key#15){+.+...}, at: [<ffffffff803d6687>] vfs_setxattr+0x57/0xb0
>   #2:  (jbd2_handle){.+.+..}, at: [<ffffffff80493f40>] start_this_handle+0xf0/0x420
>   #3:  (&ei->xattr_sem){++++..}, at: [<ffffffff804920ba>] ext4_xattr_set_handle+0x9a/0x4f0
> 
>  stack backtrace:
>  CPU: 0 PID: 1822 Comm: python Not tainted 4.12.0-rc1+ #740
>  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  Call Trace:
>   dump_stack+0x67/0x9e
>   __lock_acquire+0x5f3/0x1750
>   lock_acquire+0xb5/0x1d0
>   down_write+0x2c/0x60
>   ext4_xattr_set_entry+0x65a/0x7b0
>   ext4_xattr_block_set+0x1b2/0x9b0
>   ext4_xattr_set_handle+0x322/0x4f0
>   ext4_xattr_set+0x144/0x1a0
>   ext4_xattr_user_set+0x34/0x40
>   __vfs_setxattr+0x66/0x80
>   __vfs_setxattr_noperm+0x69/0x1c0
>   vfs_setxattr+0xa2/0xb0
>   setxattr+0x12e/0x150
>   path_setxattr+0x87/0xb0
>   SyS_setxattr+0xf/0x20
>   entry_SYSCALL_64_fastpath+0x18/0xad
> 
> Signed-off-by: Tahsin Erdogan <tahsin@...gle.com>

Thanks, applied.

					- Ted