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?

Let's assume that the BKL is not held here, at least over the whole
thing.  First, what do we need to do to keep the module from getting
unloaded after the request_module() in get_blkfops()?

We can add a semaphore which must be acquired before a module can be
unloaded, and hold it over the area where the module must not be
unloaded.  We could replace the unload_lock spinlock with a semaphore,
which I'll call it unload_sem here.  It would look something like this:

         down( &unload_sem );
         if (!bdev->bd_op)
                 bdev->bd_op = get_blkfops(MAJOR(dev));
         if (bdev->bd_op) {
                 ret = 0;
                 if (bdev->bd_op->owner)
                         __MOD_INC_USE_COUNT(bdev->bd_op->owner);
                 up( &unload_sem );
         ...
     } else {
             up( &unload_sem );
     }

Once the __MOD_INC_USE_COUNT() has been done, the module is protected
from being unloaded by its usecount.  Until that point the unload_sem
would protect it.  However, this isn't very clean, it forces the block
device code to know something about the module locking scheme.  In
addition, we will need to move the BKL into the get_blkfops() function 
for protection of blkdevs[] and request_module().

Now, what do we do about the need for the drivers to have the BKL in
their opens?  I suggest for now that we move the BKL into the open()
functions.  It will be messy, but I've done 95% of it already.  We can
slowly remove them as we deem them safe (we meaning me).  A similar 
approach was used for release() very early in 2.4 development.

I've attached a patch which does these things.  I don't expect anyone to
apply it, it's just there for you to see exactly what I'm trying to do.

--
Dave Hansen
haveblue@us.ibm.com