Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757211Ab3CRVxq (ORCPT ); Mon, 18 Mar 2013 17:53:46 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:51364 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755302Ab3CRVxn (ORCPT ); Mon, 18 Mar 2013 17:53:43 -0400 Date: Mon, 18 Mar 2013 21:53:34 +0000 From: Al Viro To: Jan Kara Cc: David Howells , Miklos Szeredi , 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 Message-ID: <20130318215333.GE21522@ZenIV.linux.org.uk> References: <1363184193-1796-3-git-send-email-miklos@szeredi.hu> <1363184193-1796-1-git-send-email-miklos@szeredi.hu> <1944.1363525619@warthog.procyon.org.uk> <20130318153936.GB28508@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130318153936.GB28508@quack.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1309 Lines: 28 On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote: > IMO the deadlock is real. In freeze_super() we wait for all writers to > the filesystem to finish while blocking beginning of any further writes. So > we have a deadlock scenario like: > > THREAD1 THREAD2 THREAD3 > mnt_want_write() mutex_lock(&inode->i_mutex); > ... freeze_super() > block on mutex_lock(&inode->i_mutex) > sb_wait_write(sb, SB_FREEZE_WRITE); > block in sb_start_write() The bug is on fsfreeze side and this is not the only problem related to it. I've missed the implications when I applied "fs: Add freezing handling to mnt_want_write() / mnt_drop_write()" last June ;-/ The thing is, until then mnt_want_write() used to be a counter; it could be nested. Now any such nesting is a deadlock you've just described. This is seriously wrong, IMO. BTW, having sb_start_write() buried in individual ->splice_write() is asking for trouble; could you describe the rules for that? E.g. where does it nest wrt filesystem-private locks? XFS iolock, for example... -- 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/