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] [day] [month] [year] [list]

Message-ID: <20250130172437.GN5556@nvidia.com>
Date: Thu, 30 Jan 2025 13:24:37 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Greg KH <gregkh@...uxfoundation.org>
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 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'm also not sure about moved on, Uros's previously accepted patches
are still unmerged:

Uros Bizjak (6):
      x86/kgdb: use IS_ERR_PCPU() macro
      compiler.h: introduce TYPEOF_UNQUAL() macro
      percpu: use TYPEOF_UNQUAL() in variable declarations
      percpu: use TYPEOF_UNQUAL() in *_cpu_ptr() accessors
      percpu: repurpose __percpu tag as a named address space qualifier
      percpu/x86: enable strict percpu checks via named AS qualifiers

Uros has now respun a v4 without a CONFIG_CC_HAS_TYPEOF_UNQUAL that
triggered the rust issue. The underlying Rust issue of mismatched
compilers messing up kconfig probes looks to still be open.

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

My reading of this paragraph makes me think you expect Linus to have
merged Andrew's PR and left the rust build broken so that the rust
maintainer/developers could fix it later?

Jason