Re: [PATCH] nvme: reject completions for requests that are not in flight

[Mauricio Faria de Oliveira <mfo@igalia.com>]

On 2026-11-04 17:11, Keith Busch wrote:
> On Wed, Nov 04, 2026 at 04:46:12PM -0300, Mauricio Faria de Oliveira wrote:
>> On 2026-11-03 17:06, Keith Busch wrote:
>> > On Tue, Nov 03, 2026 at 04:54:27PM -0300, Mauricio Faria de Oliveira wrote:
>> >> For the former question, I'd imagine other block drivers might be
>> >> subject to a similar issue, under incorrect completions, and can take a
>> >> look at this later. I'd appreciate feedback on the points above before
>> >> trying to address it generically in the block layer, if at all possible.
>> > 
>> > Here's my real concern: the proposal is a race. Another CPU can change
>> > the request state to in-flight, and this code will declare it complete
>> > before the hardware even saw it. It's a silent data corruption problem
>> > that we can't fix because it is impossible to tell the difference
>> > between a bogus and a legit completion at that point. This kind of
>> > hardware shouldn't be allowed to exist as it can't be used successfully
>> > when it behaves this way.
>> 
>> Could you please clarify? Not that I'm defending the patch; just so I
>> understand your point.
>> 
>> The reason I ask is, IIUIC, if another CPU changes the request state to
>> in-flight and wins the race over an incorrect completion that maps to
>> that request, the request is declared complete anyway, even without this
>> code, no?
> 
> Yes, the race I'm mentioning is pre-existing assuming we're dealing with
> this kind of protocol breaking hardware. It just can't be fixed on the
> kernel side, and the proposal trying to cater to it makes it painfully
> obvious. I'd rather crash the kernel than risk passing on corrupted data
> as a success.

Indeed, under risk, crashing sounds better. Thanks for clarifying.

-- 
Mauricio