[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241218090422.c66wse2kswnazkou@jpoimboe>
Date: Wed, 18 Dec 2024 01:04:22 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Marco Elver <elver@...gle.com>, Arnd Bergmann <arnd@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andrey Konovalov <andreyknvl@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Dmitry Vyukov <dvyukov@...gle.com>,
Aleksandr Nogikh <nogikh@...gle.com>, kasan-dev@...glegroups.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kcov: mark in_softirq_really() as __always_inline
On Wed, Dec 18, 2024 at 09:49:46AM +0100, Arnd Bergmann wrote:
> On Wed, Dec 18, 2024, at 09:40, Josh Poimboeuf wrote:
> > On Tue, Dec 17, 2024 at 09:30:24AM +0100, Marco Elver wrote:
> >> On Tue, 17 Dec 2024 at 08:18, Arnd Bergmann <arnd@...nel.org> wrote:
> >> >
> >> > From: Arnd Bergmann <arnd@...db.de>
> >> >
> >> > If gcc decides not to inline in_softirq_really(), objtool warns about
> >> > a function call with UACCESS enabled:
> >> >
> >> > kernel/kcov.o: warning: objtool: __sanitizer_cov_trace_pc+0x1e: call to in_softirq_really() with UACCESS enabled
> >> > kernel/kcov.o: warning: objtool: check_kcov_mode+0x11: call to in_softirq_really() with UACCESS enabled
> >> >
> >> > Mark this as __always_inline to avoid the problem.
> >> >
> >> > Fixes: 7d4df2dad312 ("kcov: properly check for softirq context")
> >> > Signed-off-by: Arnd Bergmann <arnd@...db.de>
> >>
> >> __always_inline is the usual approach for code that can be
> >> instrumented - but I thought we explicitly never instrument
> >> kernel/kcov.c with anything. So I'm rather puzzled why gcc would not
> >> inline this function. In any case "inline" guarantees nothing, so:
> >
> > I'm guessing CONFIG_DEBUG_SECTION_MISMATCH was enabled, which enables
> > -fno-inline-functions-called-once which ends up being the cause of a lot
> > of these __always_inline patches.
> >
> > I had a patch to get rid of that at some point, guess it got lost...
>
> It doesn't seem to be the cause here, I get the warning both with
> and without CONFIG_DEBUG_SECTION_MISMATCH in random configurations.
> I've attached one .config that shows the problem without this
> option in case you want to investigate further.
Guess I should have looked closer, that function is called more than
once, never mind...
--
Josh
Powered by blists - more mailing lists