From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Arnd Bergmann <arnd@arndb.de>,
Michael Ellerman <mpe@ellerman.id.au>,
Adrian Hunter <adrian.hunter@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
John Stultz <jstultz@google.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
"x86@kernel.org" <x86@kernel.org>,
Aneesh Kumar K.V <aneesh.kumar@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Nicholas Piggin <npiggin@gmail.com>,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Anna-Maria Gleixner <anna-maria@linutronix.de>,
Stephen Boyd <sboyd@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Sven Schnelle <svens@linux.ibm.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] bug: Fix no-return-statement warning with !CONFIG_BUG
Date: Mon, 15 Apr 2024 17:07:15 +0000 [thread overview]
Message-ID: <a87bed5b-edb7-4ba2-bdd1-88fcd1da7b69@csgroup.eu> (raw)
In-Reply-To: <e0cf6827-06c2-4212-848c-10d275c75546@app.fastmail.com>
Le 15/04/2024 à 17:35, Arnd Bergmann a écrit :
> On Mon, Apr 15, 2024, at 04:19, Michael Ellerman wrote:
>> "Arnd Bergmann" <arnd@arndb.de> writes:
>>> On Thu, Apr 11, 2024, at 11:27, Adrian Hunter wrote:
>>>> On 11/04/24 11:22, Christophe Leroy wrote:
>>>>
>>>> That is fragile because it depends on defined(__OPTIMIZE__),
>>>> so it should still be:
>>>
>>> If there is a function that is defined but that must never be
>>> called, I think we are doing something wrong.
>>
>> It's a pretty inevitable result of using IS_ENABLED(), which the docs
>> encourage people to use.
>
> Using IS_ENABLED() is usually a good idea, as it helps avoid
> adding extra #ifdef checks and just drops static functions as
> dead code, or lets you call extern functions that are conditionally
> defined in a different file.
>
> The thing is that here it does not do either of those and
> adds more complexity than it avoids.
>
>> In this case it could easily be turned into a build error by just making
>> it an extern rather than a static inline.
>>
>> But I think Christophe's solution is actually better, because it's more
>> explicit, ie. this function should not be called and if it is that's a
>> build time error.
>
> I haven't seen a good solution here. Ideally we'd just define
> the functions unconditionally and have IS_ENABLED() take care
> of letting the compiler drop them silently, but that doesn't
> build because of missing struct members.
>
> I won't object to either an 'extern' declaration or the
> 'BUILD_BUG_ON()' if you and others prefer that, both are better
> than BUG() here. I still think my suggestion would be a little
> simpler.
The advantage of the BUILD_BUG() against the extern is that the error
gets detected at buildtime. With the extern it gets detected only at
link-time.
But agree with you, the missing struct members defeats the advantages of
IS_ENABLED().
At the end, how many instances of struct timekeeper do we have in the
system ? With a quick look I see only two instances: tkcore.timekeeper
and shadow_timekeeper. If I'm correct, wouldn't it just be simpler to
have the three debug struct members defined at all time ?
Christophe
next prev parent reply other threads:[~2024-04-15 17:07 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 15:32 [PATCH] bug: Fix no-return-statement warning with !CONFIG_BUG Adrian Hunter
2024-04-10 15:32 ` Adrian Hunter
2024-04-10 17:02 ` Naresh Kamboju
2024-04-10 17:02 ` Naresh Kamboju
2024-04-10 20:05 ` [tip: timers/urgent] " tip-bot2 for Adrian Hunter
2024-04-11 7:04 ` [PATCH] " Arnd Bergmann
2024-04-11 7:04 ` Arnd Bergmann
2024-04-11 7:16 ` Adrian Hunter
2024-04-11 7:16 ` Adrian Hunter
2024-04-11 7:56 ` Arnd Bergmann
2024-04-11 9:03 ` Adrian Hunter
2024-04-11 10:27 ` David Laight
2024-04-11 8:13 ` Christophe Leroy
2024-04-11 8:13 ` Christophe Leroy
2024-04-11 8:22 ` Christophe Leroy
2024-04-11 8:22 ` Christophe Leroy
2024-04-11 9:27 ` Adrian Hunter
2024-04-11 9:27 ` Adrian Hunter
2024-04-11 11:26 ` Arnd Bergmann
2024-04-11 11:26 ` Arnd Bergmann
2024-04-15 2:19 ` Michael Ellerman
2024-04-15 15:35 ` Arnd Bergmann
2024-04-15 15:35 ` Arnd Bergmann
2024-04-15 17:07 ` Christophe Leroy [this message]
2024-04-15 17:32 ` Arnd Bergmann
2024-04-15 17:32 ` Arnd Bergmann
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=a87bed5b-edb7-4ba2-bdd1-88fcd1da7b69@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=adrian.hunter@intel.com \
--cc=agordeev@linux.ibm.com \
--cc=aneesh.kumar@kernel.org \
--cc=anna-maria@linutronix.de \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=naresh.kamboju@linaro.org \
--cc=naveen.n.rao@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=sboyd@kernel.org \
--cc=svens@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=vincenzo.frascino@arm.com \
--cc=x86@kernel.org \
/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.