linux-kernel - Re: [PATCH v2 2/3] rust: configfs: introduce rust support for configfs

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]

Message-ID: <87eczvhch6.fsf@kernel.org>
Date: Tue, 18 Feb 2025 09:40:53 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Benno Lossin" <benno.lossin@...ton.me>
Cc: "Danilo Krummrich" <dakr@...nel.org>,  "Miguel Ojeda"
 <ojeda@...nel.org>,  "Alex Gaynor" <alex.gaynor@...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>,  "Trevor
 Gross" <tmgross@...ch.edu>,  "Joel Becker" <jlbec@...lplan.org>,
  "Christoph Hellwig" <hch@....de>,  "Peter Zijlstra"
 <peterz@...radead.org>,  "Ingo Molnar" <mingo@...hat.com>,  "Will Deacon"
 <will@...nel.org>,  "Waiman Long" <longman@...hat.com>,  "Fiona Behrens"
 <me@...enk.dev>,  "Charalampos Mitrodimas" <charmitro@...teo.net>,
  <rust-for-linux@...r.kernel.org>,  <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/3] rust: configfs: introduce rust support for configfs

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

> On 17.02.25 13:20, Andreas Hindborg wrote:
>> "Benno Lossin" <benno.lossin@...ton.me> writes:
>>> On 17.02.25 12:08, Andreas Hindborg wrote:
>>>>>> +
>>>>>> +/// A `configfs` subsystem.
>>>>>> +///
>>>>>> +/// This is the top level entrypoint for a `configfs` hierarchy. To register
>>>>>> +/// with configfs, embed a field of this type into your kernel module struct.
>>>>>> +#[pin_data(PinnedDrop)]
>>>>>> +pub struct Subsystem<Data> {
>>>>>
>>>>> Usually, we don't have multi-character generics, any specific reason
>>>>> that you chose `Data` here over `T` or `D`?
>>>>
>>>> Yes, I find it more descriptive. The patch set went through quite a bit
>>>> of evolution, and the generics got a bit complicated in earlier
>>>> iterations, which necessitated more descriptive generic type parameter
>>>> names. It's not so bad in this version after I restricted the pointer
>>>> type to just `Arc`, but I still think that using a word rather a single
>>>> letter makes the code easier to comprehend at first pass.
>>>
>>> Makes sense. I'm not opposed to it, but I am a bit cautious, because one
>>> disadvantage with using multi-character names for generics is that one
>>> cannot easily see if a type is a generic or not. Maybe that is not as
>>> important as I think it could be, but to me it seems useful.
>>
>> If you use an editor with semantic highlighting, you can style the
>> generic identifiers. I am currently trying out Helix, and that is
>> unfortunately on of the features it is missing. Can't have it all I
>> guess.
>
> That is true, but there are a lot of places where Rust code is put that
> aren't my editor (git diffs/commit messages, mails, lore.kernel.org,
> github) and there it'll become more difficult to read (also people might
> not have their editor configured to highlight them).
>
> So I think we should at least consider it more.

There is a trade-off to be made for sure.

>
>>>>>> +                    // SAFETY: We are expanding `configfs_attrs`.
>>>>>> +                    static [< $data:upper _ $name:upper _ATTR >]:
>>>>>> +                      $crate::configfs::Attribute<$attr, $data, $data> =
>>>>>> +                        unsafe {
>>>>>> +                            $crate::configfs::Attribute::new(c_str!(::core::stringify!($name)))
>>>>>> +                        };
>>>>>> +                }
>>>>>> +            )*
>>>>>> +
>>>>>> +
>>>>>> +            const N: usize = $cnt + 1usize;
>>>>>
>>>>> Why do we need an additional copy? To have a zero entry at the end for C
>>>>> to know it's the end of the list? If so, a comment here would be very
>>>>> helpful.
>>>>
>>>> Yes, we need space for a null terminator. I'll add a comment.
>>>>
>>>> We actually have a static check to make sure that we not missing this.
>>>
>>> Where is this static check?
>>
>> In `Attribute::add`:
>>
>>         if I >= N - 1 {
>>             kernel::build_error!("Invalid attribute index");
>>         }
>
> Ahh I see, would be also nice to have a comment there explaining why the
> check is `>= N - 1`.

I'll add a comment 👍


Best regards,
Andreas Hindborg