Re: recursive spinlocks. Shoot.

[Peter T. Breuer]

"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 :-).

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.

Peter