linux-kernel - Re: [PATCH] x86/vdso: shrink vdso/extable.i via IWYU

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] [day] [month] [year] [list]

Message-ID: <20240105144556.GBZZgWJOjq6Ekmps6Z@fat_crate.local>
Date: Fri, 5 Jan 2024 15:45:56 +0100
From: Borislav Petkov <bp@...en8.de>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Tanzir Hasan <tanzirh@...gle.com>, Andy Lutomirski <luto@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	Kees Cook <keescook@...omium.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Andy Shevchenko <andy@...nel.org>
Subject: Re: [PATCH] x86/vdso: shrink vdso/extable.i via IWYU

On Wed, Jan 03, 2024 at 11:36:35AM -0800, Nick Desaulniers wrote:
> By being more precise in what's necessary via making more specific use
> of includes (making "indirect" includes into "direct" includes) in the
> .c files, it will allow us to more easily refactor the header files
> themselves.

I know, but you have to realize that header files are not a static thing
- we do "refactor" them all the time. So it's not like we'll refactor
them and they'll be done. No, we'll refactor them again later.

> And yes, these inclusion lists will change over time.  As you say
> below, they can be cleaned up again every couple of releases.  Though
> right now most files have never been cleaned up at all.

Yap, the need for some tool or facility to keep include files proper and
optimal is indisputable. There's a reason it is called the "Include
Hell".

> Over time, they will add up. But not if we reject the patches as
> unnecessary churn.

There's the other side of that coin: if we keep applying those, it'll
turn into a never-ending stream of silly fixes. Like spellchecking and
whitespace cleanups. And maintainers will start ignoring them.

> Maybe the overall numbers are interesting, but landing one patch that
> updates numerous .c files' inclusion lists seems error prone.  I
> suspect it's more likely that a more incremental approach of smaller
> patches allows progress if there are any issues; a build
> failure/mistake doesn't block the whole thing from landing.
> 
> Overall numbers can also be collected after the fact.

You could do a single patch *set* and say, before and after, we get
these improvements. And the whole set goes in in one fell swoop.

> > And then do it
> > again in a couple of releases, when it becomes necessary again.
> 
> That's the use case I had in mind.  Though I suspect the initial run
> of this tooling will result in the most changes, as some files in tree
> are hardly touched between releases. For those, I don't expect any
> automated tooling to be churning those files after the initial
> cleaning.

That's why I said "when it becomes necessary". :)

> Yeah, the idea is that the tooling results in repeatable processes by
> others.  One could imagine build bots running this, or integrating it
> into checkpatch, or git presubmit hooks, or w/e.

Yap, that would be best. Because it'll stop from the whole include hell
from even ensuing in the first place.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette