Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Jiri Kosina <jikos@kernel.org>,
	Benjamin Tissoires <bentiss@kernel.org>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	llvm@lists.linux.dev
Subject: Re: [PATCH] HID: simplify code in fetch_item()
Date: Tue, 15 Apr 2025 09:45:58 +0300	[thread overview]
Message-ID: <Z_4ApoWzgWSovgRi@smile.fi.intel.com> (raw)
In-Reply-To: <20250415003326.GA4164044@ax162>

On Mon, Apr 14, 2025 at 05:33:26PM -0700, Nathan Chancellor wrote:
> On Mon, Apr 14, 2025 at 09:30:36AM +0300, Andy Shevchenko wrote:
> > On Thu, Oct 10, 2024 at 03:24:51PM -0700, Nathan Chancellor wrote:
> > > On Tue, Oct 01, 2024 at 08:42:36AM -0700, Dmitry Torokhov wrote:

...

> > > Getting rid of the unreachable() in some way resolves the issue. I
> > > tested using BUG() in lieu of unreachable() like the second change I
> > > mentioned above, which resolves the issue cleanly, as the default case
> > > clearly cannot happen. ...
> > 
> > As Dmitry pointed out to this old discussion, I have a question about the above
> > test. Have you tried to use BUG() while CONFIG_BUG=n? Does it _also_ solve the
> > issue?
> 
> Yes because x86 appears to always emit ud2 for BUG() regardless of
> whether CONFIG_BUG is set or not since HAVE_ARCH_BUG is always
> respected.

Thank you for the reply. But do you know if this is guaranteed on the rest of
supported architectures? I.o.w. may we assume that BUG() in lieu of unreachable()
will always fix the issue?

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2025-04-15  6:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ZvwYbESMZ667QZqY@google.com>
2024-10-10 22:24 ` [PATCH] HID: simplify code in fetch_item() Nathan Chancellor
2024-10-15 18:28   ` Dmitry Torokhov
2024-10-15 18:56     ` Paul E. McKenney
2024-10-15 19:26     ` Nathan Chancellor
2024-10-15 20:59       ` Segher Boessenkool
2025-04-14  6:30   ` Andy Shevchenko
2025-04-15  0:33     ` Nathan Chancellor
2025-04-15  6:45       ` Andy Shevchenko [this message]
2025-04-15 15:21         ` Nathan Chancellor
2025-04-16  6:48           ` Andy Shevchenko

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=Z_4ApoWzgWSovgRi@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=bentiss@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox