> > > 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. Ok, but - this is a late revision, the allocation you pointed out did not exist in for example 2.6.10. I tried this my test script on a 128MB machine a few kernels back and it did happen in 2.6.10, maybe not as fast however. The place where loop does page allocations in writeout in 2.6.10 is do_lo_send() grab_cache_page() find_or_create_page() alloc_page() And the grab_cache_page looks like a common filesystem called function, but I guess the difference is that this time the data to writeout is in kernel memory and not user-space owned. I figure loop shouldn't call this function that does bare alloc_page, but needs something that uses a mempool to prevent it from deadlocks when stacking with other drivers. I don't think I've got the whole picture here, but I'm grateful for your previous explanation, it helps alot! Thanks! Alexander