From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [WTFoTW] ->quota_on() deadlocks Date: Fri, 2 Jul 2010 22:13:58 +0200 Message-ID: <20100702201357.GC3583@quack.suse.cz> References: <20100701185629.GJ31073@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, Jan Kara , Joel Becker , Christoph Hellwig To: Al Viro Return-path: Received: from cantor2.suse.de ([195.135.220.15]:52856 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757575Ab0GBUOW (ORCPT ); Fri, 2 Jul 2010 16:14:22 -0400 Content-Disposition: inline In-Reply-To: <20100701185629.GJ31073@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu 01-07-10 19:56:29, Al Viro wrote: > All quotactl callbacks are done with s_umount held shared. > Fine, but ->quota_on() will do kern_path() and _that_ can try to > grab the same thing exclusive - suppose we pass a pathname that > walks into autofs and triggers mounting of the same fs (at a different > mountpoint, that is). That'll end up calling sget(), finding our > superblock and trying to grab s_umount on it. mount(8) sits > uninterruptibly sleeping in mount(2), kern_path() waits for it > to complete and that's not going to happen until the caller of > kern_path() (do_quotactl(), ultimately) finishes. > > Obvious solution is b0rken - we _can't_ take the call of > kern_path() to a point prior to getting (and locking) the superblock. > Why? Because ocfs2 ignores the pathname argument, so failing on > bogus pathnames will blow the userland API compatibility. > > Other alternatives are also not particulary pleasant since > we need s_umount at some point there - we want some exclusion with > remounting. > > Ideas? Not now :(. I'm on vacation this and next week. I'll look into the bug when I return. Honza -- Jan Kara SUSE Labs, CR