linux-kernel - Re: [RFC PATCH 4/5] rust: block: add rnull, Rust null

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] [thread-next>] [day] [month] [year] [list]

Date: Wed, 03 Apr 2024 11:47:18 +0200
From: Andreas Hindborg <nmi@...aspace.dk>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Jens Axboe <axboe@...nel.dk>,  Christoph Hellwig <hch@....de>,  Keith
 Busch <kbusch@...nel.org>,  Damien Le Moal <Damien.LeMoal@....com>,  Bart
 Van Assche <bvanassche@....org>,  Hannes Reinecke <hare@...e.de>,
  "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,  Andreas
 Hindborg <a.hindborg@...sung.com>,  Niklas Cassel <Niklas.Cassel@....com>,
  Greg KH <gregkh@...uxfoundation.org>,  Matthew Wilcox
 <willy@...radead.org>,  Miguel Ojeda <ojeda@...nel.org>,  Alex Gaynor
 <alex.gaynor@...il.com>,  Wedson Almeida Filho <wedsonaf@...il.com>,
  Boqun Feng <boqun.feng@...il.com>,  Gary Guo <gary@...yguo.net>,
  Björn
 Roy Baron <bjorn3_gh@...tonmail.com>,  Alice Ryhl <aliceryhl@...gle.com>,
  Chaitanya Kulkarni <chaitanyak@...dia.com>,  Luis Chamberlain
 <mcgrof@...nel.org>,  Yexuan Yang <1182282462@...t.edu.cn>,  Sergio
 González Collado <sergio.collado@...il.com>,  Joel
 Granados
 <j.granados@...sung.com>,  "Pankaj Raghav (Samsung)"
 <kernel@...kajraghav.com>,  Daniel Gomez <da.gomez@...sung.com>,  open
 list <linux-kernel@...r.kernel.org>,  "rust-for-linux@...r.kernel.org"
 <rust-for-linux@...r.kernel.org>,  "lsf-pc@...ts.linux-foundation.org"
 <lsf-pc@...ts.linux-foundation.org>,  "gost.dev@...sung.com"
 <gost.dev@...sung.com>
Subject: Re: [RFC PATCH 4/5] rust: block: add rnull, Rust null_blk
 implementation

Benno Lossin <benno.lossin@...ton.me> writes:

[...]

>
>
> So I did some digging and there are multiple things at play. I am going
> to explain the second error first, since that one might be a problem
> with `pin_init`:
> - the `params` extension of the `module!` macro creates constants with
>    snake case names.
> - your `QueueData` struct has the same name as a field.
> - `pin_init!` generates `let $field_name = ...` statements for each
>    field you initialize
>
> Now when you define a constant in Rust, you are able to pattern-match
> with that constant, eg:
>
>      const FOO: u8 = 0;
>      
>      fn main() {
>          match 10 {
>              FOO => println!("foo"),
>              _ => {}
>          }
>      }
>
> So when you do `let FOO = x;`, then it interprets `FOO` as the constant.
> This is still true if the constant has a snake case name.
> Since the expression in the `pin_init!` macro has type
> `DropGuard<$field_type>`, we get the error "expected
> `DropGuard<IRQMode>`, found `__rnull_mod_irq_mode`".

Thanks for the analysis!

So in this expanded code:

1   {
2       unsafe { ::core::ptr::write(&raw mut ((*slot).irq_mode), irq_mode) };
3   }
4   let irq_mode = unsafe {
5       $crate::init::__internal::DropGuard::new(&raw mut ((*slot).irq_mode))
6   };

the `irq_mode` on line 2 will refer to the correct thing, but the one on
line 6 will be a pattern match against a constant? That is really
surprising to me. Can we make the let binding in line 6 be `let
irq_mode_pin_init` or something similar?

>
> Now to the first error, this is a problem with the parameter handling of
> `module`. By the same argument above, your let binding in line 104:
>
>      let irq_mode = (*irq_mode.read()).try_into()?;
>
> Tries to pattern-match the `irq_mode` constant with the right
> expression. Since you use the `try_into` function, it tries to search
> for a `TryInto` implementation for the type of `irq_mode` which is
> generated by the `module!` macro. The type is named
> __rnull_mod_irq_mode.
>
>
> Now what to do about this. For the second error (the one related to
> `pin_init`), I could create a patch that fixes it by adding the suffix
> `_guard` to those let bindings, preventing the issue. Not sure if we
> need that though, since it will not get rid of the first issue.

I think that is a good idea 👍

>
> For the first issue, I think there is no other way than to use a
> different name for either the field or the constant. Since constants are
> usually named using screaming snake case, I think it should be renamed.
> I believe your reason for using a snake case name is that these names
> are used directly as the names for the parameters when loading the
> module and there the convention is to use snake case, right?
> In that case I think we could expect people to write the screaming snake
> case name in rust and have it automatically be lower-cased by the
> `module!` macro when it creates the names that the parameters are shown
> with.

I was thinking about putting the parameters in a separate name space,
but making them screaming snake case is also a good idea. So it would
be `module_parameters::IRQ_MODE` to access the parameter with the name
`irq_mode` exposed towards the user. Developers can always opt in to bringing
the symbols into scope with a `use`.

Best regards,
Andreas