Fwd: Memory Leak in /dev/shm on ARM 2.6.36

[AJ ONeal]

umount does fail, but umount -l succeeds.

Here's a snippet of the most relevant portion of the code:
https://gist.github.com/749619


The data size is always 512kb
The file write occurs every 128ms (with some hiccups now and then)
14 writes occur before the first file is overwritten.

It's not very likely, but possible that another process could have the
file open for reading when it is unlinked, but never written to.

Luckily I happen to have a 2.6.35 laying around for ARM.

Perhaps I can just get you a copy of the code to test on x86.
I don't have any handy that I'm okay to swap kernels on.

AJ ONeal

On Mon, Dec 20, 2010 at 9:46 PM, Hugh Dickins <hughd@xxxxxxxxxx> wrote:
>
> On Mon, 20 Dec 2010, AJ ONeal wrote:
>
> > In my other message about SIGBUS I was mmap-ing a file in /dev/shm.
> >
> > I switched my implementation to use write() instead of mmap and now it
> > leaks memory very very quickly.
> >
> > `df -h` shows that 80mb of memory are in use
> > `du -ch /dev/shm` shows that 10mb of memory in use
> >
> > After just a few minutes of creating and removing 512kb files in
> > /dev/shm the program exits with a write failure.
> > Unmounting and remounting /dev/shm reclaims the memory.
>
> I'm interested, but won't have any time to investigate for several days.
>
> The usual reason (for such a large df/du discrepancy) would be something
> holding open the unlinked files; but if that were the case, then umount
> would fail, complaining that the mount is busy.
>
> Can you please try x86 and see if the same happens there with your
> program?  (I've got x86 but not arm: I see no problem on x86,
> but I'm probably not doing exactly what you're doing.)
>
> Can you please try 2.6.35 and see if that behaves in the same way?
> There were some shmem block accounting changes in 2.6.36, I wonder
> if they're misbehaving on arm.
>
> Thanks,
> Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/