linux-kernel - Re: [PATCH v9 12/27] rust: add `kernel` crate

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yyr5pKpjib/yqk5e@kroah.com>
Date:   Wed, 21 Sep 2022 13:46:44 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Konstantin Shelekhin <k.shelekhin@...ro.com>
Cc:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, ojeda@...nel.org,
        alex.gaynor@...il.com, ark.email@...il.com,
        bjorn3_gh@...tonmail.com, bobo1239@....de, bonifaido@...il.com,
        boqun.feng@...il.com, davidgow@...gle.com, dev@...lasmohrin.de,
        dsosnowski@...snowski.pl, foxhlchen@...il.com, gary@...yguo.net,
        geofft@...reload.com, jarkko@...nel.org, john.m.baublitz@...il.com,
        leseulartichaut@...il.com, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, m.falkowski@...sung.com,
        me@...enk.de, milan@...verde.com, mjmouse9999@...il.com,
        patches@...ts.linux.dev, rust-for-linux@...r.kernel.org,
        thesven73@...il.com, torvalds@...ux-foundation.org,
        viktor@...ar.de, wedsonaf@...gle.com,
        Andreas Hindborg <andreas.hindborg@....com>
Subject: Re: [PATCH v9 12/27] rust: add `kernel` crate

On Wed, Sep 21, 2022 at 02:23:42PM +0300, Konstantin Shelekhin wrote:
> On Sat, Aug 06, 2022 at 01:22:52PM +0200, Miguel Ojeda wrote:
> > On Sat, Aug 6, 2022 at 12:25 PM Konstantin Shelekhin
> > <k.shelekhin@...ro.com> wrote:
> > >
> > > I sense possible problems here. It's common for a kernel code to pass
> > > flags during memory allocations.
> > 
> > Yes, of course. We will support this, but how exactly it will look
> > like, to what extent upstream Rust's `alloc` could support our use
> > cases, etc. has been on discussion for a long time.
> > 
> > For instance, see https://github.com/Rust-for-Linux/linux/pull/815 for
> > a potential extension trait approach with no allocator carried on the
> > type that Andreas wrote after a discussion in the last informal call:
> > 
> >     let a = Box::try_new_atomic(101)?;
> 
> In my opinion, the rest of the thread clearly shows that the
> conservative approach is currently the only solid option. I suggest the
> following explicit API:
> 
>   let a = Box::try_new(size, flags)?;
>   Vec::try_push(item, flags)?;
> 
> etc. Whadda you think?

Please, yes.  This fits the current kernel memory allocation pattern and
allows for proper propagation of the allocation flags as needed through
the system.  This is going to be required in any non-trivial kernel code
anyway, might as well do it correct from the beginning.

It also allows for flags to change over time, which also happens.

thanks,

greg k-h