Re: [PATCH] fs/proc/task_mmu: fix missed VMAs when reading /proc/PID/maps and friends

[David Hildenbrand (Arm)]

On 10/25/26 20:01, Jose A. Perez de Azpillaga wrote:
> On 10/25/26 11:43 AM, David Hildenbrand (Arm) wrote:
> [snip]
> 
>> Fixes: 5631da56c9a8 ("fs/proc/task_mmu: read proc/pid/maps under per-vma lock")
>> Fixes: ea3085dd7a4e ("fs/proc/task_mmu: read proc/pid/{smaps|numa_maps} under per-vma lock")
>> Fixes: 0e985559d72a ("proc/task_mmu: read proc/pid/smaps_rollup under per-vma lock")

> 
> PROCMAP_QUERY does the same fresh lookup, shouldn't d9d1c2d81797
> ("fs/proc/task_mmu: execute PROCMAP_QUERY ioctl under per-vma locks") be
> here as well? (commit tracked down by an LLM)

Hm, very likely I missed that. So yeah, let's just add it. I assume it won't
matter much because 5631da56c9a8 is the oldest one either way.

> 
> [snip]
> 
>> There is the issue with seqcount overflows that Lorenzo is tackling. It
>> probably interacts here as well? Likely, but that's an independent issue
>> to resolve.
> 
> the saved seq is reset on every m_start() and query, so a wrap would
> need 2^31 write locks inside one read() or ioctl, I don't think it
> matters in practice :)
> 
> I tested it on x86_64 in qemu with KASAN, lockdep and DEBUG_VM on top of
> mm-unstable, the maps holes I hit there are gone. Also, the code LGTM:
> 
> Reviewed-by: Jose A. Perez de Azpillaga <azpijr@xxxxxxxxx>
> Tested-by: Jose A. Perez de Azpillaga <azpijr@xxxxxxxxx>
> 

Thanks for the review!

-- 
Cheers,

David