From: Tom Rix <trix@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] bug: mark generic BUG() as unreachable
Date: Fri, 18 Jun 2021 06:43:13 -0700 [thread overview]
Message-ID: <312e5b85-bfa5-e7f1-c1f7-a13a5d2583b8@redhat.com> (raw)
In-Reply-To: <CAK8P3a14uKvDZ4OevR5z2+AJervkepDcPjGWwstTo5antbQyXA@mail.gmail.com>
On 6/18/21 1:20 AM, Arnd Bergmann wrote:
> On Thu, Jun 17, 2021 at 11:44 PM <trix@redhat.com> wrote:
>> From: Tom Rix <trix@redhat.com>
>>
>> This spurious error is reported for powerpc64, CONFIG_BUG=n
>>
>> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
>> index f152b9bb916fc..b250e06d7de26 100644
>> --- a/include/asm-generic/bug.h
>> +++ b/include/asm-generic/bug.h
>> @@ -177,7 +177,10 @@ void __warn(const char *file, int line, void *caller, unsigned taint,
>>
>> #else /* !CONFIG_BUG */
>> #ifndef HAVE_ARCH_BUG
>> -#define BUG() do {} while (1)
>> +#define BUG() do { \
>> + do {} while (1); \
>> + unreachable(); \
>> + } while (0)
>> #endif
> Please let's not go back to this version, we had good reasons to use
> the infinite loop,
> mostly to avoid undefined behavior that would lead to the compiler producing
> completely random output in code paths that lead to a BUG() statement. Those
> do cause other kinds of warnings from objtool and from other compilers.
>
> The obvious workaround here would be to add a return statement locally, but
> it may also help to figure out what exactly triggers the warning, as I don't see
> it in my randconfig builds and it may be that there is a bug elsewhere.
>
> I've tried a simple reproducer on https://godbolt.org/z/341P949bG that did not
> show this warning in any of the compilers I tried. Can you try to narrow down
> the exact compiler versions and commmand line options that produce the
> warning? https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/ has
> most of the supported gcc versions in case you need those.
Please follow the link in the cover letter to the original issue
reported for fs/afs/dir + gcc ppc64 9.x / 10.3.1
Adding the return was the first, rejected solution.
Tom
>
> Arnd
>
next prev parent reply other threads:[~2021-06-18 13:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 21:43 [PATCH 0/1] bug: mark generic BUG() as unreachable trix
2021-06-17 21:43 ` [PATCH 1/1] " trix
2021-06-18 8:20 ` Arnd Bergmann
2021-06-18 13:43 ` Tom Rix [this message]
2021-06-18 14:35 ` 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=312e5b85-bfa5-e7f1-c1f7-a13a5d2583b8@redhat.com \
--to=trix@redhat.com \
--cc=arnd@arndb.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.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.