Re: [PATCH v3] block: assign caller-specific lockdep class to disk->open_mutex

[Mark Brown]

On Fri, Jun 05, 2026 at 02:40:24PM +0200, Miguel Ojeda wrote:

Copying in Kees and Gustavo due to a rust/randstruct interaction in
-next.

> I Cc'd you since I was wondering if your new `LLVM=1` build should
> have caught it (I thought the GCC one wouldn't, since my understanding
> is that we lost that last week due to the KASAN+RUST patch).

Yes, you did loose it so I swapped to LLVM=1 in order to try to keep
coverage.  I didn't specifically verify that it worked though, I only
noticed that change as I'd been enabling rust for KUnit and that flags
any missing Kconfig symbol.

> And, yeah, it is fragile... It is quite a complicated set of Kconfig
> relationships, so years ago I also ended up in the same situation and
> early on decided to add an explicit grep for `CONFIG_RUST=y` and
> certain other bits that I wanted to ensure are in place after the
> config phase.

It looks like the breakage is due to 'depends on !RANDSTRUCT' because
clang supports randstruct and allmodconfig defaults that to
RANDSTRUCT_FULL.  The fact that rust depends on !RANDSTRUCT but
randstruct doesn't care about rust means that randstruct wins.  I've got
to say rust coverage seems more important than randstruct coverage for
-next, others might have different opinions though!

> For you and those building with Rust enabled it would be great to
> notice when it gets disabled by mistake, but I am not sure if most
> maintainers (i.e. those without a Rust toolchain but using
> `all*config` routinely) will appreciate it (or rather, tolerate it...
> :).

I guess there's a difference between !RUST_IS_AVAILABLE and
RUST_IS_AVAILABLE && !RUST which is interesting here.  

I know other people have been caught out by silently not having rust
coverage in their CI.

Attachment: signature.asc
Description: PGP signature