[lkml]   [2003]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: recursive spinlocks. Shoot.
    On Mon, May 19 2003, Peter T. Breuer wrote:
    > "David Woodhouse wrote:"
    > > To be honest, if any programmer is capable of committing this error and
    > > not finding and fixing it for themselves, then they're also capable, and
    > > arguably _likely_, to introduce subtle lock ordering discrepancies which
    > > will cause deadlock once in a blue moon.
    > >
    > > I don't _want_ you to make life easier for this hypothetical programmer.
    > >
    > > I want them to either learn to comprehend locking _properly_, or take up
    > > gardening instead.
    > Let's quote the example from rubini & corbet of the sbull block device
    > driver. The request function ends like so:
    > spin_unlock_irq (&io_request_lock);
    > spin_lock(&device->lock);
    > /* Process all of the buffers in this (possibly clustered) request. */
    > do {
    > status = sbull_transfer(device, req);
    > } while (end_that_request_first(req, status, DEVICE_NAME));
    > spin_unlock(&device->lock);
    > spin_lock_irq (&io_request_lock);
    > end_that_request_last(req);
    > }
    > device->busy = 0;
    > }
    > Notice that he runs end_that_request_first outside the io_request_lock
    > and end_that_request_last under the lock. Do you know which is right?
    > (if any :-).

    Both are right, as it so happens.

    > And he takes a device lock before calling the "transfer" routine.
    > Yes, he's ok because his transfer function is trivial and doesn't
    > take the lock, but anyone following his recipe is heading for
    > trouble.

    In 2.5, the device lock most likely would be the queue lock as well so
    no confusion there. But what are you talking about? I'd assume that the
    device lock must be held in the transfer function, why else would you
    grab it in the first place in the function you quote? Please, if you are
    going to find examples to support the recursive locking idea, find some
    decent ones...

    I think you are trying to make up problems that do not exist. I'd hate
    to see recursive locks being used just because someone can't be bothered
    to write to code correctly (recursive locks have its uses, the one you
    are advocating definitely isn't one). Recursive locks are _not_ a remedy
    for someone who doesn't understand locking or isn't capable enough to
    design his locking correctly. Period.

    Jens Axboe

    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:35    [W:0.023 / U:90.376 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site