From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F0473A4505; Mon, 10 Aug 2026 08:36:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786351016; cv=none; b=cKsLIG302uAFmHa2DLz0E4YM5XqC5VWGCB6yFmWmWKguFsGQ847sHhS5mqMv1qxYtLiDFfQMAfPSLj7+gKoJ8Vbo0DBiCW+v+1KWJtBlQLfPjQ2rjaeZwPatPLF4QgvTe7q9ayt7A/QN2czPxMCEeBoJBuyNchkP/qk1ROfn0FM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786351016; c=relaxed/simple; bh=0heE0aeUQp5JoHVaYB/JZs1HN8xkC2lK7gU6vSQV+9A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B1E8wyD4Uq1SkzNfffuqybEFJE5SC9+auyTJxhcpXBGB7UTOCYzMmVFnFFYmaTsJJkB9D4PGgJFUal1IvzSqjfNbeL+ybVQet60cLTxjHYmpXFNPkwzzWMLgKlIvtEfR7SSnaz+Xi2VohYWAlS9tmSeXNwlDmlLRVQa+kLxDI/Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WG9vfruA; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WG9vfruA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E7FC1F00A3D; Mon, 10 Aug 2026 08:36:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786351015; bh=JV5WNgHkpKWzZzTADt5HV8WfufvTRE1W/LdtA3ppIU0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=WG9vfruAdcqV26E8riIECGmFnBJZd5QFGEF/vLwr28j8gC4/i7xF0ppv5LbXGsZXX JxNn+AK3ID5hxM+oY6+3ga/4g5kSAUZ3bpLvKsQ3jdW2iUMHhzYR8K+qeLV3wBd+SH VfMjlXUAPInIsYgKwkG0faj9NQPkTn8mbqTh93b2RkQ6vc61GikkngdVPvCYS8u1v3 Bbmd+K6Qvi9MyaqQYp3ipshXdNTBrXxLxAhKWBNy+rqBS761NXJu8HVp2apMLGHoSi TNqEO7IDleHDyLVMiyzHc0N4UA6L3SFYnW+RHipKKKGb19601kNwdtCQOjQmzQOcPt EgpNCWtEiomWw== Date: Mon, 10 Aug 2026 09:36:21 +0100 From: "Lorenzo Stoakes (ARM)" To: Suren Baghdasaryan Cc: Andrew Morton , David Hildenbrand , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Michal Hocko , Jann Horn , Pedro Falcato , "Matthew Wilcox (Oracle)" , Jan Kara , Miaohe Lin , Naoya Horiguchi , Rik van Riel , Harry Yoo , Lance Yang , Kees Cook , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Usama Arif , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Peter Xu , Xu Xin , Chengming Zhou , Arnd Bergmann , Greg Kroah-Hartman , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Sven Schnelle , Alex Deucher , Christian =?utf-8?B?S8O2bmln?= , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Boris Brezillon , Steven Price , Liviu Dudau , Huang Rui , Matthew Auld , Thomas =?utf-8?Q?Hellstr=C3=B6m?= , Rodrigo Vivi , Masami Hiramatsu , Oleg Nesterov , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Jason Gunthorpe , John Hubbard , Muchun Song , Oscar Salvador , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Youngjun Park , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, kvm@vger.kernel.org, linux-s390@vger.kernel.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-perf-users@vger.kernel.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH v4 01/20] mm/vma: introduce VMA anon page offset field and add helpers Message-ID: References: <20260806-b4-scalable-cow-virt-pgoff-v4-0-ab318a350404@kernel.org> <20260806-b4-scalable-cow-virt-pgoff-v4-1-ab318a350404@kernel.org> Precedence: bulk X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Sat, Aug 08, 2026 at 05:51:10PM -0700, Suren Baghdasaryan wrote: > On Thu, Aug 6, 2026 at 1:22 PM Lorenzo Stoakes (ARM) wrote: > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 87feaa5a2b78..df78847f5f07 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -4393,6 +4393,65 @@ static inline pgoff_t vma_last_pgoff(const struct vm_area_struct *vma) > > return vma_end_pgoff(vma) - 1; > > } > > > > +/** > > + * vma_start_anon_pgoff() - Get the anonymous page offset of the start of @vma > > + * @vma: The VMA whose anonymous page offset is required. > > + * > > + * If unfaulted, then this is vma->vm_start >> PAGE_SHIFT, if faulted then the > > + * anonymous page offset at the time of first fault. > > + * > > + * If the VMA is anonymous, this returns the same value as vma_start_pgoff(). > > + * > > + * This value is used for tracking MAP_PRIVATE file-backed mappings by their > > + * anonymous page offset. > > I assume this function should not be used with shared file-backed > mappings, right? If so, maybe add a comment like the one you have for > linear_anon_page_index(): "It is not valid to call this function for > shared file-backed mappings."? No that's not the case, it is valid to access this for any VMA though it's only meaningful for MAP_PRIVATE and anonymous VMAs (though in the latter case pgoff == anon pgoff). The code keeps the anon pgoff values consistent even for shared mappings because - hey - we have the field anyway and it's easiest and safest to just keep it the same. One alternative would be to have code that checks the flags and zeroes the field otherwise , but then you have problems like - early on initialisation now there's an ordering requirement which can easily go wrong. Another alternative is to just leave it stale, but then that seems objectively worse and again requires branching code on update and set. All-in-all it's easier to keep this working the same for any type of mapping, it's just useless to do anything with the anon pgoff for a shared mapping :) -- Cheers, Lorenzo