From: Evgeniy Dushistov <dushistov@mail.ru>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Nick Bowler <nbowler@elliptictech.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] BKL removal follow-up
Date: Fri, 24 Dec 2010 14:04:58 +0300 [thread overview]
Message-ID: <20101224110458.GA18894@maclin> (raw)
In-Reply-To: <201012212354.06895.arnd@arndb.de>
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.
> @@ -922,22 +922,22 @@ void ufs_evict_inode(struct inode * inode)
> if (want_delete) {
> loff_t old_i_size;
> /*UFS_I(inode)->i_dtime = CURRENT_TIME;*/
> - lock_kernel();
> + lock_ufs();
lock
> mark_inode_dirty(inode);
> ufs_update_inode(inode, IS_SYNC(inode));
> old_i_size = inode->i_size;
> inode->i_size = 0;
> if (inode->i_blocks && ufs_truncate(inode, old_i_size))
call truncate with lock
> ufs_warning(inode->i_sb, __func__, "ufs_truncate failed\n");
> - unlock_kernel();
> + unlock_ufs();
> }
> diff --git a/fs/ufs/truncate.c b/fs/ufs/truncate.c
> index a58f915..9f22d00 100644
> --- a/fs/ufs/truncate.c
> +++ b/fs/ufs/truncate.c
> @@ -467,7 +467,7 @@ int ufs_truncate(struct inode *inode, loff_t old_i_size)
>
> block_truncate_page(inode->i_mapping, inode->i_size, ufs_getfrag_block);
>
> - lock_kernel();
> + lock_ufs();
call lock again
--
/Evgeniy
next prev parent reply other threads:[~2010-12-24 11:10 UTC|newest]
Thread overview: 20+ 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 ` [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 ` [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-21 14:12 ` Boaz Harrosh
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 [this message]
2010-12-30 14:58 ` Arnd Bergmann
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=20101224110458.GA18894@maclin \
--to=dushistov@mail.ru \
--cc=arnd@arndb.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox