linux-kernel - Re: Build performance regressions originating from min()/max() macros

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: <0b11e6c8-170d-4b95-ad14-76685d657643@suse.com>
Date: Wed, 24 Jul 2024 11:40:07 +0200
From: Jürgen Groß <jgross@...e.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, david.laight@...lab.com,
 Arnd Bergmann <arnd@...nel.org>, willy@...radead.org,
 torvalds@...ux-foundation.org, Jason@...c4.com, hch@...radead.org,
 andriy.shevchenko@...ux.intel.com, pedro.falcato@...il.com,
 Mateusz Guzik <mjguzik@...il.com>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: Build performance regressions originating from min()/max() macros

On 24.07.24 10:31, Lorenzo Stoakes wrote:
> On Wed, Jul 24, 2024 at 10:14:12AM GMT, Jürgen Groß wrote:
>> On 23.07.24 23:59, Lorenzo Stoakes wrote:
>>> Arnd reported a significant build slowdown [0], which was bisected to the
>>> series spanning commit 80fcac55385c ("minmax: relax check to allow
>>> comparison between unsigned arguments and signed constants") to commit
>>> 867046cc70277 ("minmax: relax check to allow comparison between unsigned
>>> arguments and signed constants"), originating from the series "minmax:
>>> Relax type checks in min() and max()." [1].
> 
> [snip]
> 
>> I can send a patch to simplify the problematic construct, but OTOH this
>> will avoid only one particularly bad example.
> 
> Thanks, appreciated but I am a little concerned that we might get stuck in
> whack-a-mole here a bit. I'm pretty sure we've had previous patches that
> have addressed invocation points, but obviously the underlying issue are
> these macros which will keep cropping up again and again.

The xen example seems to be one of the worst due to nesting of min3() and
min(), so being de facto a min4().

I think drivers/firmware/sysfb_simplefb.c has a similar problem, as it is
nesting max() with max3(). Same applies to arch/x86/kernel/cpu/cacheinfo.c
and multiple times to fs/xfs/libxfs/xfs_trans_resv.c.

There are probably more such extreme cases.


Juergen