On Mon, Apr 28, 2025 at 12:34:27PM -0700, Linus Torvalds wrote:
> And yes, this really is a very potential and real security issue. In
> the kernel I don't think we have this ever happening, partly because a
> lot of configurations use gcc which afaik doesn't have this particular
> horrendous mode
On Mon, Apr 28, 2025 at 12:34 PM Linus Torvalds
wrote:
>
> On Mon, 28 Apr 2025 at 11:08, Bill Wendling wrote:
> >
> > This situation is one of the
> > easier ones: "do something other than fall into the next function";
>
> Note that the "fall into the next function" is just something that
> objto
On Mon, 28 Apr 2025 at 12:54, Josh Poimboeuf wrote:
>
> BTW, I've noticed Clang also generates UB for negative shift values. I
> assume we'd want it to stop checking for those as well.
Yeah, that seems to match the exact same issue.
And again - the correct fix would be for the compiler to not d
On Mon, Apr 28, 2025 at 12:34:27PM -0700, Linus Torvalds wrote:
> Honestly, the least wrong thing is to just NOT HAVE THE CHECK FOR ZERO AT ALL.
>
> IOW, just generate the divide instruction.
>
> I can almost guarantee that that will actually then generate the best
> code too, because you'll prob
On Mon, 28 Apr 2025 at 11:08, Bill Wendling wrote:
>
> This situation is one of the
> easier ones: "do something other than fall into the next function";
Note that the "fall into the next function" is just something that
objtool notices. It *could* be "fall into the next basic block of the
same f
On Sat, Apr 26, 2025 at 5:31 PM Linus Torvalds
wrote:
> So please. Clang people need to get a clue. Yes, we care *deeply*
> about performance in the kernel, but a C compiler that thinks that
> using UD to generate "better" code is a disgrace and pure garbage.
> Because security matters a whole lot
On Sat, Apr 26, 2025 at 1:57 PM Linus Torvalds
wrote:
>
> On Sat, 26 Apr 2025 at 13:05, Nathan Chancellor wrote:
> >
> > KBUILD_CFLAGS += -mllvm -trap-unreachable
>
> Hmm. That certainly builds for me, but yeah, it generates new objtool
> warnings, notably
>
>panic() missing __noreturn in
On Sat, 26 Apr 2025 at 16:23, Nathan Chancellor wrote:
>
> Pardon my ignorance though, isn't something like this
> basically just '-fsanitize=undefined -fsanitize-trap=all'?
Sure. Except -fsanitize=undefined is a horrible horrible thing.
Why? Because it pointlessly adds code to *look* for undef
On Sat, Apr 26, 2025 at 01:56:59PM -0700, Linus Torvalds wrote:
> IOW, there's a *big* difference between "the programmer told me this
> is unreachable, so I won't generate code past this point" and "I have
> decided this is undefined behavior, so now I won't generate code past
> this point".
>
>
On Sat, 26 Apr 2025 at 13:05, Nathan Chancellor wrote:
>
> KBUILD_CFLAGS += -mllvm -trap-unreachable
Hmm. That certainly builds for me, but yeah, it generates new objtool
warnings, notably
panic() missing __noreturn in .c/.h or NORETURN() in noreturns.h
and I *think* that is because that
Hi Linus,
On Sat, Apr 26, 2025 at 10:42:40AM -0700, Linus Torvalds wrote:
> But I *really* think that clang silently just generating known bad
> code for invalida operations like this is very very dangerous, and is
> a bug in clang.
>
> Can we *please* get a flag for clang that it doesn't just st
On Sat, 26 Apr 2025 at 10:42, Linus Torvalds
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
So with clang, I get these drm build warnings
drivers/gpu/drm/amd/amdgpu/../display/dc/basics/fixpt31_32.o:
warning: objtool: dc_fixpt_recip() falls through to next function
dc_fixpt_sinc()
drivers/gpu/drm/amd/amdgpu/../display/dc/sspl/spl_fixpt31_32.o:
warning: objtool: spl_fixpt_r
13 matches
Mail list logo
