linux-kernel - Re: [PATCH 0/7] minmax: reduce compilation time

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: <CAHk-=wi0UOUydauODOLAcS=mDzQsnxd=tGsJRLja88qrWjABWA@mail.gmail.com>
Date: Sat, 27 Jul 2024 11:16:34 -0700
From: Linus Torvalds <torvalds@...uxfoundation.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Jens Axboe <axboe@...nel.dk>, 
	David Laight <David.Laight@...lab.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Christoph Hellwig <hch@...radead.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Dan Carpenter <dan.carpenter@...aro.org>, Arnd Bergmann <arnd@...nel.org>, 
	"Jason@...c4.com" <Jason@...c4.com>, "pedro.falcato@...il.com" <pedro.falcato@...il.com>, 
	Mateusz Guzik <mjguzik@...il.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 0/7] minmax: reduce compilation time

On Sat, 27 Jul 2024 at 10:34, Matthew Wilcox <willy@...radead.org> wrote:
>
> In the specific case of PageLocked, that can hopefully go away fairly
> soon.  We only have 24 instances left in tree and five of those are
> comments/docs.  The ones in fs (btrfs, crypto, f2fs, ocfs2 and pipe)
> should be converted to folio soon.

So unlike the min/max mess, at least in this case there's some
_reason_ for the long lines (ie it's not some long line because of
just mindless expansion, it's a long line because it defines several
helper functions intentionally in one go).

End result: I don't think these are really in the same class as some
of the min/max expansion issues, but:

> But I have been wondering whether the way we define all the functions
> around page/folio flags is sensible.  Every file which includes
> page-flags.h (... which is most of them ...) regenerates the macros.
> You can't grep for the definition of folio_test_locked().  There's
> nowhere to put kernel-doc for folio_test_locked().

Right, these things do have their own issues, and the different flag
handling helper functions _used_ to be simpler than they are now. It
is indeed a pain to grep for, for example, and yes, it gets included
for a lot of people who simply don't need it or want it.

I'm not convinced having it in a generated file would help the
greppability - I certainly don't use "grep -R" any more, I use "git
grep", which by definition will never see any generated files any more
than it sees pre-processor output.

But whether those functions should be in one core header file at all,
that's clearly questionable. I wonder how inlined they need to be
either, outside of the trivial cases.

(And when I say "those functions", I don't mean just the pageflag
ones. The folio ones largely have all the same issues - except the
"page" ones have a *TON* of debugging code in them, so they expand to
be much bigger)

Side note: one very simple thing to do might be to short-circuit the
"constant bit number" test in the bitops that the PG_##flags cases
use. That's a lot of noise to select between "simple constant bit
number" and "generic variable one" when we know they are all constant.

                   Linus