On Mon, 11 Jan 1999 12:20:39 +0100, Pavel Machek
<pavel@atrey.karlin.mff.cuni.cz> said:
> Hi!
>> In fact, to make it really safe we'd need to avoid synchronous swapout
>> altogether: otherwise we can have
>>
>> A kswiod nbd server process
>> [deadlock]
> Is this only matter of nbd? If so, maybe the best solution is to start
> claiming: "don't swap over nbd, don't mount localhost drives read
> write". [It is bad, but it is probably better than polluting rest of
> kernel with nbd workarounds...]
No. Any other process which gets in the way of our IO and which blocks
for memory allocation can cause the deadlock. That might be another
process doing a file IO, locking a buffer and then allocating memory
inside the scsi layers, for example. It is not limited to nbd, but
nbd's networking use will probably make it particularly bad.
Linus, I've also realised that making semaphores recursive does not fix
the inode deadlock. It only eliminates the single process case. We can
still have two separate processes each writing to a separate mmaped()
file deadlock. If each process starts a msync() on its own file and in
the process of that tries to sync one of the other process's pages via
try_to_free_page, we get the deadlock back.
I can't see any way around this other than to make try_to_free never,
ever block on IO, which implies having a separate page writer thread, or
to rework the code so that we never allocate memory while holding one of
the critical filesystem locks (which is a non-starter 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/