> > I think this is more related to dm-crypt and not to loop. However - this > > only seems to happen when dm-crypt is on top of loop, something I cannot > > explain, how do they differ?. Sysrq-t trace at the bottom. My belief > > after looking at this is that dm-crypt leaks memory somewhere but I > > couldn't get around the dm code so here it is. This is 2.6.11, but this > > bug has been present forever (easier to trigger now though). > > > > ================================================= > > > > Testcase: > > #!/bin/sh > > losetup /dev/loop7 loopbackfile > > echo 0 `blockdev --getsize /dev/loop7` crypt aes-plain 0123456789abcdef0123456789abcdef 0 /dev/loop7 0 | dmsetup create volume1 > > mkfs.ext3 /dev/mapper/volume1 > > mount /dev/mapper/volume1 mnt > > cd mnt > > dbench 20 > > How do you see there's a memory leak? Does your machine lock up? I just > ran your testcase several times and I don't see anything unusual. Total > system memory consumption doesn't change before and afterwards. > > 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. 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 It doesn't happen on normal block devices nor does loop cause this by itself, it's the combination. Some binary searching showed that this bug goes long back although it's easier to trigger now. I'm kind of out of ideas, I've tried to look at the code myself but I found it difficult to follow :(