From: Greg KH <gregkh@linuxfoundation.org>
To: FUJITA Tomonori <tomo@aliasing.net>
Cc: dakr@kernel.org, ojeda@kernel.org, a.hindborg@kernel.org,
acourbot@nvidia.com, aliceryhl@google.com,
bjorn3_gh@protonmail.com, boqun@kernel.org,
daniel.almeida@collabora.com, gary@garyguo.net,
lossin@kernel.org, tamird@kernel.org, tmgross@umich.edu,
work@onurozkan.dev, rust-for-linux@vger.kernel.org,
fujita.tomonori@gmail.com
Subject: Re: [PATCH v1] rust: bug: Add bug_on macro
Date: Wed, 8 Jul 2026 07:29:31 +0200 [thread overview]
Message-ID: <2026070841-unplanned-lagoon-651f@gregkh> (raw)
In-Reply-To: <20260708.074859.867796876307901722.fujita@bee>
On Wed, Jul 08, 2026 at 07:48:59AM +0900, FUJITA Tomonori wrote:
> On Tue, 7 Jul 2026 17:20:10 +0200
> Greg KH <gregkh@linuxfoundation.org> wrote:
>
> > On Tue, Jul 07, 2026 at 04:51:40PM +0200, Danilo Krummrich wrote:
> >> On Tue Jul 7, 2026 at 4:30 PM CEST, FUJITA Tomonori wrote:
> >> > Use of this macro is heavily discouraged. Prefer warn_on() macro with
> >> > recovery code where feasible. See the documentation for C's BUG_ON()
> >> > for guidance on when it is rarely justified.
> >>
> >> Given that, can you please spell out the motivation for this patch?
> >
> > I agree, this should probably NOT be added unless there is a real user
> > for it that requires it and we all agree that crashing the system is the
> > only way out.
>
> bindings::BUG() is already in use today, indirectly, from the kernel
> crate itself and from drivers such as binder and nova-core, via
> panic!()/.exepct().unwrap() on invariants that "can't happen". All of
> those funnel through panic() in kernel/lib.rs (#[panic_handler]),
> which itself calls BUG().
>
> The motivation for this patch is narrow: replace that bindings::BUG()
> call in lib.rs's panic() with bug_on!(), for a somewhat better
> trace. It isn't adding a new decision to crash the system -- that
> decision is already made at each of the existing panic!()/.expect()
> call sites.
That wasn't obvious that this was the reason why this change was being
introduced, perhaps the changelog should have said that?
thanks,
greg k-h
prev parent reply other threads:[~2026-07-08 5:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 14:30 [PATCH v1] rust: bug: Add bug_on macro FUJITA Tomonori
2026-07-07 14:51 ` Danilo Krummrich
2026-07-07 15:20 ` Greg KH
2026-07-07 22:48 ` FUJITA Tomonori
2026-07-08 5:29 ` Greg KH [this message]
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=2026070841-unplanned-lagoon-651f@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=tomo@aliasing.net \
--cc=work@onurozkan.dev \
/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.