Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 1 Dec 2022 00:43:58 +0300
From:   Cyrill Gorcunov <gorcunov@gmail.com>
To:     Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Mel Gorman <mgorman@suse.de>, Peter Xu <peterx@redhat.com>,
        David Hildenbrand <david@redhat.com>,
        Andrei Vagin <avagin@gmail.com>, kernel@collabora.com,
        stable@vger.kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm: set the vma flags dirty before testing if it is
 mergeable
Message-ID: <Y4fOnsav2CK5lcA7@grain>
References: <20221122115007.2787017-1-usama.anjum@collabora.com>
 <Y4W0axw0ZgORtfkt@grain>
 <ecef5201-04d5-3618-a667-2e7c4770b908@collabora.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ecef5201-04d5-3618-a667-2e7c4770b908@collabora.com>
User-Agent: Mutt/2.2.7 (2022-08-07)
Precedence: bulk

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@redhat.com/
> and we can proceed with this.
> 
> > 
> >>
> >> [1] https://lore.kernel.org/all/20221109102303.851281-1-usama.anjum@collabora.com/
> >> [2] https://lore.kernel.org/all/bfcae708-db21-04b4-0bbe-712badd03071@redhat.com/

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