Re: loopback blockdev deadlocks -- explained?

From: Mike Galbraith (mikeg@weiden.de)
Date: Tue Apr 18 2000 - 09:02:40 EST


On Sun, 16 Apr 2000, Steve Dodd wrote:

> On Sun, Apr 16, 2000 at 05:13:39PM +0200, Jens Axboe wrote:
> > On Sun, Apr 16 2000, Steve Dodd wrote:
>
> > > /*
> > > * Loop uses two requests, 1 for loop and 1 for the real device.
> > > * Cut max_req in half to avoid running out and deadlocking.
> > > */
> > > if ((major == LOOP_MAJOR) || (major == NBD_MAJOR))
> > > max_req >>= 1;
> > >
> > > This assumption presumably breaks down horribly for file-backed loop
> > > devices? The numbers of requests that the filesystem is going to generate
> > > to deal with one loop device request may well be >1. Does this sound
> > > plausible to anyone or have I missed something?
> >
> > The assumption does indeed break down for file back devices, but that
> > should not be a problem. The worst case scenario would just cause
> > get_request to block, even though it would be safe to dish out a
> > request.
>
> Hmmm, I'm not clear on the working of the request queue stuff, but I don't
> see why the comment above would apply to block-backed but not file-backed
> loops. Surely the issue is that you can end up in a sitation where you need
> one or more free requests to complete a request, there are no free
> requests, and the only way to free one is to complete a request..

I still think you can't get there from here with stacked devices.
Looking at what Ingo did to make raid devices pluggable along with
the below have me pretty well convinced.

linux/drivers/block/ll_rw_blk.c
623 if (list_empty(head)) {
624 if ((major != LOOP_MAJOR)) /*the easiest way*/
625 q->plug_device_fn(q, bh->b_rdev); /* is atomic */
626 goto get_rq;
627 }

        -Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:13 EST