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.
Thanks for confirming this. I didn't realize there is VMA for bounds
table itself.
But, this code is very likely to go away soon. If it's causing a
problem for you, let me know and I'll see if I can get to removing it
faster.
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.
Thanks,
Yang
