From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4582B27F01B for ; Mon, 17 Nov 2025 04:39:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763354385; cv=none; b=N5RKlne5qs6+1uNW+DiidxQP/H97X1vl7HrJgndI2K8biLUwFrSntxegAK3dkGYQi1DAxok0TCYukauyz30BpkLCT2xV8LqxSqNABIYUX7vGp4tAYvbcNVlizE0Hh7FbG9JSZHL02rOobgXYLuBORAxYLHlktQFpGd+AxzHI+Yk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763354385; c=relaxed/simple; bh=6MJYMREd2KSy2sHZWutbi5FMhZ8u0XAdxAa705cPrd0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HBRZfO7ulNeF15xej3p4a1VQbay6yiTmvYVtH0B8uuEnOOUnyA5u8Isgz0m8XRf65QsM+yh+NZTrP89wnFkcjc5rNZJxfx9CI4HTGkE0cmCDUgk4gBCp+hpnf5Rphx0lwL/eQiQj1kHF7cYslJTMtcxyVTjqwo5Z+HgA+zH6p5Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C693DFEC; Sun, 16 Nov 2025 20:39:35 -0800 (PST) Received: from [10.164.18.52] (unknown [10.164.18.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 284213F63F; Sun, 16 Nov 2025 20:39:39 -0800 (PST) Message-ID: Date: Mon, 17 Nov 2025 10:09:37 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] mm: propagate VM_SOFTDIRTY on merge To: Lorenzo Stoakes , Andrew Morton Cc: David Hildenbrand , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: Content-Language: en-US From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14/11/25 11:23 PM, Lorenzo Stoakes wrote: > Currently we set VM_SOFTDIRTY when a new mapping is set up (whether by > establishing a new VMA, or via merge) as implemented in __mmap_complete() > and do_brk_flags(). > > However, when performing a merge of existing mappings such as when > performing mprotect(), we may lose the VM_SOFTDIRTY flag. > > This is because currently we simply ignore VM_SOFTDIRTY for the purposes of > merge, so one VMA may possess the flag and another not, and whichever > happens to be the target VMA will be the one upon which the merge is > performed which may or may not have VM_SOFTDIRTY set. > > Now we have the concept of 'sticky' VMA flags, let's make VM_SOFTDIRTY one > which solves this issue. > > Additionally update VMA userland tests to propagate changes. > > Suggested-by: Vlastimil Babka > Signed-off-by: Lorenzo Stoakes > --- > include/linux/mm.h | 23 +++++++++++------------ > tools/testing/vma/vma_internal.h | 23 +++++++++++------------ > 2 files changed, 22 insertions(+), 24 deletions(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 43eec43da66a..fd9eeff07eb5 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -532,29 +532,28 @@ extern unsigned int kobjsize(const void *objp); > * possesses it but the other does not, the merged VMA should nonetheless have > * applied to it: > * > + * VM_SOFTDIRTY - if a VMA is marked soft-dirty, that is has not had its > + * references cleared via /proc/$pid/clear_refs, any merged VMA > + * should be considered soft-dirty also as it operates at a VMA > + * granularity. > + * > * VM_MAYBE_GUARD - If a VMA may have guard regions in place it implies that > * mapped page tables may contain metadata not described by the > * VMA and thus any merged VMA may also contain this metadata, > * and thus we must make this flag sticky. > */ > -#define VM_STICKY VM_MAYBE_GUARD > +#define VM_STICKY (VM_SOFTDIRTY | VM_MAYBE_GUARD) > > /* > * VMA flags we ignore for the purposes of merge, i.e. one VMA possessing one > * of these flags and the other not does not preclude a merge. > * > - * VM_SOFTDIRTY - Should not prevent from VMA merging, if we match the flags but > - * dirty bit -- the caller should mark merged VMA as dirty. If > - * dirty bit won't be excluded from comparison, we increase > - * pressure on the memory system forcing the kernel to generate > - * new VMAs when old one could be extended instead. > - * > - * VM_STICKY - If one VMA has flags which most be 'sticky', that is ones > - * which should propagate to all VMAs, but the other does not, > - * the merge should still proceed with the merge logic applying > - * sticky flags to the final VMA. > + * VM_STICKY - If one VMA has flags which most be 'sticky', that is ones > + * which should propagate to all VMAs, but the other does not, > + * the merge should still proceed with the merge logic applying > + * sticky flags to the final VMA. > */ > -#define VM_IGNORE_MERGE (VM_SOFTDIRTY | VM_STICKY) > +#define VM_IGNORE_MERGE VM_STICKY Logically VM_STICKY should be the only flag qualifying for VM_IGNORE_MERGE. In that case should not VM_IGNORE_MERGE flag be dropped all together ?