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