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: <2iypqaa3orklplwec4k5n4nuuov3gajtkiv2nt2ce2s2b4e7gd@7y6cmwrwr5te>
Date: Fri, 14 Feb 2025 11:09:55 -0500
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Alice Ryhl <aliceryhl@...gle.com>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Miguel Ojeda <ojeda@...nel.org>, Matthew Wilcox <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>, John Hubbard <jhubbard@...dia.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>, Jann Horn <jannh@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        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>,
        Benno Lossin <benno.lossin@...ton.me>,
        Andreas Hindborg <a.hindborg@...nel.org>,
        Trevor Gross <tmgross@...ch.edu>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, rust-for-linux@...r.kernel.org,
        Balbir Singh <balbirs@...dia.com>
Subject: Re: [PATCH v14 0/8] Rust support for mm_struct, vm_area_struct, and
 mmap

* Lorenzo Stoakes <lorenzo.stoakes@...cle.com> [250214 07:20]:
> On Fri, Feb 14, 2025 at 12:56:29PM +0100, Alice Ryhl wrote:
> > On Thu, Feb 13, 2025 at 8:46 PM Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
> > >
> > > * Lorenzo Stoakes <lorenzo.stoakes@...cle.com> [250213 07:16]:
> > > > On Thu, Feb 13, 2025 at 01:03:04PM +0100, Miguel Ojeda wrote:
> > > > > On Thu, Feb 13, 2025 at 12:50 PM Lorenzo Stoakes
> > > > > <lorenzo.stoakes@...cle.com> wrote:
> > > > > >
> > > > > > Right, I don't mean the rust subsystem, I mean designated rust
> > > > > > maintainers. The point being that this won't add workload to Andrew, nor
> > > > > > require him nor other mm C people to understand rust.
> > > > >
> > > > > Sounds good, and apologies for being pedantic, but given the recent
> > > > > discussions, I thought I should clarify just in case others read it
> > > > > differently.
> > > > >
> > > > > In the same vein, one more quick thing (that you probably didn't mean
> > > > > in this way, but still, I think it is better I add the note, sorry): I
> > > > > don't think it is true that it will not add workload to Andrew or MM
> > > > > in general. It always adds some workload, even if the maintainers
> > > > > don't handle the patches at all, since they may still need to perform
> > > > > a small change in something Rust related due to another change they
> > > > > need to do, or perhaps at least contact the Rust sub-maintainer to do
> > > > > it for them, etc.
> > > > >
> > > > >     https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers
> > > > >
> > > > > Cheers,
> > > > > Miguel
> > > >
> > > > Ack, for the record I'm happy to help with any work that might come up.
> > >
> > > Ack, here too.
> > >
> > > Without the drama, I'm not sure how we'd feel so alive :P
> > >
> > > Can I be added to whatever list so I can be Cc'ed on the changes on your
> > > side?
> >
> > I'm happy to format the entries whichever way you all prefer, but for
> > example it could be a new MAINTAINERS entry below MEMORY MAPPING along
> > these lines:
> >
> > MEMORY MANAGEMENT/MAPPING [RUST]
> 
> I think a general:
> 
> MEMORY MANAGEMENT [RUST]
> 
> works better here as it ought to (at least for the time being) cover off all
> rust mm stuff.
> 
> > M: Alice Ryhl <aliceryhl@...gle.com>
> 
> I wonder if we should have Andrew as a co-maintainer here so people also
> send to Andrew also for merge? (and obviously as the mm maintainer he may
> have commentary).

Indeed, FWIU each subsystem is doing something different with some
taking no responsibility/effort while others are involved.

The mm space has been a very good citizen in both methods (merging with
cover letters, code quality, etc) and in code (always on top of syzbot,
bugs).  I think it is important to strive to keep this functioning.

This will become more important once we have more than just wrappers,
but I think we should talk about what this will need to look like before
it actually happens.  ie: unstable rust branch tracking unstable c
branch with build emails, etc?  Early days yet, though.

> 
> > R: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> 
> Am happy to be a reviewer this is fine!
> 
> > R: Liam R. Howlett <Liam.Howlett@...cle.com>
> 
> I am sure Liam is also, but of course he can comment himself :)

Yes, please add me here.

> 
> > L: linux-mm@...ck.org
> > L: rust-for-linux@...r.kernel.org
> > S: Maintained
> 
> Probably need these here too if Andrew is taking in his tree:
> 
> W:	http://www.linux-mm.org
> T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

This is a good question.

I am unclear how the branching/merging happens.  When do we need to
start (at lest) building the rust side?  We've been doing a lot of work
in the modularization/interface level to try and integrate more isolated
testing, as well as the locking changes.

Do you have build bots that will tell us when things are broken?

...

Thanks,
Liam

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ