* David Hildenbrand <david@xxxxxxxxxx> [240723 06:12]: > 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. > Ah, that's what I was missing. Might be worth adding to the change log. Thanks, Liam
