Re: [PATCH v2] mm: set the vma flags dirty before testing if it is mergeable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 29, 2022 at 06:49:53PM +0500, Muhammad Usama Anjum wrote:
> > ioctl might be an option indeed
> Thank you for supporting this. I'll track down the issue caused by
> remapping and mprotect mentioned here:
> https://lore.kernel.org/all/bfcae708-db21-04b4-0bbe-712badd03071@xxxxxxxxxx/
> and we can proceed with this.
> 
> > 
> >>
> >> [1] https://lore.kernel.org/all/20221109102303.851281-1-usama.anjum@xxxxxxxxxxxxx/
> >> [2] https://lore.kernel.org/all/bfcae708-db21-04b4-0bbe-712badd03071@xxxxxxxxxx/

Hi Muhammad! Hopefully I'll find some time soon to read all these conversation,
so for now my replies might be simply out of context. Initially the vma softdirty
was needed to catch a case where memory remapped inplace and what is worse it might
have _same_ ptes dirty after clear_refs call. IOW, the process allocated vma and
write some data into. Then we (page tracker process) come in, read pagemap and clear
softdirty bits, and page traker process terminates. While we're not watching the program
unmaps vma, maps new one with same size and what is worse it writes data to the same pages
as we saw at last scan time. So without VM_SOFTDIRTY we won't be able to find that this
VMA is actually carrying new pages which were not yet dumped.

And similar scenario can be for merging: say former vma has been 4 pages, we scan it
and clear dirty pages at low and hight address. Then process splits this VMA to two with
gap inbetween and then map new area which merge them all into one vma, and process can
write again pages to same address so we have to mark this new VMA as softdirty. If only
I rememeber correctly about the initial idea :)



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux