Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756253Ab3CQNIN (ORCPT ); Sun, 17 Mar 2013 09:08:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21997 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753472Ab3CQNIL (ORCPT ); Sun, 17 Mar 2013 09:08:11 -0400 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <1363184193-1796-3-git-send-email-miklos@szeredi.hu> References: <1363184193-1796-3-git-send-email-miklos@szeredi.hu> <1363184193-1796-1-git-send-email-miklos@szeredi.hu> To: Miklos Szeredi , jack@suse.cz Cc: dhowells@redhat.com, viro@ZenIV.linux.org.uk, torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hch@infradead.org, akpm@linux-foundation.org, apw@canonical.com, nbd@openwrt.org, neilb@suse.de, jordipujolp@gmail.com, ezk@fsl.cs.sunysb.edu, sedat.dilek@googlemail.com, hooanon05@yahoo.co.jp, mszeredi@suse.cz Subject: Re: [PATCH 2/9] vfs: export do_splice_direct() to modules Date: Sun, 17 Mar 2013 13:06:59 +0000 Message-ID: <1944.1363525619@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2948 Lines: 76 Miklos Szeredi wrote: > Export do_splice_direct() to modules. Needed by overlay filesystem. Apparently you cannot call this from any function that is holding an i_mutex if the target of the splice uses generic_file_splice_write(). The problem is a potential deadlock situation: We have places already that do: mnt_want_write() mutex_lock() This can be found in do_last() for example. However, mnt_want_write() calls sb_start_write() as does generic_file_splice_write(). So now in ovl_copy_up_locked() you're adding: mutex_lock() sb_start_write() which lockdep reports as a potential ABBA deadlock. Now, looking at __sb_start_write(), I'm not entirely sure how the deadlock might operate, so it's possible that this is a false alarm. Maybe Jan Kara can illuminate further, so I've added him to the cc list. I've attached the report I got with unionmount. David --- [ INFO: possible recursive locking detected ] 3.9.0-rc1-fsdevel+ #934 Not tainted --------------------------------------------- fs-op/4476 is trying to acquire lock: (sb_writers#4){.+.+.+}, at: [] generic_file_splice_write+0x5d/0x14b but task is already holding lock: (sb_writers#4){.+.+.+}, at: [] mnt_want_write+0x1f/0x46 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(sb_writers#4); lock(sb_writers#4); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by fs-op/4476: #0: (sb_writers#4){.+.+.+}, at: [] mnt_want_write+0x1f/0x46 #1: (&type->i_mutex_dir_key[1]){+.+.+.}, at: [] __union_copy_up+0x9a/0x132 stack backtrace: Pid: 4476, comm: fs-op Not tainted 3.9.0-rc1-fsdevel+ #934 Call Trace: [] __lock_acquire+0x86a/0x16cf [] ? page_cache_pipe_buf_release+0x1b/0x1b [] lock_acquire+0x57/0x6d [] ? generic_file_splice_write+0x5d/0x14b [] __sb_start_write+0x10d/0x15d [] ? generic_file_splice_write+0x5d/0x14b [] generic_file_splice_write+0x5d/0x14b [] do_splice_from+0x74/0x91 [] direct_splice_actor+0x1e/0x20 [] splice_direct_to_actor+0xc2/0x17e [] ? do_splice_from+0x91/0x91 [] do_splice_direct+0x47/0x5a [] __union_copy_up_locked+0x171/0x2b2 [] __union_copy_up+0xea/0x132 [] vfs_truncate+0x15e/0x289 [] do_sys_truncate+0x46/0x83 [] sys_truncate+0x9/0xb [] system_call_fastpath+0x16/0x1b -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/