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: <2025013030-gummy-cosmic-7927@gregkh>
Date: Thu, 30 Jan 2025 17:11:43 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: phasta@...nel.org, Christoph Hellwig <hch@....de>,
	Danilo Krummrich <dakr@...nel.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Abdiel Janulgue <abdiel.janulgue@...il.com>,
	daniel.almeida@...labora.com, aliceryhl@...gle.com,
	robin.murphy@....com, rust-for-linux@...r.kernel.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>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>,
	Valentin Obst <kernel@...entinobst.de>,
	open list <linux-kernel@...r.kernel.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>, airlied@...hat.com,
	"open list:DMA MAPPING HELPERS" <iommu@...ts.linux.dev>
Subject: Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.

On Thu, Jan 30, 2025 at 11:46:46AM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 30, 2025 at 02:19:16PM +0100, Philipp Stanner wrote:
> > would some sort of official statement by the "entire community"
> > reassure you that the burden of keeping Rust abstractions working with
> > any changes on the C side rests entirely on the Rust side's
> > shoulders?
> 
> You'd have to reconcile that with the recent event where Linus defered
> the MM pull request and some C patches were dropped because of rust
> kbuild bugs:
> 
> https://lore.kernel.org/linux-mm/CAHk-=whddBhfi5DUi370W3pYs+z3r2E7KYuHjwR=a1eRig5Gxg@mail.gmail.com/
> 
> It seems to me the message is now crystal clear, and the opposite of
> what you claim.
> 
> All PRs to Linus must not break the rust build and the responsibilty
> for that falls to all the maintainers. If the Rust team is not quick
> enough to resolve any issues during the development window then
> patches must be dropped before sending PRs, or Linus will refuse the
> PR.
> 
> Effectively this seems to imply that patches changing some of the C
> API cannot be merged by maintainers unless accompanied by matching
> Rust hunks.
> 
> If there are different instructions to maintainers I would be
> interested to know.

That's not the case, the one you point at above was a tooling issue that
people missed due to the holidays.  Fixing it up was simple enough and
people did so and moved on.

Once a core api changes in a tree and it hits linux-next and that blows
up a rust build, obviously people should notice it then and the rust
maintainers/developers have said they will fix it up.

So the claim remains the same here.  It's just like staging, api changes
to subsystems are allowed to break staging, and rust code, and
maintainers do NOT have to fix them up there, that's up to the staging
and rust maintainers/developers to do so.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ