Am Donnerstag, den 10.03.2005, 15:55 +0100 schrieb Alexander Nyberg: > > Can anybody else confirm this? > > The original report came from Steffen Michalke (CC'd), but I find it > very weird that you can't trigger the lockup. It takes about a second > here on a UP non-preempt box to lock up. Perhaps my machine has too much memory. ;) > Why I think it's a memory leak is due to the sysrq-Meminfo trace > and the call-trace showing > crypt_alloc_buffer => mempool_alloc => io_schedule That's normal. For write-outs dm-crypt has to allocate some buffers where it can put the encrypted data. mempool_alloc means that it ran out of preallocated buffers and waits for some in-flight I/O to finish which should free some buffers. It looks like this is a dm-crypt <-> loop deadlock. The problem with loop is that it goes back through the page cache. The loop thread is also waiting for memory to actually be able to write out some more pages. So this seems to be a loop bug. Loop is waiting for pages to become free to actually be able to write some pages. dm-crypt uses a mempool to avoid this deadlock but if the underlying device deadlocks it can't do anything about that. loop does a: alloc_page(GFP_NOIO | __GFP_HIGHMEM); There is no guarantee that this will succeed. It probably should also have some sort of emergency pool.
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
