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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 May 2024 19:23:33 -0700
From: Stephen Brennan <stephen.s.brennan@...cle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
        Masami Hiramatsu
 <mhiramat@...nel.org>
Cc: Andrii Nakryiko <andrii@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
        Jonathan Haslam <jonathan.haslam@...il.com>,
        Kui-Feng Lee
 <thinker.li@...il.com>, Ye Bin <yebin10@...wei.com>,
        Steven Rostedt
 <rostedt@...dmis.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] probes updates for v6.10

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Wed, 15 May 2024 at 17:52, Masami Hiramatsu <mhiramat@...nel.org> wrote:
>>
>> Probes updates for v6.10:
>
> Grr,
>
> This doesn't even build right.
>
> Yes, it builds cleanly in an allmoconfig build, which is what I did
> before I pushed out.
>
> But after pushing out, I notice that it doesn't build in more limited
> configurations and with clang, because:
>
>> Stephen Brennan (1):
>>       kprobe/ftrace: bail out if ftrace was killed
>
> This is no longer valid C code, and hasn't been for a long long while:
>
>     void kprobe_ftrace_kill()
>     {
>         kprobe_ftrace_disabled = true;
>     }
>
> we require proper prototypes, not some ancient per-ANSI K&R syntax.
>
> It turns out that gcc apparently still accepts these things, but it
> really shouldn't. But with a clang build, you get a big error:
>
>     kernel/kprobes.c:1140:24: error: a function declaration without a
> prototype is deprecated in all versions of C
> [-Werror,-Wstrict-prototypes]
>
> and the reason it didn't get noticed in -next is that this commit had
> apparently not *been* in linux-next.
>
> Dammit, that's now how any of this is supposed to work.
>
> Why was this untested crap sent to me?

Hi Linus,

Yes, this was may fault for missing "(void)", that's basic and shouldn't
have gone out. I was too focused on getting a prototype for each
possible configuration that I couldn't see the forest for the trees!

My GCC builds were not W=1, which I will do next time. I would have seen
this with a W=1 build. I can't speak for why it wasn't in -next, but it
did get caught yesterday and I sent a fix:

https://lore.kernel.org/oe-kbuild-all/202405170340.eyEMhYvc-lkp@intel.com/

My apologies.

-Stephen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ