linux-kernel - Re: [RFC 6/8] x86_64/bug: Implement __WARN

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: <20250602180922.GC30486@noisy.programming.kicks-ass.net>
Date: Mon, 2 Jun 2025 20:09:22 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Linus Torvalds <torvalds@...uxfoundation.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, kees@...nel.org,
	acarmina@...hat.com, jpoimboe@...nel.org, mark.rutland@....com
Subject: Re: [RFC 6/8] x86_64/bug: Implement __WARN_printf()

On Mon, Jun 02, 2025 at 09:38:09AM -0700, Linus Torvalds wrote:
> On Mon, 2 Jun 2025 at 08:50, Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > Yes, it absolutely builds with clang. The inline asm isn't something we
> > don't already do elsewhere :-) *cough* extable *cough*
> 
> Eww. I hadn't looked at that (or repressed it if I did). *Shudder*.
> 
> But looking around, I don't think any of the normal code I ever look
> at actually *generate* that disgusting thing.
> 
> I had to search for it, and looked at the absolute horror it generates
> in the futex code, and honestly, if I ever have to look at that
> garbage, I would throw up.
> 
> And WARN_ONCE() is in stuff I *do* look at.
> 
> So no. I'm NAK'ing it just because it makes the asm look entirely unreadable.
> 
> And no, I'm not ok with only using 'objdump' and friends to look at
> assembly generation. I want to be able to do
> 
>    make xyz.s
> 
> and look at code generation without throwing up.
> 
> The fact that we have this disgusting thing elsewhere in places that
> I've not looked at does *not* excuse adding it to other places.

Right. So the problem is using asm macros in inline-asm. We've tried
adding those macros to a global asm, but IIRC that had trouble.

So yeah, now we do the macro definition and purge right around the
inline asm and then you get this horror show :-(

Anyway, I'll try and come up with something else.