From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [cgroup or VFS ?] INFO: possible recursive locking detected Date: Tue, 10 Feb 2009 04:37:33 +0000 Message-ID: <20090210043733.GY28946@ZenIV.linux.org.uk> 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; charset=us-ascii Cc: Peter Zijlstra , LKML , Andrew Morton , Paul Menage , Arjan van de Ven , linux-fsdevel@vger.kernel.org To: Li Zefan Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:50291 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750869AbZBJEhj (ORCPT ); Mon, 9 Feb 2009 23:37:39 -0500 Content-Disposition: inline In-Reply-To: <4990EF3F.3010501@cn.fujitsu.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Feb 10, 2009 at 11:06:39AM +0800, Li Zefan wrote: > BTW, I found another bug in current code: Why is that a bug? If _anything_ had been trying to acquire the rwsem in question, it would be fscked anyway. Not to mention that nothing could have ever seen that struct super_block in this particular case, as a general rule * if something might be blocked on your mutex/rwsem or spinning on a spinlock, releasing it before you free the object won't save your arse. You have no promise whatsoever that whoever's been trying to get the lock in question will even get out of the locking primitive before the memory that contains the lock gets freed. In case of superblocks in general, you don't free them until ->s_count hits zero. At that point anything as much as remembering the address of that superblock is already FUBAR.