From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756961AbaCECt6 (ORCPT ); Tue, 4 Mar 2014 21:49:58 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:58118 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754190AbaCECt4 (ORCPT ); Tue, 4 Mar 2014 21:49:56 -0500 X-Sasl-enc: svdU+Ynsz/OOUxL2PKA8kD6lLlmH6bOQ6f+nHTG8hblh 1393987795 Date: Tue, 4 Mar 2014 18:50:16 -0800 From: Greg KH To: Tejun Heo Cc: LKML , Sasha Levin Subject: Re: [PATCH driver-core-next] kernfs: cache atomic_write_len in kernfs_open_file Message-ID: <20140305025016.GB18412@kroah.com> References: <53113485.2090407@oracle.com> <20140303223933.GC26523@mtj.dyndns.org> <531505E4.8020802@oracle.com> <20140303224609.GF26523@mtj.dyndns.org> <20140304203846.GB2204@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140304203846.GB2204@htj.dyndns.org> User-Agent: Mutt/1.5.22 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 04, 2014 at 03:38:46PM -0500, Tejun Heo wrote: > While implementing atomic_write_len, 4d3773c4bb41 ("kernfs: implement > kernfs_ops->atomic_write_len") moved data copy from userland inside > kernfs_get_active() and kernfs_open_file->mutex so that > kernfs_ops->atomic_write_len can be accessed before copying buffer > from userland; unfortunately, this could lead to locking order > inversion involving mmap_sem if copy_from_user() takes a page fault. > > ====================================================== > [ INFO: possible circular locking dependency detected ] > 3.14.0-rc4-next-20140228-sasha-00011-g4077c67-dirty #26 Tainted: G W > ------------------------------------------------------- > trinity-c236/10658 is trying to acquire lock: > (&of->mutex#2){+.+.+.}, at: [] kernfs_fop_mmap+0x54/0x120 > > but task is already holding lock: > (&mm->mmap_sem){++++++}, at: [] vm_mmap_pgoff+0x6e/0xe0 > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #1 (&mm->mmap_sem){++++++}: > [] validate_chain+0x6c5/0x7b0 > [] __lock_acquire+0x4cd/0x5a0 > [] lock_acquire+0x182/0x1d0 > [] might_fault+0x7e/0xb0 > [] kernfs_fop_write+0xd8/0x190 > [] vfs_write+0xe3/0x1d0 > [] SyS_write+0x5d/0xa0 > [] tracesys+0xdd/0xe2 > > -> #0 (&of->mutex#2){+.+.+.}: > [] check_prev_add+0x13f/0x560 > [] validate_chain+0x6c5/0x7b0 > [] __lock_acquire+0x4cd/0x5a0 > [] lock_acquire+0x182/0x1d0 > [] mutex_lock_nested+0x6a/0x510 > [] kernfs_fop_mmap+0x54/0x120 > [] mmap_region+0x310/0x5c0 > [] do_mmap_pgoff+0x385/0x430 > [] vm_mmap_pgoff+0x8f/0xe0 > [] SyS_mmap_pgoff+0x1b0/0x210 > [] SyS_mmap+0x1d/0x20 > [] tracesys+0xdd/0xe2 > > other info that might help us debug this: > > Possible unsafe locking scenario: > > CPU0 CPU1 > ---- ---- > lock(&mm->mmap_sem); > lock(&of->mutex#2); > lock(&mm->mmap_sem); > lock(&of->mutex#2); > > *** DEADLOCK *** > > 1 lock held by trinity-c236/10658: > #0: (&mm->mmap_sem){++++++}, at: [] vm_mmap_pgoff+0x6e/0xe0 > > stack backtrace: > CPU: 2 PID: 10658 Comm: trinity-c236 Tainted: G W 3.14.0-rc4-next-20140228-sasha-00011-g4077c67-dirty #26 > 0000000000000000 ffff88011911fa48 ffffffff8438e945 0000000000000000 > 0000000000000000 ffff88011911fa98 ffffffff811a0109 ffff88011911fab8 > ffff88011911fab8 ffff88011911fa98 ffff880119128cc0 ffff880119128cf8 > Call Trace: > [] dump_stack+0x52/0x7f > [] print_circular_bug+0x129/0x160 > [] check_prev_add+0x13f/0x560 > [] ? deactivate_slab+0x511/0x550 > [] validate_chain+0x6c5/0x7b0 > [] __lock_acquire+0x4cd/0x5a0 > [] ? mmap_region+0x24a/0x5c0 > [] lock_acquire+0x182/0x1d0 > [] ? kernfs_fop_mmap+0x54/0x120 > [] mutex_lock_nested+0x6a/0x510 > [] ? kernfs_fop_mmap+0x54/0x120 > [] ? get_parent_ip+0x11/0x50 > [] ? kernfs_fop_mmap+0x54/0x120 > [] kernfs_fop_mmap+0x54/0x120 > [] mmap_region+0x310/0x5c0 > [] do_mmap_pgoff+0x385/0x430 > [] ? vm_mmap_pgoff+0x6e/0xe0 > [] vm_mmap_pgoff+0x8f/0xe0 > [] ? __rcu_read_unlock+0x44/0xb0 > [] ? dup_fd+0x3c0/0x3c0 > [] SyS_mmap_pgoff+0x1b0/0x210 > [] SyS_mmap+0x1d/0x20 > [] tracesys+0xdd/0xe2 > > Fix it by caching atomic_write_len in kernfs_open_file during open so > that it can be determined without accessing kernfs_ops in > kernfs_fop_write(). This restores the structure of kernfs_fop_write() > before 4d3773c4bb41 with updated @len determination logic. > > Signed-off-by: Tejun Heo > Reported-by: Sasha Levin > References: http://lkml.kernel.org/g/53113485.2090407@oracle.com > --- > fs/kernfs/file.c | 63 ++++++++++++++++++++++++------------------------- > include/linux/kernfs.h | 1 > 2 files changed, 33 insertions(+), 31 deletions(-) This is for 3.15, right? thanks, greg k-h