From: Stephen Brennan <stephen.s.brennan@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Masami Hiramatsu <mhiramat@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Jonathan Haslam <jonathan.haslam@gmail.com>,
Kui-Feng Lee <thinker.li@gmail.com>, Ye Bin <yebin10@huawei.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] probes updates for v6.10
Date: Fri, 17 May 2024 19:23:33 -0700 [thread overview]
Message-ID: <878r07q2my.fsf@oracle.com> (raw)
In-Reply-To: <CAHk-=wgQ_MNipb2fOSDmXJ9tYko8OhzA0fPueR-kh6eYT_MbDg@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 15 May 2024 at 17:52, Masami Hiramatsu <mhiramat@kernel.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
next prev parent reply other threads:[~2024-05-18 2:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 0:52 [GIT PULL] probes updates for v6.10 Masami Hiramatsu
2024-05-18 1:54 ` pr-tracker-bot
2024-05-18 2:12 ` Linus Torvalds
2024-05-18 2:23 ` Stephen Brennan [this message]
2024-05-18 14:38 ` Masami Hiramatsu
2024-05-18 15:55 ` Linus Torvalds
2024-05-18 23:46 ` Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878r07q2my.fsf@oracle.com \
--to=stephen.s.brennan@oracle.com \
--cc=andrii@kernel.org \
--cc=jolsa@kernel.org \
--cc=jonathan.haslam@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=thinker.li@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=yebin10@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.