linux-kernel - Re: [tip: core/urgent] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS_

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: <Z_wTzWA7h5jdy47Y@gmail.com>
Date: Sun, 13 Apr 2025 21:43:09 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Uros Bizjak <ubizjak@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Borislav Petkov <bp@...en8.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org,
	Paul Menzel <pmenzel@...gen.mpg.de>, x86@...nel.org
Subject: Re: [tip: core/urgent] compiler.h: Avoid the usage of
 __typeof_unqual__() when __GENKSYMS__ is defined


* Uros Bizjak <ubizjak@...il.com> wrote:

> On Sun, Apr 13, 2025 at 9:20 PM Ingo Molnar <mingo@...nel.org> wrote:
> >
> >
> > * Uros Bizjak <ubizjak@...il.com> wrote:
> >
> > > > > If this commit is removed, [...]
> > > >
> > > > I did not remove commit ac053946f5c4, it's already upstream. Nor
> > > > did I advocate for it to be reverted - I'd like it to be fixed. So
> > > > you are barking up the wrong tree.
> > >
> > > If the intention is to pass my proposed workaround via Andrew's tree,
> > > then I'm happy to bark up the wrong tree, but from the referred
> > > message trail, I didn't get the clear decision about the patch, and
> > > neither am sure which patch "brown paper bag bug" refers to.
> >
> > It's up to akpm (he merged your original patch that regressed), but I
> > think scripts/genksyms/ should be fixed instead of worked around -
> > which is why I zapped the workaround.
> 
> As said earlier, I have tried to fix genksyms, but the simple fix was 
> not enough. The correct fix would be somehow more involved, and I 
> have zero experience in genksyms source. I'm afraid I don't know this 
> source well enough to offer a fix in the foreseeable future, so I 
> resorted to the workaround (which at the end of the day is as 
> effective as the real fix).

I disagree that hacks/workarounds are as effective as the real fix.

In the Linux kernel the usual principle is that developers who 
introduce unanticipated in-tree regressions are expected to fix them 
for real and not just work them around. Not following that principle 
may have reputational costs going forward (or not), but it's your time 
and your call really.

Thanks,

	Ingo