linux-kernel - Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.

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: <2025013148-reversal-pessimism-1515@gregkh>
Date: Fri, 31 Jan 2025 08:47:54 +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 01:24:37PM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 30, 2025 at 05:11:43PM +0100, Greg KH wrote:
> > 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.
> 
> Regardless of holidays, you seem to be saying that Linus should have
> accepted Andrew's PR and left rust with build failures?

I can't answer for Linus, sorry.  But a generic "hey, this broke our
working toolchain builds" is something that is much much much different
than "an api changed so I now have to turn off this driver in my build"
issue.

thanks,

greg k-h