From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [cgroup or VFS ?] INFO: possible recursive locking detected Date: Tue, 10 Feb 2009 09:32:35 +0100 Message-ID: <1234254755.4893.3.camel@laptop> References: <49617D2E.8050502@cn.fujitsu.com> <496576E7.1@cn.fujitsu.com> <20090209112321.GW28946@ZenIV.linux.org.uk> <1234180131.5951.85.camel@laptop> <4990EF3F.3010501@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Al Viro , LKML , Andrew Morton , Paul Menage , Arjan van de Ven , linux-fsdevel@vger.kernel.org To: Li Zefan Return-path: Received: from casper.infradead.org ([85.118.1.10]:58997 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750772AbZBJIco (ORCPT ); Tue, 10 Feb 2009 03:32:44 -0500 In-Reply-To: <4990EF3F.3010501@cn.fujitsu.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 2009-02-10 at 11:06 +0800, Li Zefan wrote: > > It seems to me we can simply put the new s_umount instance in a > > different subclass. Its a bit unusual to use _nested for the outer lock, > > but lockdep doesn't particularly cares about subclass order. > > > > If there's any issue with the callers of sget() assuming the s_umount > > lock being of sublcass 0, then there is another annotation we can use to > > fix that, but lets not bother with that if this is sufficient. > > > > Signed-off-by: Peter Zijlstra > > Tested-by: Li Zefan > > Thanks! > > a minor comment > > > + * lock of the old one. Since these are clearly distrinct > > s/distrinct/distinct Yes, someone else was kind enough to point that out as well :-) Al, do you want a resend or will you fix that up when you add the patch to your queue? > BTW, I found another bug in current code: Yep, looks good, freeing held locks makes lockdep unhappy. > From: Li Zefan > Date: Tue, 10 Feb 2009 10:55:53 +0800 > Subject: [PATCH] vfs: add missing unlock in sget() > > We should release s->s_umount before calling destroy_super(s). > > Signed-off-by: Li Zefan > ---