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

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

On Sun Feb 15, 2026 at 1:06 PM CET, Miguel Ojeda wrote:
> On Sun, Feb 15, 2026 at 12:06 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> I just want to have a reasonable review time for the first patch since
> it is new code.

That's a bit vague as this may mean something else to different people and may
even depend on the actual patch and the people involed. I.e. we may have a
different understandng of what is reasonable in this case. :)

For instance, for the scope of this specific patch, given that it was sent by
Gary and already had a review pass from Benno I would not have any concerns to
see it land within three weeks or so (assuming that it will also receive
positive feedback from Alice).

But of course it depends and as a maintainer I also constantly re-evaluate when
a patch is considered ready.

To me time is a less important measure; a more important measure for me is
whether the key stakeholders are in agreement that things go in the right
direction.

Having that said, it is perfectly fine not to rely on the judgement of another
maintainer is this case. It is of course your decision if and *when* you provide
the ACK for this to go through another tree. :)

> That is why I asked whether there is UB "actually" happening today,
> because I wanted to understand how urgent we were talking about.

Ah, I thought you already know that there is no rush, as this topic was also
raised by Gary in the last R4L call.

>> I do not see any reason for this to be backported, but it is reasonable to be
>> included in a -fixes PR.
>
> The backporting part was to mention that you were right that we treat
> soundness issues as bugs -- even to the point of backporting. I
> introduced that policy to try to raise the bar compared to C, since we
> want that "extra layer" of protection and to keep it up even in stable
> kernels.
>
> 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.

Independent of the above, this is how I see it (and treat it so far) for both C
and Rust code:

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.

The reason I say usually is because it is a judgement call in the end, as it
also highly depends on where we are in the cycle.

For instance, if it is early in the cycle and the fix is considered low risk, I
rather take it (e.g. before another subsequent fix regresses due to the
potential bug). But if it is late in the cycle, even for a low risk fix, I
rather hold it back.

To me a soundness bug (that is not yet "abused") falls into this category and
receives the same handling.