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 :)
