linux-kernel - Re: Memory Leak in /dev/shm on ARM 2.6.36

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <AANLkTinwLr8jXoMtPzOCK0Hp=jn4bOjTjae1Faw+rriS@mail.gmail.com>
Date:	Wed, 26 Jan 2011 12:09:51 -0700
From:	AJ ONeal <coolaj86@...il.com>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Tim Chen <tim.c.chen@...ux.intel.com>, linux-kernel@...r.kernel.org
Subject: Re: Memory Leak in /dev/shm on ARM 2.6.36

I have another thought which may narrow down the problem a little bit.

Although all open files are closed before being removed, inotify is
watching the directory.
Perhaps this is a contributing factor? Thoughts?

I'll be trying the 2.6.35 kernel today, perhaps other kernels.

AJ ONeal

On Tue, Dec 21, 2010 at 12:51 AM, AJ ONeal <coolaj86@...il.com> wrote:
> 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@...gle.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/