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

Jason Gunthorpe
2025-01-30T17:24:42Z

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