From: Paul Cercueil <paul@crapouillou.net>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH] pinctrl: ingenic: Make unreachable path more robust
Date: Wed, 19 Feb 2020 22:36:57 -0300 [thread overview]
Message-ID: <1582162617.3.1@crapouillou.net> (raw)
In-Reply-To: <20200217151804.yymflofpbiqjqnnz@treble>
Hi Josh,
Le lun., févr. 17, 2020 at 09:18, Josh Poimboeuf <jpoimboe@redhat.com>
a écrit :
> On Fri, Feb 14, 2020 at 11:37:04PM -0300, Paul Cercueil wrote:
>> > > I don't like the idea that you change this driver's code just
>> to
>> > > work around
>> > > a bug in objtool, and I don't like the idea of working around a
>> > > future bug
>> > > that shouldn't be introduced in the first place.
>> >
>> > It's not an objtool bug. It's a byproduct of the fact that GCC's
>> > undefined behavior is inscrutable, and there's no way to
>> determine that
>> > it actually *wants* to jump to a random function.
>> >
>> > And anyway, regardless of objtool, the patch is meant to make the
>> code
>> > more robust.
>> >
>> > Do you not agree that BUG (defined behavior) is more robust than
>> > unreachable (undefined behavior)?
>>
>> It's a dead code path. That would be an undefined behaviour, if it
>> was
>> taken, but it's not.
>
> Given your confidence that humans don't introduce bugs, would you
> recommend that we
>
> s/BUG()/unreachable()/
>
> tree-wide?
Of course not.
> Another option would be to remove the unreachable() statement, which
> would actually improve the generated code by making it more compact
> (16
> bytes of i-cache savings), on top of removing the "fallthrough to next
> function" nastiness.
I'd prefer that, yes.
-Paul
> diff --git a/drivers/pinctrl/pinctrl-ingenic.c
> b/drivers/pinctrl/pinctrl-ingenic.c
> index 96f04d121ebd..13c7d3351ed5 100644
> --- a/drivers/pinctrl/pinctrl-ingenic.c
> +++ b/drivers/pinctrl/pinctrl-ingenic.c
> @@ -2158,7 +2158,8 @@ static int ingenic_pinconf_set(struct
> pinctrl_dev *pctldev, unsigned int pin,
> break;
>
> default:
> - unreachable();
> + /* unreachable */
> + break;
> }
> }
>
>
next prev parent reply other threads:[~2020-02-20 1:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 16:37 [PATCH] pinctrl: ingenic: Make unreachable path more robust Josh Poimboeuf
2020-02-14 19:02 ` Paul Cercueil
2020-02-14 20:37 ` Josh Poimboeuf
2020-02-15 2:37 ` Paul Cercueil
2020-02-17 15:18 ` Josh Poimboeuf
2020-02-20 1:36 ` Paul Cercueil [this message]
2020-02-14 21:52 ` Randy Dunlap
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=1582162617.3.1@crapouillou.net \
--to=paul@crapouillou.net \
--cc=jpoimboe@redhat.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.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.