From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: BUG? deadlock bug at generic_shutdown_ Date: Wed, 29 Jul 2009 21:41:24 -0600 Message-ID: <20090730034124.GO3711@parisc-linux.org> References: <2014bcab0907292029o6617b6a7n944cbd28edd39c10@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: ?????? shin hong Return-path: Received: from palinux.external.hp.com ([192.25.206.14]:39607 "EHLO mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751903AbZG3DlY (ORCPT ); Wed, 29 Jul 2009 23:41:24 -0400 Content-Disposition: inline In-Reply-To: <2014bcab0907292029o6617b6a7n944cbd28edd39c10@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Jul 30, 2009 at 12:29:57PM +0900, ?????? shin hong wrote: > Hi. I am reporting a suspected deadlock bug. > > generic_shutdown_super() acquires lock_super(sb) > and then acquires lock_kernel(). It hasn't since commit a9e220f8322e2b0e0b8903fe00265461cffad3f0. Please work against a current kernel. > However, do_remount() acquires lock_super() while > it holds lock_kernel(). > > Therefore, concurrent execution of generic_shutdown_super() > and do_remount() may result deadlock. The reason this wasn't a problem before the commit above is that generic_shutdown_super() can never execute concurrently with do_remount. For generic_shutdown_super() to be called, there must be no remaining references to the super_block. do_remount() must hold a reference to the super_block. CONFIG_LOCKDEP finds lock inversion problems; I suspect you're wasting your time looking for them by hand. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."