All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Evgeniy Dushistov <dushistov@mail.ru>
Cc: Nick Bowler <nbowler@elliptictech.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] BKL removal follow-up
Date: Thu, 30 Dec 2010 15:58:22 +0100	[thread overview]
Message-ID: <201012301558.22191.arnd@arndb.de> (raw)
In-Reply-To: <20101224110458.GA18894@maclin>

On Friday 24 December 2010, Evgeniy Dushistov wrote:
> On Tue, Dec 21, 2010 at 11:54:06PM +0100, Arnd Bergmann wrote:
> > On Monday 22 November 2010 16:17:23 Nick Bowler wrote:
> > > On 2010-11-21 09:45 -0800, Linus Torvalds wrote:
> > > > Yes, I'd be ok with UDF doing a "select BKL" along with a "default n"
> > > > for BKL itself.
> > > > 
> > > > I think UDF currently is the only sane reason to have BKL enabled any
> > > > more, and yes, it would probably make it easier to configure things.
> > > 
> > > UFS (which I use) also relies on BKL.
> > 
> > Would you mind running a kernel with this patch and lockdep enabled then?
> > 
> > It's quite likely that this doesn't work, but the easiest way to find
> > out is to just try it if you don't understand the code. I can't see anything
> > in the code that relies on the release-on-sleep semantics and there
> > are no obvious recursive lock_kernel() calls.
> 
> I see one without looking at code (am I missed something?). See below.

Right, that was rather obvious, thanks for taking a look!

Now that I have your attention, do you expect to be able to prepare
a proper patch for 2.6.38? I don't have any experience with this file
system, nor do I have useful ways of testing it, so that would be
appreciated. Nick already volunteered to test patches, but I guess it
would make more sense if you could do the patch.

	Arnd

  reply	other threads:[~2010-12-30 14:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-17 15:26 [PATCH 0/7] BKL removal follow-up Arnd Bergmann
2010-11-17 15:26 ` Arnd Bergmann
2010-11-17 15:26 ` [PATCH 1/7] staging/stradis: mark as "depends on BKL" Arnd Bergmann
2010-11-17 16:03   ` Greg KH
2010-11-17 15:26 ` [PATCH 2/7] drm/i810: remove the BKL Arnd Bergmann
2010-11-17 15:26   ` Arnd Bergmann
2010-11-17 15:26 ` [PATCH 3/7] BKL: remove extraneous #include <smp_lock.h> Arnd Bergmann
2010-11-17 15:26 ` [PATCH 4/7] BKL: remove references to lock_kernel from comments Arnd Bergmann
2010-11-17 15:40   ` J. Bruce Fields
2010-11-17 15:26 ` [PATCH 5/7] BKL: disable by default Arnd Bergmann
2010-11-17 15:26 ` [PATCH 6/7] BKL: mark lock_kernel as deprecated Arnd Bergmann
2010-11-17 15:26 ` [PATCH 7/7] BKL: move CONFIG_BKL to staging Arnd Bergmann
2010-11-18 23:34 ` [PATCH 0/7] BKL removal follow-up Jan Kara
2010-11-18 23:40   ` Linus Torvalds
2010-11-18 23:40     ` Linus Torvalds
2010-11-21 14:12     ` Boaz Harrosh
2010-11-21 14:12       ` Boaz Harrosh
2010-11-21 17:45       ` Linus Torvalds
2010-11-21 17:45         ` Linus Torvalds
2010-11-22 15:17         ` Nick Bowler
2010-12-21 22:54           ` Arnd Bergmann
2010-12-22 15:23             ` Nick Bowler
2010-12-24 11:04             ` Evgeniy Dushistov
2010-12-30 14:58               ` Arnd Bergmann [this message]
2010-12-30 15:16                 ` Evgeniy Dushistov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201012301558.22191.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=dushistov@mail.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nbowler@elliptictech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.