Re: [PATCH 0/4] rust: add pointer projection infrastructure and convert DMA

["Danilo Krummrich" <dakr@kernel.org>]

On Sun Feb 15, 2026 at 4:16 PM CET, Miguel Ojeda wrote:
> On Sun, Feb 15, 2026 at 1:56 PM Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> see it land within three weeks or so
>
> That sounds fine -- as I mentioned, what I don't want is that we land
> patches like this one (i.e. soundness fixes that require a new
> feature) with the urgency of usual fixes, but rather more on the side
> of that of a new feature, since they contain one.

The fact that you keep repeating this and that you said in your fist reply "I
would prefer we at least have a reasonable review time for this." confuses me a
bit, since repeating it and saying "at least" reads to me as if I would have
ever said something different, when I noted:

	If you don't mind I would like to take this one through the driver-core
	tree as well, as it is not only the base for this fix, but also the base
	for the upcoming I/O infrastructure work.

I did not mean to create any impression of urgency, but only wanted to know
whether that's fine with you in general, e.g. "Yep, will ACK it once I feel it's
ready.".

So, again to avoid any possible misunderstanding, we never were in disagreement.

> (It is not so much about this patch in particular, it is more about
> trying to establish a pattern.)

Not sure there is a new pattern to be established, it's always a judgement call
how to handle those things. As I already said, I don't think that soundness
holes that do not lead to an actual bug yet are any different to other cases of
potential bugs, regardless of C or Rust.

For instance, if you have an API on the C side that is supposed to be safe
against concurrency, which is buggy, but the only user does not use it in a
concurrent way, that's the exact same situation I think.

Hence, I do apply the same general handling and judgement.

>> If there is a potential bug (i.e. code that is broken, but no user experiences
>> it so far) then I usually take the fix through a -fixes PR but don't flag it for
>> backporting.
>
> That sounds fine -- my only note is that we do our best to backport
> Rust soundness fixes (i.e. unless there is a reason not to, e.g. it
> could be that it is just way too much effort and the risk of getting
> actually abused is low).
>
> I have just added this section -- we may also want to add it
> elsewhere, e.g. the guidelines, for more visibility:
>
>   https://rust-for-linux.com/contributing#soundness-issues-and-backporting
>
> In general, if code is actually broken, even if a user didn't report
> an issue yet, the stable team also takes them (going by the things
> they usually pick). But I assume you meant it more in an abstract
> sense of broken ("conceptually broken", "theoretical issues"), like
> Rust soundness bugs, yeah.

(Yes, this is what I meant.)

> So Rust soundness bugs are exceptional in that sense, i.e. we nevertheless
> backport them even if "theoretical".

I'm a bit confused by this paragraph. In your last message you raised the
following concern.

	"But it is all a balance, i.e. in the C side, it wouldn't be even
	considered a bug to begin with, unless there was an "actual issue", and
	thus unlikely to be justified for a fixes PR. So I want to make sure we
	don't overdo it on the Rust side."

But now, additional to my usual handling I described, you seem to ask for a
backport in such cases, as your link mentions "In general, fixes for Rust
soundness issues should be marked for backport, unless there is a reason not
to.".

Can you please clarify?

Besides that, as I mentioned above, I don't really see a reason to handle this
different than any other "potential bug", such as the C example I gave above.