On Tue, 28 Oct 2014, Ren Qiaowei wrote: > On 10/28/2014 04:49 AM, Thomas Gleixner wrote: > > On Mon, 27 Oct 2014, Ren Qiaowei wrote: > > > If so, I guess that there are some questions needed to be considered: > > > > > > 1) Almost all palces which call do_munmap() will need to add > > > mpx_pre_unmap/post_unmap calls, like vm_munmap(), mremap(), shmdt(), etc.. > > > > What's the problem with that? > > > > For example: > > shmdt() > down_write(mm->mmap_sem); > vma = find_vma(); > while (vma) > do_munmap(); > up_write(mm->mmap_sem); > > We could not simply add mpx_pre_unmap() before do_munmap() or down_write(). > And seems like it is a little hard for shmdt() to be changed to match this > solution, right? Everything which does not fall in place right away seems to be a little hard, heavy weight or whatever excuses you have for it. It's not that hard, really. We can simply split out the search code into a seperate function and use it for both problems. Yes, it is quite some work to do, but its straight forward. > > > 3) According to Dave, those bounds tables related to adjacent VMAs within > > > the > > > start and the end possibly don't have to be fully unmmaped, and we only > > > need > > > free the part of backing physical memory. > > > > Care to explain why that's a problem? > > > > I guess you mean one new field mm->bd_remove_vmas should be added into staruct > mm, right? That was just to demonstrate the approach. I'm giving you a hint how to do it, I'm not telling you what the exact solution will be. If I need to do that, then I can implement it myself right away. > For those VMAs which we only need to free part of backing physical memory, we > could not clear bounds directory entries and should also mark the range of > backing physical memory within this vma. If so, maybe there are too many new > fields which will be added into mm struct, right? If we need more data to carry over from pre to post, we can allocate a proper data structure and just add a pointer to that to mm. And it's not written in stone, that you need to carry that information from pre to post. You could do the unmap/zap work in the pre phase already and reduce mpx_post_unmap() to up_write(mm->bt_sem). I gave you an idea and the center point of that idea is to have a separate rwsem to protect against the various races, fault handling etc. You still have to think about the implementation details. Thanks, tglx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>