Re: [PATCH] vfio/type1: Retry follow_pfnmap_start() when PFNMAP is zapped

[David Hildenbrand (Arm)]

On 3/19/26 15:30, Alex Williamson wrote:
> On Thu, 19 Mar 2026 14:18:49 +0100
> "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:
> 
>> On 3/19/26 09:36, Boone, Max wrote:
>>>
>>>   
>>>
>>> I’d say that the best case would be to have follow_pfnmap_start() return
>>> -EINVAL or -ENOENT w.r.t. which of the two return values it is. But then
>>> again, we could theoretically run into an infinite loop I guess - as the zap
>>> and faulting could run in lockstep (the race window is extremely small
>>> though).  
>>
>> Well, in theory :) To hit that race repeatedly, you'd really have to be
>> quite lucky I guess.
>>
>> But the real question is: if user space triggered the pinning, and user
>> space keeps hurting itself to make progress, is that a real problem?
> 
> I'd say no, that's not a problem.  It's really just that masking all
> non-zero returns as -EAGAIN makes some assumptions about the other
> error conditions that could change over time, so minimally those
> dependencies should be clearly stated.  Even better would be if we
> didn't need to make those assumptions. 

I agree that follow_pfnmap_start() should be improved, to return -EINVAL
on invalid parameters and -ENOENT on "no present entry"."

And -ENOENT should be documented to be resolvable by triggering a fault.

Looking at it, the retry label in the function also seems avoidable, and
some other checks might be shaky ...

Let me briefly see if I can rework that.

-- 
Cheers,

David