[lkml]   [2001]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Change locking in block_dev.c:do_open()

On Wed, 12 Dec 2001, David C. Hansen wrote:

> I've been looking at how the BKL is used throughout the kernel. My end
> goal is to eliminate the BKL, but I don't have any fanciful ideas that I
> can get rid of it myself, or do it in a short period of time. Right
> now, I'm looking for interesting BKL uses and examining alternatives.
> Lately, I've been examining do_open() in block_dev.c. This particular
> nugget of code uses the BKL for a couple of things. First,
> get_blkfops() can call request_module(), which requires the BKL.
> Secondly, there needs to be protection so that the module isn't removed
> between the get_blkfops() and the __MOD_INC_USE_COUNT(). Lastly, the
> bd_op->open() calls expect the BKL to be held while they are called. Is
> this it? Anybody know of more reasons?

Sigh... First of all, the right thing to do is to call try_inc_mod_count()
_in_ get_blkfops(). No need to reinvent the wheel. But real problem with
that area is not BKL. It's *!@& damn devfs=only mess and code that does
direct assignment of ->bd_op before calling blkdev_get(). Until it's solved
(and the only decent way I see is to remove this misfeature) I'd seriously
recommend to leave the damn thing as is.

If you can think of a decent way to handle that problem - you are very
welcome. _If_ we remove devfs=only I have a patchset that moves BKL to
the area immediately around the call of ->open() - see*-S14-pre5.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:14    [W:0.109 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site