On 22.07.24 23:17, Peter Xu wrote:
On Mon, Jul 22, 2024 at 04:22:45PM -0400, Liam R. Howlett wrote:
The problem report from [2] and [3] is that we are getting to a call
path that includes unmap_single_vma() without the mmap lock. This patch
fails to address that issue, it only takes the caller with the assert
out of the call path.
Removing the function with the lock check doesn't fix the locking issue.
If there is no locking issue here, please state the case in the commit
log as you feel it is safe to use a vma pointer without the mmap_lock
held.
Could you please state why there's a locking issue, and why this patch (of
a x86 PAT specific issue...) would need any documentation on that?
I thought it was pretty common that file truncation (or anything similar)
does a file rmap walk over vmas that mapping this file, and vmas need to be
alive during the rmap walk, no?
Right, I was also assuming that the rmap locking (from where we obtained
that VMA -- rmap interval tree) makes sure that using the VMA is safe.
--
Cheers,
David / dhildenb
