Re: loopback device HANGS

aem@netcom.ca
Mon, 18 May 1998 12:00:13 -0400 (EDT)

> The changes Stefan are referring to are spinlocks added to the general
> block IO subsystem, not loopback device changes.
> Apparently, what is happening is that the loopback device hangs because it
> invokes the block device subsystem recursively, deadlocking on the
> spinlocks. I remember someone was working on this recently, but I don't
> recall whom. The correct solution is to unlock the spinlocks before
> loopback recurses into the block device subsystem, right? Did someone
> have a patch for this? [I seem to recall that there were unresolved
> issues...]

These are the resursive problems in the loop driver that I know of:
- the interrupt flag is not always saved and restored in the block
code, instead it is often set and cleared without regard to its
previous state.
- a loop device must sleep if it cannot allocate all the requests
it will need to complete a request
- a loop device must sleep if it cannot allocate all the buffers
it will need to complete a request
I fixed the first two in a patch for 2.1.59, but it is now quite outdated.
The third problem isn't a major factor after curing the second.

The patch for my modular loop driver is currently in the process of being
updated - there is an alpha version available now for 2.1.98, but without
the fixes for the recursive problems mentioned above.
ftp://fractal.mta.ca/pub/users/aem/crypto/message

I've volunteered to be the loop driver maintainer as soon as I get
the patch updated, and if it gets accepted into the kernel distribution.
Ted gave me his blessings.

--
Andrew E. Mileski   mailto:aem@netcom.ca


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu