linux-kernel - RE: [PATCH next v4 0/5] minmax: Relax type checks in min() and max().

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: <53d06c12ebcf4a87b241ae31b81c3ea6@AcuMS.aculab.com>
Date: Tue, 9 Jan 2024 09:35:21 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Linus Torvalds' <torvalds@...ux-foundation.org>, Jiri Slaby
	<jirislaby@...il.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Andy
 Shevchenko" <andriy.shevchenko@...ux.intel.com>, Andrew Morton
	<akpm@...ux-foundation.org>, "Matthew Wilcox (Oracle)" <willy@...radead.org>,
	Christoph Hellwig <hch@...radead.org>, "Jason A. Donenfeld" <Jason@...c4.com>
Subject: RE: [PATCH next v4 0/5] minmax: Relax type checks in min() and max().

From: Linus Torvalds
> Sent: 08 January 2024 18:19
> 
> On Mon, 8 Jan 2024 at 03:46, Jiri Slaby <jirislaby@...il.com> wrote:
> >
> >    CPP [M] drivers/media/pci/solo6x10/solo6x10-p2m.i
> > real    0m45,002s
> >
> > $ git revert 867046cc7027703f60a46339ffde91a1970f2901
> >    CPP [M] drivers/media/pci/solo6x10/solo6x10-p2m.i
> > real    0m11,132s
> >
> > $ git revert 4ead534fba42fc4fd41163297528d2aa731cd121
> >    CPP [M] drivers/media/pci/solo6x10/solo6x10-p2m.i
> > real    0m3,711s
> 
> Ouch. Yeah, that's unfortunate. There's a lot of nested nasty macro
> expansion there, but that timing is excessive.
> 
> Sparse actually complains about that file:
> 
>   drivers/media/pci/solo6x10/solo6x10-p2m.c:309:13: error: too long
> token expansion
>   drivers/media/pci/solo6x10/solo6x10-p2m.c:310:17: error: too long
> token expansion
> 
> and while that is a sparse limitation, it's still interesting. Having
> that file expand to 122M is not ok.
> 
> In this case, I suspect the right thing to do is to simply not use
> min()/max() in that header at all, but do something like

Replacing the max(a, min(b, c)) with clamp(b, a, c)
(I think that is the right order of the args)
would probably stop the complete explosion.

Then I'm pretty sure it shouldn't actually be nesting the two
defines.
The code really doesn't what to expand most of those very often.
In fact doing so once during init is probably the right thing to do.

That is true regardless of the implementation of min() and max().

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)