linux-kernel - Re: [PATCH RFC 02/20] rust_binder: add binderfs support to Rust binder

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: <ZUUvI0leuPfhCOfE@boqun-archlinux>
Date:   Fri, 3 Nov 2023 10:34:27 -0700
From:   Boqun Feng <boqun.feng@...il.com>
To:     Benno Lossin <benno.lossin@...ton.me>
Cc:     Alice Ryhl <aliceryhl@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arve Hjønnevåg <arve@...roid.com>,
        Todd Kjos <tkjos@...roid.com>,
        Martijn Coenen <maco@...roid.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Christian Brauner <brauner@...nel.org>,
        Carlos Llamas <cmllamas@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Miguel Ojeda <ojeda@...nel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...il.com>,
        linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
        Gary Guo <gary@...yguo.net>,
        Björn Roy Baron <bjorn3_gh@...tonmail.com>,
        Andreas Hindborg <a.hindborg@...sung.com>,
        Matt Gilbride <mattgilbride@...gle.com>,
        Jeffrey Vander Stoep <jeffv@...gle.com>,
        Matthew Maurer <mmaurer@...gle.com>
Subject: Re: [PATCH RFC 02/20] rust_binder: add binderfs support to Rust
 binder

On Fri, Nov 03, 2023 at 04:30:54PM +0000, Benno Lossin wrote:
> On 01.11.23 19:01, Alice Ryhl wrote:
> > +/// There is one context per binder file (/dev/binder, /dev/hwbinder, etc)
> > +#[pin_data]
> > +pub(crate) struct Context {
> > +    #[pin]
> > +    manager: Mutex<Manager>,
> > +    pub(crate) name: CString,
> > +    #[pin]
> > +    links: ListLinks,
> > +}
> > +
> > +kernel::list::impl_has_list_links! {
> > +    impl HasListLinks<0> for Context { self.links }
> > +}
> > +kernel::list::impl_list_arc_safe! {
> > +    impl ListArcSafe<0> for Context { untracked; }
> > +}
> > +kernel::list::impl_list_item! {
> > +    impl ListItem<0> for Context {
> > +        using ListLinks;
> > +    }
> > +}
> 
> I think at some point it would be worth introducing a derive macro that
> does this for us. So for example:

Agreed.

> 
>     #[pin_data]
>     #[derive(HasListLinks)]
>     pub(crate) struct Context {
>         #[pin]
>         manager: Mutex<Manager>,
>         pub(crate) name: CString,
>         #[pin]
>         #[links]
>         links: ListLinks,
>     }
> 
> And if you need multiple links you could do:
> 
>     #[pin_data]
>     #[derive(HasListLinks)]
>     struct Foo {
>         #[links = 0]
>         a_list: ListLinks,

we will need more discussion on how the derive syntax would look like,
but I'd expect we can reference the field with names instead of numbers
if we use derive macros. In other words type numbering to distinguish
different fields should be an implementation detail.

Regards,
Boqun

>         #[links = 1]
>         b_list: ListLinks,
>     }
> 
> Same for `ListItem` and `HasWork`. I have not yet taken a look at your
> linked list implementation, so I don't know if this is possible (since
> `ListItem` seems to have multiple "backends").
> 
> I think this improvement can wait though, just wanted to mention it.
> 
> -- 
> Cheers,
> Benno
>