Re: memleaks, acpi + ext4 + tty

["Luis R. Rodriguez" <mcgrof@gmail.com>]

On Sun, Aug 30, 2009 at 11:24 AM, Theodore Tso<tytso@mit.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