From: "Arnd Bergmann" <arnd@arndb.de>
To: "Michael Ellerman" <mpe@ellerman.id.au>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Christophe Leroy" <christophe.leroy@csgroup.eu>
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:35:30 +0200 [thread overview]
Message-ID: <e0cf6827-06c2-4212-848c-10d275c75546@app.fastmail.com> (raw)
In-Reply-To: <875xwjcqpl.fsf@mail.lhotse>
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.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Michael Ellerman" <mpe@ellerman.id.au>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Christophe Leroy" <christophe.leroy@csgroup.eu>
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 Sch nelle <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:35:30 +0200 [thread overview]
Message-ID: <e0cf6827-06c2-4212-848c-10d275c75546@app.fastmail.com> (raw)
In-Reply-To: <875xwjcqpl.fsf@mail.lhotse>
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.
Arnd
next prev parent reply other threads:[~2024-04-15 15:35 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 [this message]
2024-04-15 15:35 ` Arnd Bergmann
2024-04-15 17:07 ` Christophe Leroy
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=e0cf6827-06c2-4212-848c-10d275c75546@app.fastmail.com \
--to=arnd@arndb.de \
--cc=adrian.hunter@intel.com \
--cc=agordeev@linux.ibm.com \
--cc=aneesh.kumar@kernel.org \
--cc=anna-maria@linutronix.de \
--cc=bhelgaas@google.com \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=christophe.leroy@csgroup.eu \
--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.