From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751989AbdFVBSq (ORCPT ); Wed, 21 Jun 2017 21:18:46 -0400 Received: from imap.thunk.org ([74.207.234.97]:57330 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113AbdFVBSo (ORCPT ); Wed, 21 Jun 2017 21:18:44 -0400 Date: Wed, 21 Jun 2017 21:18:34 -0400 From: "Theodore Ts'o" To: Tahsin Erdogan Cc: Andreas Dilger , "Darrick J . Wong" , Jan Kara , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 02/32] ext4: fix lockdep warning about recursive inode locking Message-ID: <20170622011834.kvbsjvcpit233n5d@thunk.org> Mail-Followup-To: Theodore Ts'o , Tahsin Erdogan , Andreas Dilger , "Darrick J . Wong" , Jan Kara , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org References: <20170621212142.16581-1-tahsin@google.com> <20170621212142.16581-2-tahsin@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170621212142.16581-2-tahsin@google.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: [] ext4_xattr_set_entry+0x65a/0x7b0 > > but task is already holding lock: > (&sb->s_type->i_mutex_key#15){+.+...}, at: [] 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: [] mnt_want_write+0x1f/0x50 > #1: (&sb->s_type->i_mutex_key#15){+.+...}, at: [] vfs_setxattr+0x57/0xb0 > #2: (jbd2_handle){.+.+..}, at: [] start_this_handle+0xf0/0x420 > #3: (&ei->xattr_sem){++++..}, at: [] 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 Thanks, applied. - Ted