Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760599AbZIPXhX (ORCPT ); Wed, 16 Sep 2009 19:37:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755416AbZIPXhV (ORCPT ); Wed, 16 Sep 2009 19:37:21 -0400 Received: from ey-out-2122.google.com ([74.125.78.25]:19887 "EHLO ey-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754531AbZIPXhU convert rfc822-to-8bit (ORCPT ); Wed, 16 Sep 2009 19:37:20 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CaAaVkSDJTETjhD/iStgVOmk/LSSmg97HMh2YmC36BJlZ4W7jxZxOg7fULpQmkVVpH YI8+FjcUU8AaYX3S+YtgeqLBo+ePvL/QXoMWsubyQO5Di+nEUy3/FC4NXAt4lgPYd1T0 a8xNPKlyWneVjorz9Xf022OL4R5ahBc8UVOGk= MIME-Version: 1.0 In-Reply-To: <20090916203747.GB5068@nowhere> References: <1251167570-5233-1-git-send-email-fweisbec@gmail.com> <20090826201330.GA18761@orion> <20090914203749.GF6045@nowhere> <20090916203747.GB5068@nowhere> Date: Thu, 17 Sep 2009 03:37:22 +0400 Message-ID: Subject: Re: [PATCH 0/4] kill-the-bkl/reiserfs: fix some lock dependency inversions From: Alexander Beregalov To: Frederic Weisbecker Cc: LKML , Reiserfs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2743 Lines: 85 2009/9/17 Frederic Weisbecker : > On Tue, Sep 15, 2009 at 01:33:42AM +0400, Alexander Beregalov wrote: >> > Hi Alexander, >> > >> > It should be fixed now, still in the following tree: >> >> Hi! >> Another one, similar: >> It is v2.6.31-3123-g99bc470 plus your 805031859(kill-the-bkl/reiserfs: >> panic in case of lock imbalance), UP. > > > > Although I can't reproduce it, I think I see how that can happen. > > On mount time, we have the following dependency: > > reiserfs_lock -> bdev_mutex -> sysfs_mutex > > which happens while calling journal_init_dev() because > we open the device there. > > But also in case of mmap on a reiserfs filesystem we > may call reiserfs_readpages(), holding the reiserfs lock > while already holding mm->mmap_sem > > The above dependency is then updated: > > mmap_sem >     | >     | >     ------- reiserfs_lock -> bdev_mutex -> sysfs_mutex > > And later, while doing a readdir() on a sysfs directory, > sysfs calls filldir, which might_fault, and then might grab > mmap_sem. filldir is called there while holding sys_mutex, > creating the new following dependency > > sysfs_mutex -> mmap_sem > > Hence the inversion. > It seems the deadlock can't ever happen, I even don't see > corner cases where it could happen. > > But still, this dependency should disappear. > > Could you please tell me if the following patch makes it shut down? > > Otherwise, I may need your config. I don't know why, but I suspect > the lock_acquire(mmap_sem) in might_fault doesn't trigger needed the lockdep > check, although I have the appropriate debug config, at least it seems. > But anyway, it should also happen in my box but it doesn't... > > Thanks! > > The patch: Yes, it is working! > > diff --git a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c > index d23d6d7..59f7a4c 100644 > --- a/fs/reiserfs/journal.c > +++ b/fs/reiserfs/journal.c > @@ -2801,11 +2801,14 @@ int journal_init(struct super_block *sb, const char *j_dev_name, >                goto free_and_return; >        } > > +       reiserfs_write_unlock(sb); >        if (journal_init_dev(sb, journal, j_dev_name) != 0) { >                reiserfs_warning(sb, "sh-462", >                                 "unable to initialize jornal device"); > +               reiserfs_write_lock(sb); >                goto free_and_return; >        } > +       reiserfs_write_lock(sb); > >        rs = SB_DISK_SUPER_BLOCK(sb); > > > -- 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/