On Wed, 10 Jan 1990 06:12:50 +0100, Pavel Machek <pavel@bug.ucw.cz>
said:
> I _think_ that there's some problem with fs superblock lock or
> something like that. It is not just block layer that can daedlock -
> you've fs layer out there, too.
> To write datablock on loop device you need to write indirectblock on
> host fs. So for datablock write on loop you need superblock lock on
> host or something like that. (These are wild guesses.)
So? You take the superblock lock on the host, you allocate, you drop
the lock. Unless there are any recursion situations where you need to
access a lock on the local machine while holding that remote superblock
lock, you just have normal synchronisation locking without deadlock.
And yes, the kpiod thread added in 2.2.2 does eliminate a whole class of
such locking deadlocks. We no longer have any way for memory allocation
requirements on the host to trigger a deadlocking lock recursion back to
the client. I really meant it when I said that our VM is much more
robust now.
> I've definitely seen deadlocks on 2.3.early. This is not plain
> hand-waving. I'm not close to linux station now (writing mails in
> Delphi under Win95 :-(((( )
2.3 is undergoing sufficiently rapid evolution right now that I'd not
take that as meaningful until the source of the deadlock is found!
> I can mail script to reproduce deadlocks if you are interested. But it
> does just what I said: > /tmp/emptyfile ; mke2fs /tmp/emptyfile; mount
> /tmp/emptyfile -oloop /somewhere; write to both /somewhere/XXX and
> /tmp/YYY. Deadlock.
OK. we can definitely look into this, but the fact remains that I don't
know of any _fundamental_ reasons why we cannot do sparse loopback right
now. The VM infrastructure is resistant to those deadlocks.
> PS: Of course swapping over nbd does not work. When someone eats all
> atomic memory (which almost never happens) you don't have enough memory
> to receive ack for packet you send, and you deadlock. It is reproducible
> with mem=8M and heavy pingflood, but artifical all-atomicram-eater works
> much better.
Yes. There _are_ pretty simple ways to fix this, btw, but adding a
separate clean-page-reaper thread to kswapd is probably too dangerous
for 2.2.
--Stephen
-
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/