linux-kernel - Re: [PATCH v7 07/16] rust: add `io::{Io, IoRaw}` base types

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <wnzq3vlgawjdchjck7nzwlzmm5qbmactwlhtj44ak7s7kefphd@m7emgjnmnkjn>
Date: Tue, 25 Feb 2025 16:50:05 +1100
From: Alistair Popple <apopple@...dia.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Danilo Krummrich <dakr@...nel.org>, gregkh@...uxfoundation.org, 
	rafael@...nel.org, bhelgaas@...gle.com, ojeda@...nel.org, alex.gaynor@...il.com, 
	boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com, 
	benno.lossin@...ton.me, tmgross@...ch.edu, a.hindborg@...sung.com, aliceryhl@...gle.com, 
	airlied@...il.com, fujita.tomonori@...il.com, lina@...hilina.net, 
	pstanner@...hat.com, ajanulgu@...hat.com, lyude@...hat.com, robh@...nel.org, 
	daniel.almeida@...labora.com, saravanak@...gle.com, dirk.behme@...bosch.com, j@...nau.net, 
	fabien.parent@...aro.org, chrisi.schrefl@...il.com, paulmck@...nel.org, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org, 
	devicetree@...r.kernel.org, rcu@...r.kernel.org
Subject: Re: [PATCH v7 07/16] rust: add `io::{Io, IoRaw}` base types

On Fri, Feb 21, 2025 at 04:58:59AM +0100, Miguel Ojeda wrote:
> Hi Alistair,
> 
> On Fri, Feb 21, 2025 at 2:20 AM Alistair Popple <apopple@...dia.com> wrote:
> >
> > Is this a known issue or limitation? Or is this a bug/rough edge that still
> > needs fixing? Or alternatively am I just doing something wrong? Would appreciate
> > any insights as figuring out what I'd done wrong here was a bit of a rough
> > introduction!
> 
> Yeah, it is a result of our `build_assert!` machinery:
> 
>     https://rust.docs.kernel.org/kernel/macro.build_assert.html
> 
> which works by producing a build (link) error rather than the usual
> compiler error and thus the bad error message.
> 
> `build_assert!` is really the biggest hammer we have to assert
> something is true at build time, since it may rely on the optimizer.
> For instance, if `static_assert!` is usable in that context, it should
> be instead of `build_assert!`.
> 
> Ideally we would have a way to get the message propagated somehow,
> because it is indeed confusing.

Are there any proposals or ideas for how we could do that?

> I hope that helps.

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?

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.

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?

Thanks.

 - Alistair

> Cheers,
> Miguel