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-=wip2-yTrWpAkrUQ0iejEo2PjReddu4xntwBvdnSvWDbzg@mail.gmail.com>
Date: Sat, 26 Apr 2025 10:52:10 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>, Harry Wentland <harry.wentland@....com>, 
	Leo Li <sunpeng.li@....com>, Alex Deucher <alexander.deucher@....com>, 
	Christian König <christian.koenig@....com>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <nick.desaulniers+lkml@...il.com>, 
	Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>
Cc: "the arch/x86 maintainers" <x86@...nel.org>, dri-devel <dri-devel@...ts.freedesktop.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: clang and drm issue: objtool warnings from clang build

On Sat, 26 Apr 2025 at 10:42, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> We had something similar some time ago, where there was a drm
> assertion without error handling, which caused the compiler to see
> that there was a static path where the invalid value was used, and
> then caused other problems. I forget the details, and gmail search
> isn't helping me

My dim memories came back and helped me with the right search terms,
and this is what I was talking about:

   https://lore.kernel.org/all/CAHk-=wg4ETks+pGUco4gDrRxT+1UBbFGQtpOqSxLSzvVAWpm5w@mail.gmail.com/

different compiler, very different results, but same kind of issue:
warning about an error case without actually *dealing* with the error,
which results in the compiler seeing a static code path from the
warning to an invalid situation, and causing odd problems.

Please people: "ASSERT()" like behavior is simply not acceptable in
the kernel. WARN_ON() and friends need to either be otherwise benign
(ie "warn but then continue to do valid things") or they need to be
*handled* (ie "warn and then refuse to do things that aren't valid").

Just warning and then doing random crap is not sane. If you aren't
capable of dealing with the situation, don't do the bogus test. Just
warning about it isn't fixing the code, and can make things actively
worse as in these two examples.

But I do think that clang needs to stop doing that "make things
actively worse" part. Maybe even have an actual honest-to-goodness
"this is a static undefined situation, I will stop generating code AND
THAT MEANS I FAIL THE BUILD".

Not this silent "now I generate random code by falling through to
something else entirely" that clang does now. Not good.

              Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ