Re: BKL removal

[Rick Lindsley <ricklind@us.ibm.com>]

    So you agree with me?  Good.  I know you think the code is better
    than it was before, but beauty is in the eye of the beholder, or in
    this case, the eye of the people that fully understand the code :)

The problem is, of course, that to responsibly use the BKL, you must
fully understand ALL the code that utilizes it, so that you know your
new use of it doesn't conflict or interfere with existing code and
usage.  That's the same problem we have when it DOES show contention --
is the problem in the functions which can't grab it (for trying
unnecessarily), or in the functions that can (for holding it
unnecessarily)?

If you are the person who understands the BKL in all its usages
throughout the kernel, then thankfully, our search is over.  We've been
looking for you to help resolve some of these discussions.  If you
aren't that person, though, then you can't accurately say your use of
it doesn't affect anybody else adversely.  All you can assert is that
in your corner of the kernel, *you* use it for X, Y, and Z and they
don't interact poorly with each other.

With a narrowly defined and used lock, it is much less difficult to
determine who uses it, what it is guarding, and what impact yet another
use of it will have.  With the BKL (and a few other poorly documented
locks which have recently been cleaned up) nobody has had a hope of
understanding the interactions.

    If nothing else, I hope you will think twice before sending off
    your next BKL removel patch in a subsystem that you haven't fully
    tested or understood.  That's the point I keep trying to get across
    here.

So can you define for me under what conditions the BKL is appropriate
to use?  Removing it from legitimate uses would be bad, of course, but
part of the problem here is that it's currently used for a variety of
unrelated purposes.

Rick