public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Moving BKL from generic code into drivers
@ 2001-12-05  3:20 David C. Hansen
  2001-12-05  4:03 ` Alexander Viro
  0 siblings, 1 reply; 2+ messages in thread
From: David C. Hansen @ 2001-12-05  3:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List

As a first step toward removing the BKL from some block device drivers, 
I'm planning on moving the BKL out of the generic code and into the 
drivers themselves.

I plan on doing this indiscriminately.  All block devices will have a 
lock_kernel() at the top of their open() and an unlock_kernel() at the 
bottom.  Later on, we can remove it from individual drivers as we see fit.

Now the big question:
In block_dev.c:do_open(), the BKL is held in addition to bdev->bd_sem. 
Why is the BKL held here, other than to protect all of the drivers' open 
functions?  What doesn't the semaphore provide?

This kind of action, moving the BKL from generic code into drivers isn't 
a first:
http://marc.theaimsgroup.com/?l=linux-kernel&m=96346538231916&w=2
-- 
Dave Hansen
haveblue@us.ibm.com


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Moving BKL from generic code into drivers
  2001-12-05  3:20 Moving BKL from generic code into drivers David C. Hansen
@ 2001-12-05  4:03 ` Alexander Viro
  0 siblings, 0 replies; 2+ messages in thread
From: Alexander Viro @ 2001-12-05  4:03 UTC (permalink / raw)
  To: David C. Hansen; +Cc: Linux Kernel Mailing List



On Tue, 4 Dec 2001, David C. Hansen wrote:

> As a first step toward removing the BKL from some block device drivers, 
> I'm planning on moving the BKL out of the generic code and into the 
> drivers themselves.
> 
> I plan on doing this indiscriminately.  All block devices will have a 
> lock_kernel() at the top of their open() and an unlock_kernel() at the 
> bottom.  Later on, we can remove it from individual drivers as we see fit.
> 
> Now the big question:
> In block_dev.c:do_open(), the BKL is held in addition to bdev->bd_sem. 
> Why is the BKL held here, other than to protect all of the drivers' open 
> functions?  What doesn't the semaphore provide?

get_blkfops() and module {un,}loading.

Please, don't step into that mess right now - there's a bunch of bad races
in devfs-related side of ->bd_op handling and the last thing we need is
additional set of complications.

Naive fix won't work due to devfs mess and correct one will take serious
massage of generic code _and_ devfs.

Besides, for block devices ->open() and ->release() are absolutely not
interesting wrt BKL contention.  Just how often are they called?


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-12-05  4:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-12-05  3:20 Moving BKL from generic code into drivers David C. Hansen
2001-12-05  4:03 ` Alexander Viro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox