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

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

[Miguel Ojeda]

On Wed, 03 Jun 2026 20:54:05 +0900 Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>
> Acknowledgment:
>   Since I have no experience with Rust, changes needed by Rust block layer
>   bindings and rnull module are made based on conversation with the Gemini
>   AI collaborator.

Then please do Cc the right people as `MAINTAINERS` mentions, including
"BLOCK LAYER DEVICE DRIVER API [RUST]" and "RUST"...

I am quite confused. Why was this added to linux-next?

It doesn't go through block, nor has an Ack or review and breaks
the `rustdoc` build in linux-next (and thus rust.docs.kernel.org):

    error: unresolved link to `my_gendisk_lkclass`
      --> rust/kernel/block/mq/gen_disk.rs:42:50
       |
    42 | /// This type can only be instantiated via the [`my_gendisk_lkclass!`] macro.

It is also not Clippy-clean -- it doesn't follow our usual conventions
for safety comments and sections:

    error: unsafe function's docs are missing a `# Safety` section
      --> rust/kernel/block/mq/gen_disk.rs:59:5
       |
    59 |     pub const unsafe fn new_lock_class(ptr: *mut bindings::gendisk_lkclass) -> GenDiskLockClass {

    error: function has unnecessary safety comment
      --> rust/kernel/block/mq/gen_disk.rs:59:5
       |
    58 |     /// SAFETY: `ptr` must point to a valid static `gendisk_lkclass` instance.
       |         ------- help: consider changing it to a `# Safety` section: `# Safety`
    59 |     pub const unsafe fn new_lock_class(ptr: *mut bindings::gendisk_lkclass) -> GenDiskLockClass {

Please see:

  https://rust-for-linux.com/contributing#submit-checklist-addendum

In any case, it is also too late in the cycle to be experimenting in
linux-next.

So what am I missing? What is going on?

(And on top of all that, for some reason I did not receive it even if I
am apparently in Cc, so I have asked the admins about that.)

Cheers,
Miguel

Cc: Andreas Hindborg <a.hindborg@kernel.org>
Cc: Boqun Feng <boqun@kernel.org>
Cc: rust-for-linux@vger.kernel.org

Cc: Mark Brown <broonie@kernel.org>

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

[Andreas Hindborg]

"Miguel Ojeda" <ojeda@kernel.org> writes:

> On Wed, 03 Jun 2026 20:54:05 +0900 Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>>
>> Acknowledgment:
>>   Since I have no experience with Rust, changes needed by Rust block layer
>>   bindings and rnull module are made based on conversation with the Gemini
>>   AI collaborator.
>
> Then please do Cc the right people as `MAINTAINERS` mentions, including
> "BLOCK LAYER DEVICE DRIVER API [RUST]" and "RUST"...
>
> I am quite confused. Why was this added to linux-next?
>
> It doesn't go through block, nor has an Ack or review and breaks
> the `rustdoc` build in linux-next (and thus rust.docs.kernel.org):
>
>     error: unresolved link to `my_gendisk_lkclass`
>       --> rust/kernel/block/mq/gen_disk.rs:42:50
>        |
>     42 | /// This type can only be instantiated via the [`my_gendisk_lkclass!`] macro.
>
> It is also not Clippy-clean -- it doesn't follow our usual conventions
> for safety comments and sections:
>
>     error: unsafe function's docs are missing a `# Safety` section
>       --> rust/kernel/block/mq/gen_disk.rs:59:5
>        |
>     59 |     pub const unsafe fn new_lock_class(ptr: *mut bindings::gendisk_lkclass) -> GenDiskLockClass {
>
>     error: function has unnecessary safety comment
>       --> rust/kernel/block/mq/gen_disk.rs:59:5
>        |
>     58 |     /// SAFETY: `ptr` must point to a valid static `gendisk_lkclass` instance.
>        |         ------- help: consider changing it to a `# Safety` section: `# Safety`
>     59 |     pub const unsafe fn new_lock_class(ptr: *mut bindings::gendisk_lkclass) -> GenDiskLockClass {
>
> Please see:
>
>   https://rust-for-linux.com/contributing#submit-checklist-addendum
>
> In any case, it is also too late in the cycle to be experimenting in
> linux-next.
>
> So what am I missing? What is going on?
>
> (And on top of all that, for some reason I did not receive it even if I
> am apparently in Cc, so I have asked the admins about that.)
>
> Cheers,
> Miguel
>
> Cc: Andreas Hindborg <a.hindborg@kernel.org>
> Cc: Boqun Feng <boqun@kernel.org>
> Cc: rust-for-linux@vger.kernel.org
>
> Cc: Mark Brown <broonie@kernel.org>

Looks like this was pulled through the tomoyo tree:

tomoyo		git://git.code.sf.net/p/tomoyo/tomoyo.git#master

M:	Kentaro Takeda <takedakn@nttdata.co.jp>
M:	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>


Best regards,
Andreas Hindborg

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

[Tetsuo Handa]

On 2026/06/05 6:07, Miguel Ojeda wrote:
> On Wed, 03 Jun 2026 20:54:05 +0900 Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>>
>> Acknowledgment:
>>   Since I have no experience with Rust, changes needed by Rust block layer
>>   bindings and rnull module are made based on conversation with the Gemini
>>   AI collaborator.
> 
> Then please do Cc the right people as `MAINTAINERS` mentions, including
> "BLOCK LAYER DEVICE DRIVER API [RUST]" and "RUST"...

Oops, it seems that I overlooked the rust-for-linux@vger.kernel.org line.

> 
> I am quite confused. Why was this added to linux-next?

Since sashiko did not find issues on this v3 patch
( https://sashiko.dev/#/patchset/226152a3-1e4c-4eec-9a17-1d40426a7b18%40I-love.SAKURA.ne.jp ),
I started pre-testing by syzbot while waiting for responses from maintainers.

I am using my tree for allowing syzbot to test debug/experimental patches in linux-next tree
(or to apply workaround patches for bugs that prevent syzbot from testing linux-next tree),
and therefore my tree is subjected to "git reset --hard" changes.

> 
> It doesn't go through block, nor has an Ack or review and breaks
> the `rustdoc` build in linux-next (and thus rust.docs.kernel.org):
> 
>     error: unresolved link to `my_gendisk_lkclass`
>       --> rust/kernel/block/mq/gen_disk.rs:42:50
>        |
>     42 | /// This type can only be instantiated via the [`my_gendisk_lkclass!`] macro.
> 
> It is also not Clippy-clean -- it doesn't follow our usual conventions
> for safety comments and sections:
> 
>     error: unsafe function's docs are missing a `# Safety` section
>       --> rust/kernel/block/mq/gen_disk.rs:59:5
>        |
>     59 |     pub const unsafe fn new_lock_class(ptr: *mut bindings::gendisk_lkclass) -> GenDiskLockClass {
> 
>     error: function has unnecessary safety comment
>       --> rust/kernel/block/mq/gen_disk.rs:59:5
>        |
>     58 |     /// SAFETY: `ptr` must point to a valid static `gendisk_lkclass` instance.
>        |         ------- help: consider changing it to a `# Safety` section: `# Safety`
>     59 |     pub const unsafe fn new_lock_class(ptr: *mut bindings::gendisk_lkclass) -> GenDiskLockClass {

Hmm, I'm not familiar with comment styles for Rust...

Do you see any technical problems except comment style problem?

> 
> Please see:
> 
>   https://rust-for-linux.com/contributing#submit-checklist-addendum
> 
> In any case, it is also too late in the cycle to be experimenting in
> linux-next.
> 
> So what am I missing? What is going on?

Nothing bad is going on. The final patch will be sent to linux-next tree via
appropriate tree after getting acks from maintainers, and the current patch
in my tree will be dropped when maintainers accepted the final patch.

> 
> (And on top of all that, for some reason I did not receive it even if I
> am apparently in Cc, so I have asked the admins about that.)

I was enabling only SPF, but it seems that gmail started rejecting such mails.
Therefore, last night I also enabled DKIM/ARC and DMARC. I hope this mail is
delivered to gmail users.

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

[Miguel Ojeda]

On Fri, Jun 5, 2026 at 12:15 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> Oops, it seems that I overlooked the rust-for-linux@vger.kernel.org line.

I am not sure what you mean -- it is not just the mailing list, the
maintainers and the reviewers of both entries were not Cc'd either.

So like 9 Ccs are missing...

> I am using my tree for allowing syzbot to test debug/experimental patches in linux-next tree

linux-next is only meant for patches that are already reviewed, tested
and destined for the merge window.

It is not meant for experimental patches, and adding those, especially
this late in the kernel cycle, can break other people's CIs and
systems at the worst possible time. If every maintainers put random
patches in linux-next, then it would be unusable...

(There are exceptions, of course, but only if people is aware and in
agreement...)

> Do you see any technical problems except comment style problem?

The above errors are already a technical problem -- they break the
Clippy and docs build!

I assume Andreas or Boqun will eventually take a look at the patch now
that they know about its existence (is there a particular reason to
rush?).

> Nothing bad is going on. The final patch will be sent to linux-next tree via
> appropriate tree after getting acks from maintainers, and the current patch
> in my tree will be dropped when maintainers accepted the final patch.

No, please drop it now -- the patch shouldn't have been applied to
linux-next yet, since the maintainers didn't ack it (they just
realized it exists...), it is not reviewed (apart from Sashiko), it is
not tested enough (given the errors above) and not destined for the
next merge window (for all the reasons before).

Thanks!

Cheers,
Miguel

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

On Fri, Jun 05, 2026 at 01:02:59PM +0200, Miguel Ojeda wrote:
> On Fri, Jun 5, 2026 at 12:15 PM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:

> > I am using my tree for allowing syzbot to test debug/experimental patches in linux-next tree

> linux-next is only meant for patches that are already reviewed, tested
> and destined for the merge window.

> It is not meant for experimental patches, and adding those, especially
> this late in the kernel cycle, can break other people's CIs and
> systems at the worst possible time. If every maintainers put random
> patches in linux-next, then it would be unusable...

> (There are exceptions, of course, but only if people is aware and in
> agreement...)

In general the sort of testing that it's good for is "this needs more
exposure" sorts of things - things that look good locally but where
there's a wide variety of users or affected systems that might be
affected and where it's hard to judge the impact.

> > Do you see any technical problems except comment style problem?

> The above errors are already a technical problem -- they break the
> Clippy and docs build!

Oh, bah - something turned off RUST in allmodconfig again so we lost
coverage in -next, sorry about that.  I'll need to work something out to
make sure I notice that happening and can do something about it.  It's
kind of worrying that this keeps happening TBH, otherwise rust conflicts
are likely to result in broken builds.  The dependencies feel really
fraigle here.

> No, please drop it now -- the patch shouldn't have been applied to
> linux-next yet, since the maintainers didn't ack it (they just
> realized it exists...), it is not reviewed (apart from Sashiko), it is
> not tested enough (given the errors above) and not destined for the
> next merge window (for all the reasons before).

Had the rust builds been enabled for allmodconfig as I had expected the
tree would have been kept out of -next as a result of this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Miguel Ojeda]

On Fri, Jun 5, 2026 at 2:04 PM Mark Brown <broonie@kernel.org> wrote:
>
> Oh, bah - something turned off RUST in allmodconfig again so we lost
> coverage in -next, sorry about that.  I'll need to work something out to
> make sure I notice that happening and can do something about it.  It's
> kind of worrying that this keeps happening TBH, otherwise rust conflicts
> are likely to result in broken builds.  The dependencies feel really
> fraigle here.
>
> Had the rust builds been enabled for allmodconfig as I had expected the
> tree would have been kept out of -next as a result of this.

No worries at all, and thanks a lot for testing it, as usual. I am
happy to be there as a backup to catch extra things.

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).

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.

Especially the toolchain side, i.e. the fact that `CONFIG_RUST` gets
automatically disabled if the Rust toolchain is not found, is
particularly subtle. We are considering finally changing that to fail
the build:

  https://lore.kernel.org/rust-for-linux/20260521-evolve-to-crab-v2-1-c18e0e98fc54@chaosmail.tech/

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...
:).

It may be too soon -- I considered announcing it in linux-next and
adding the patch early next cycle to see what happens, but I will
probably take the safer route and ask in LPC first, unless you think
it is a good idea. Any feedback/suggestions appreciated!

Cheers,
Miguel

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Fri, Jun 05, 2026 at 02:03:22PM +0100, Mark Brown wrote:
> On Fri, Jun 05, 2026 at 02:40:24PM +0200, Miguel Ojeda wrote:

> > 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!

I think I've got a fix which isn't too bad, I'll post it later today.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]