linux-kernel - Re: Observation of a memory leak with commit 314001f0bf92 ("af

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 for Android: free password hash cracker in your pocket

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

Message-ID: <afaa879e-c888-100e-ff2e-429a2457a014@leemhuis.info>
Date:   Fri, 28 Jan 2022 14:17:41 +0100
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Jakub Kicinski <kuba@...nel.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>
Cc:     Rao Shoaib <rao.shoaib@...cle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        Sudip Mukherjee <sudip.mukherjee@...ethink.co.uk>,
        regressions@...ts.linux.dev
Subject: Re: Observation of a memory leak with commit 314001f0bf92 ("af_unix:
 Add OOB support")

On 10.01.22 17:29, Jakub Kicinski wrote:
> On Mon, 10 Jan 2022 17:19:56 +0100 Lukas Bulwahn wrote:
>> It's a regression if some application or practical use case running fine on one
>> Linux kernel works worse or not at all with a newer version compiled using a
>> similar configuration.
>>
>> The af_unix functionality without oob support works before
>> 314001f0bf92 ("af_unix: Add OOB support").
>> The af_unix functionality without oob support works after 314001f0bf92
>> ("af_unix: Add OOB support").
>> The af_unix with oob support after the new feature with 314001f0bf92
>> ("af_unix: Add OOB support") makes a memory leak visible; we do not
>> know if this feature even triggers it or just makes it visible.
>>
>> Now, if we disable oob support we get a kernel without an observable
>> memory leak. However, oob support is added by default, and this makes
>> this memory leak visible. So, if oob support is turned into a
>> non-default option or nobody ever made use of the oob support before,
>> it really does not count as regression at all. The oob support did not
>> work before and now it works but just leaks a bit of memory---it is
>> potentially a bug, but not a regression. Of course, maybe oob support
>> is also just intended to make this memory leak observable, who knows?
>> Then, it is not even a bug, but a feature.
> I see, thanks for the explanation. It wasn't clear from the "does not
> repro on 5.15, does repro on net-next" type of wording that the repro
> actually uses the new functionality.

Thx from my side, too.

>> Thorsten's database is still quite empty, so let us keep tracking the
>> progress with regzbot. I guess we cannot mark "issues" in regzbot as a
>> true regression or as a bug (an issue that appears with a new
>> feature).

Yeah, I definitely don't want regzbot to be used to track ordinary
issues, but sometimes it's hard to find clear boundaries between issue
and regression. This is one, but I tend to say it's an issue, as users s
won't notice the leak in practice afaics. But there are other areas that
are greyish; an kernel Oops/Warning/BUG or a hang sometimes might also
not strictly be a regression, but I guess tracking them might be a good
idea, so I'm open to those.

Anyway:

>> Also, this reproducer is automatically generated, so it barely
>> qualifies as "some application or practical use case", but at best as
>> some derived "stress test program" or "micro benchmark".

I left it tracked until now, but after Jakub's reply nothing to actually
address the issue seem to have happened. I guess in that case it's not
that important and it's time to remove it from the list of open
regressions tracked by regzbot, if that is okay for everyone:

#regzbot invalid: not strictly a regression

Ciao, Thorsten