Hmm, it seems to me the loop device buffers shouldn't be locked until
all the resources have been rounded up. But if this is what's being
done, it's easy enough to add a test not to wait on a loop buffer.
Are there any other cases of locked buffers that won't unlock on their
own when the i/o completes?
> The intention was to wait for some I/O to be actually performed rather
> than just queued (using the implicit matching of kflushd()'s speed to
> the device speed by get_request_wait() in ll_rw_blk.c when no free request
> structure is available). This is a similar effect to sleeping on a locked
> buffer, waiting for it to unlock.
OK, that seems reasonable in the absence of an explicit wait. But with
the addition of a wait_on_buffer, we want to wake up the tasks as soon
as the first batch of buffers have been written. Then the task will be
able to continue as quickly as possible.
Regards,
Bill