From: Danilo Krummrich <dakr@kernel.org>
To: Alistair Popple <apopple@nvidia.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
gregkh@linuxfoundation.org, rafael@kernel.org,
bhelgaas@google.com, ojeda@kernel.org, alex.gaynor@gmail.com,
boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com,
benno.lossin@proton.me, tmgross@umich.edu,
a.hindborg@samsung.com, aliceryhl@google.com, airlied@gmail.com,
fujita.tomonori@gmail.com, lina@asahilina.net,
pstanner@redhat.com, ajanulgu@redhat.com, lyude@redhat.com,
robh@kernel.org, daniel.almeida@collabora.com,
saravanak@google.com, dirk.behme@de.bosch.com, j@jannau.net,
fabien.parent@linaro.org, chrisi.schrefl@gmail.com,
paulmck@kernel.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, rcu@vger.kernel.org
Subject: Re: [PATCH v7 07/16] rust: add `io::{Io, IoRaw}` base types
Date: Tue, 25 Feb 2025 12:04:35 +0100 [thread overview]
Message-ID: <Z72jw3TYJHm7N242@pollux> (raw)
In-Reply-To: <wnzq3vlgawjdchjck7nzwlzmm5qbmactwlhtj44ak7s7kefphd@m7emgjnmnkjn>
On Tue, Feb 25, 2025 at 04:50:05PM +1100, Alistair Popple wrote:
> Kind of, but given the current state of build_assert's and the impossiblity of
> debugging them should we avoid adding them until they can be fixed?
If you build the module as built-in the linker gives you some more hints, but
I agree it's still not great.
I think build_assert() is not widely used yet and, until the situation improves,
we could also keep a list of common pitfalls if that helps?
> Unless the code absolutely cannot compile without them I think it would be
> better to turn them into runtime errors that can at least hint at what might
> have gone wrong. For example I think a run-time check would have been much more
> appropriate and easy to debug here, rather than having to bisect my changes.
No, especially for I/O the whole purpose of the non-try APIs is to ensure that
boundary checks happen at compile time.
> I was hoping I could suggest CONFIG_RUST_BUILD_ASSERT_ALLOW be made default yes,
> but testing with that also didn't yeild great results - it creates a backtrace
> but that doesn't seem to point anywhere terribly close to where the bad access
> was, I'm guessing maybe due to inlining and other optimisations - or is
> decode_stacktrace.sh not the right tool for this job?
I was about to suggest CONFIG_RUST_BUILD_ASSERT_ALLOW=y to you, since this will
make the kernel panic when hitting a build_assert().
I gave this a quick try with [1] in qemu and it lead to the following hint,
right before the oops:
[ 0.957932] rust_kernel: panicked at /home/danilo/projects/linux/nova/nova-next/rust/kernel/io.rs:216:9:
Seeing this immediately tells me that I'm trying to do out of bound I/O accesses
in my driver, which indeed doesn't tell me the exact line (in case things are
inlined too much to gather it from the backtrace of the oops), but it should be
good enough, no?
[1]
diff --git a/samples/rust/rust_driver_pci.rs b/samples/rust/rust_driver_pci.rs
index 1fb6e44f3395..2ff3af11d711 100644
--- a/samples/rust/rust_driver_pci.rs
+++ b/samples/rust/rust_driver_pci.rs
@@ -13,7 +13,7 @@ impl Regs {
const OFFSET: usize = 0x4;
const DATA: usize = 0x8;
const COUNT: usize = 0xC;
- const END: usize = 0x10;
+ const END: usize = 0x2;
}
type Bar0 = pci::Bar<{ Regs::END }>;
next prev parent reply other threads:[~2025-02-25 11:04 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 17:04 [PATCH v7 00/16] Device / Driver PCI / Platform Rust abstractions Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 01/16] rust: module: add trait `ModuleMetadata` Danilo Krummrich
2024-12-24 20:51 ` Gary Guo
2024-12-19 17:04 ` [PATCH v7 02/16] rust: implement generic driver registration Danilo Krummrich
2024-12-24 19:58 ` Gary Guo
2025-01-02 9:34 ` Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 03/16] rust: implement `IdArray`, `IdTable` and `RawDeviceId` Danilo Krummrich
2024-12-24 20:10 ` Gary Guo
2025-01-02 9:36 ` Danilo Krummrich
2025-03-15 16:52 ` Tamir Duberstein
2025-03-15 16:59 ` Danilo Krummrich
2025-03-15 17:31 ` Tamir Duberstein
2024-12-19 17:04 ` [PATCH v7 04/16] rust: add rcu abstraction Danilo Krummrich
2024-12-24 20:54 ` Gary Guo
2025-01-02 9:44 ` Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 05/16] rust: types: add `Opaque::pin_init` Danilo Krummrich
2024-12-24 20:21 ` Gary Guo
2024-12-19 17:04 ` [PATCH v7 06/16] rust: add `Revocable` type Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 07/16] rust: add `io::{Io, IoRaw}` base types Danilo Krummrich
2025-01-16 10:31 ` Fiona Behrens
2025-01-20 12:54 ` Danilo Krummrich
2025-02-21 1:20 ` Alistair Popple
2025-02-21 3:58 ` Miguel Ojeda
2025-02-25 5:50 ` Alistair Popple
2025-02-25 11:04 ` Danilo Krummrich [this message]
2025-02-27 0:25 ` Alistair Popple
2025-02-27 10:01 ` Danilo Krummrich
2025-02-28 5:29 ` Alistair Popple
2025-02-28 10:12 ` Danilo Krummrich
2025-02-28 10:22 ` Miguel Ojeda
2025-02-27 16:06 ` Miguel Ojeda
2024-12-19 17:04 ` [PATCH v7 08/16] rust: add devres abstraction Danilo Krummrich
2024-12-24 21:53 ` Gary Guo
2025-01-02 10:30 ` Danilo Krummrich
2025-01-02 15:59 ` Danilo Krummrich
2025-01-14 16:33 ` Danilo Krummrich
2025-01-15 6:41 ` Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 09/16] rust: pci: add basic PCI device / driver abstractions Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 10/16] rust: pci: implement I/O mappable `pci::Bar` Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 11/16] samples: rust: add Rust PCI sample driver Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 12/16] rust: of: add `of::DeviceId` abstraction Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 13/16] rust: driver: implement `Adapter` Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 14/16] rust: platform: add basic platform device / driver abstractions Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 15/16] samples: rust: add Rust platform sample driver Danilo Krummrich
2024-12-19 17:04 ` [PATCH v7 16/16] MAINTAINERS: add Danilo to DRIVER CORE Danilo Krummrich
2024-12-20 7:24 ` [PATCH v7 00/16] Device / Driver PCI / Platform Rust abstractions Dirk Behme
2024-12-20 16:44 ` Greg KH
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=Z72jw3TYJHm7N242@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@samsung.com \
--cc=airlied@gmail.com \
--cc=ajanulgu@redhat.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=benno.lossin@proton.me \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=chrisi.schrefl@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=dirk.behme@de.bosch.com \
--cc=fabien.parent@linaro.org \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=j@jannau.net \
--cc=lina@asahilina.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=paulmck@kernel.org \
--cc=pstanner@redhat.com \
--cc=rafael@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=saravanak@google.com \
--cc=tmgross@umich.edu \
/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;
as well as URLs for NNTP newsgroup(s).