On Tue, Aug 08, 2017 at 04:29:32PM +0530, Anshuman Khandual wrote: > On 06/16/2017 11:22 PM, Laurent Dufour wrote: > > From: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > > > > First of all, please do mention that its adding a new element into the > vm_area_struct which will act as a sequential lock element and help > in navigating page fault without mmap_sem lock. You're not making sense, there is no lock, and the lines below clearly state we're adding a sequence count. > > > Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence > > counts such that we can easily test if a VMA is changed > > Yeah true. > > > > > The unmap_page_range() one allows us to make assumptions about > > page-tables; when we find the seqcount hasn't changed we can assume > > page-tables are still valid. > > Because unmap_page_range() is the only function which can tear it down ? > Or is there any other reason for this assumption ? Yep. > > > > The flip side is that we cannot distinguish between a vma_adjust() and > > the unmap_page_range() -- where with the former we could have > > re-checked the vma bounds against the address. > > Distinguished for what purpose ? It states. If you know its a vma_adjust we could just check if we're inside the new boundaries and continue. But since we cannot, we have to assume the worst and bail. -- 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>
