linux-kernel - Re: memleaks, acpi + ext4 + tty

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <43e72e890909011059x166d4ac4s7998cc3ce64a9c99@mail.gmail.com>
Date:	Tue, 1 Sep 2009 10:59:19 -0700
From:	"Luis R. Rodriguez" <mcgrof@...il.com>
To:	Theodore Tso <tytso@....edu>,
	"Luis R. Rodriguez" <mcgrof@...il.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Catalin Marinas <catalin.marinas@....com>,
	linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: memleaks, acpi + ext4 + tty

On Sun, Aug 30, 2009 at 11:24 AM, Theodore Tso<tytso@....edu> wrote:
> On Sun, Aug 30, 2009 at 10:29:01AM -0700, Luis R. Rodriguez wrote:
>> > Yes, as soon as the next merge window opens.  The leak only shows up
>> > when you mount and unmount a filesystem, which under normal
>> > circumstances doesn't happen a huge number of times on most systems.
>> > By the time it showed up it was late enough in the 2.6.31-rcX series
>> > that I figured it was better to wait until the next merge window.  I
>> > didn't consider it a high priority bug.
>>
>> That's odd I run into this kmemleak with a single bootup, no manual remounts.
>>
>
> Yeah, but it's a singleton leak.  Let me be a bit more precise this
> time: the leak happens at mount time because we're essentially doing
> this due to some code that was accidentally duplicated when it was
> being refactored:
>
>        a = kmalloc(sizeof(...)*N, GFP_ATOMIC);
>          ...
>        a = kmalloc(sizeof(...)*N, GFP_ATOMIC);
>
> So a small amount of memory is leaked each time a filesystem is
> mounted.  It doesn't become a huge problem unless you are repeatedly
> mounting and unmounting the same filesystem in a tight loop.

Thanks for the explanation -- this still does seem like something
which could affect some users, say of, embedded systems which do need
to remount, so while it may be a priority for an average user it seems
high priority for embedded system users using ext4 and remounting a
lot.

Either way, I guess what I'm getting at is it seems rather odd to me
we would not consider fixing some memory leaks on an rc release when
we already have a fix prepared. I understand the merge window is
closing in but we're not there yet -- and in worst case, can't we at
least consider this fix after rc1?

kmeleak reports seem rather useful, I'd hate to see more users told
their memory leak issues won't be fixed until a later kernel release.
That just seems... shitty.

  Luis
--
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/