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: <CANiq72nBDEOSuSNTGKGA5xQrs3ZFH87ii0OAdhJq3rqtOv=dfQ@mail.gmail.com>
Date: Fri, 14 Feb 2025 19:04:46 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 
	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

On Fri, Feb 14, 2025 at 5:10 PM Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
>
> 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.

Like an equivalent to the `mm-unstable` one? Would patches only be
promoted if they pass the Rust build etc.?

(Sorry, I don't mind to interfere -- just trying to understand how it
would work, since I may be able to use as an example later on for
other subsystems etc.)

> 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?

If you mean on the Rust side, I just wrote some context on another thread:

    https://lore.kernel.org/rust-for-linux/CANiq72=Yy8e=pGA+bUHPZhn+D66TmU3kLSjAXCSQzgseSYnDxQ@mail.gmail.com/

The important bit is:

    I regularly test different combinations (branches, configs, compiler
    versions, and so on) to catch mainly toolchain issues and so on, and
    keep things as clean as I can. Others use regularly the Rust support
    for their different use cases, thus more testing happens on different
    environments. In other words, things generally work just fine.

    However, our testing is not meant to catch every issue everywhere.
    Like for anything else in the kernel, whoever maintains a branch with
    a particular Rust feature needs to set up proper testing for that
    particular feature and relevant configs.

I hope that clarifies.

Moreover, there are some bots available that support Rust, e.g.
Intel's 0-day bot. I am happy to put you in contact with them to see
what they can do for your branches.

Cheers,
Miguel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ