[lkml]   [2002]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: BKL removal
    On Mon, Jul 08, 2002 at 06:46:12PM -0700, Rick Lindsley wrote:
    > 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)?


    But the driverfs and USB code do _not_ show contention. Or if they do
    (as Dave pointed out in the driverfs code) it's in a non-critical
    point in the kernel's life (boot time, USB device removal, etc.)

    > 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.

    Yes, that's what I am asserting, _and_ that when my "corner" of the
    kernel uses it, it doesn't really matter if ext3, ext2, or even the
    entire VFS layer grinds to a halt. No one will care, or even notice.

    > 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.

    Wait! You're still not getting it. I'm not against removing the BKL.
    I'm not saying we should add it to more places. What I am complaining
    about (and I'm not the only one) is the method that people who are
    trying to remove the BKL from various kernel subsystems are using. I
    think Oliver said it best in this quote from this thread:

    So you do the greps and question locking usage on the
    right lists. It's quite important, you might uncover
    bugs and speed up the kernel. And you need to be
    persistent about it. Take your time to find out why
    the lock is used. Or why it makes no sense.

    So please, no more "hit and run" BKL patches that break things. Please
    come offering to help, with detailed reasons why BKL usage is wrong in
    the specific portions of the code, and how possibly it might be cleaned
    up, with patches that have _actually been tested_. And then
    flames^Wdiscussions like this one will not happen at all.


    greg k-h
    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:27    [W:0.027 / U:75.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site