On 08/22/2018 02:56 PM, owner-linux-mm@xxxxxxxxx wrote: > > > On 8/22/18 2:42 PM, Dave Hansen wrote: >> On 08/22/2018 02:10 PM, Kirill A. Shutemov wrote: >>>> For x86, mpx_notify_unmap() looks finally zap the VM_MPX vmas in >>>> bound table >>>> range with zap_page_range() and doesn't update vm flags, so it >>>> sounds ok to >>>> me since vmas have been detached, nobody can find those vmas. But, >>>> I'm not >>>> familiar with the details of mpx, maybe Kirill could help to confirm >>>> this? >>> I don't see anything obviously dependent on down_write() in >>> mpx_notify_unmap(), but Dave should know better. >> We need mmap_sem for write in mpx_notify_unmap(). >> >> Its job is to clean up bounds tables, but bounds tables are dynamically >> allocated and destroyed by the kernel. When we destroy a table, we also >> destroy the VMA for the bounds table *itself*, separate from the VMA >> being unmapped. ... > Does it depends on unmap_region()? Or IOW, does it has to be called > after unmap_region()? Now the calling sequence is: > > detach vmas > unmap_region() > mpx_notify_unmap() > > I'm wondering if it is safe to move it up before unmap_region() like: > > detach vmas > mpx_notify_unmap() > unmap_region() > > With this change we also can do our optimization to do unmap_region() > with read mmap_sem. Otherwise it does cause problem. I think changing the ordering is fine. The MPX bounds table unmapping is entirely driven by the VMAs being unmapped, so the page table unmapping in unmap_region() should not affect it.
