From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD0E9C36010 for ; Fri, 4 Apr 2025 23:32:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A0DD6B0005; Fri, 4 Apr 2025 19:32:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 450BB6B0007; Fri, 4 Apr 2025 19:32:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F0686B0008; Fri, 4 Apr 2025 19:32:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1062D6B0005 for ; Fri, 4 Apr 2025 19:32:38 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E246958676 for ; Fri, 4 Apr 2025 23:32:37 +0000 (UTC) X-FDA: 83297963154.13.0AE52EC Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf16.hostedemail.com (Postfix) with ESMTP id E293D180003 for ; Fri, 4 Apr 2025 23:32:35 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ol9SiNp2; spf=pass (imf16.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743809556; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kzspiJbW7QmXEAVW2g03GHzOnq2e3N4wowbiLpToSCY=; b=RF6MTLqcBJKjKExYz7h3mtVcYJ6QmHuHUxc2RMZjCo0/MAFlwlpudm+VOlJD5L08RNLwWp iE6vymFDqIFsU2e99hPDJijHQgL8jOYTDbHc/TO1VFkv58TTHIQSCS751g1WDHQzV+ZT+r JJki/iWekBIILqzmkEhbYL9zfuTFuxQ= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ol9SiNp2; spf=pass (imf16.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743809556; a=rsa-sha256; cv=none; b=VjsITr3/1jq436TNTFGosjGDrfpB5R+KB+jlzWSk05eQvJOD48ffqOf8qewCxGEa6Aq61l 46C319b5mf6lthpbIlo9Ju7/PdlFWVdr0Ktq/LNcsNoZF/ey/ka1LO0OW+mmPtxGBgQ2PA 5+j1JZ4WReDAg1bKxuaZyFZQQ7/yHNs= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-5e8be1bdb7bso4176665a12.0 for ; Fri, 04 Apr 2025 16:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743809554; x=1744414354; darn=kvack.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=kzspiJbW7QmXEAVW2g03GHzOnq2e3N4wowbiLpToSCY=; b=Ol9SiNp2+9RvdnxvArMGAaq/h0T4cQb9qslYslsx4ZGYmkwhMdCx8TO5Q026zUXYq2 /qtCb10VEhFE8jfM6zHeRGacHteuJHHVAcQq68J+C1y+eAWuJsQyV2NxDiPD5fUips+h svw4HGGwjGmzoAeyV6nReGxtbh3Vl0/Z9b/ILzjKlsfzJQfPb1eDA3scVL+oJK+P7rSs cS+DyPYMl+Wu6jzU/itk8pmHANeRu3IEDVRx0Nu4Sx08eKQekX2Qu4RMOxmWgOri0QIa XcDroHW/t7LAFrKKefYVN7YzX1B0ZonNhkYnk1cICBDfWPGB9hM8he46yPer7+QkQ9Fu S+ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743809554; x=1744414354; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=kzspiJbW7QmXEAVW2g03GHzOnq2e3N4wowbiLpToSCY=; b=Put62NErO5Ew3gHVj7eFtiQoW0WZvJe5KX/GRPdaNeN77e9UmWOxlVTYhmZ/YjtLYV YVJ2GHMlh+o3BdxAeKYqckPpfZzXtIIbREzPvbevv8c+Wrzp2Zv0zhDL1YYp1E8LfH1i g2FbqwXuVvPMSVRGqGb4XpKnTEexT/pdiP5g1Ift1X5wEyVBWKb9+TQZ62uCS8FXmYyf a+vPd+TDS8Ds2w/LRpqEtHwnGX5QhhSlOpeyAOlKORlZC04y1BQ7zfpvD5sKl/G1gevQ u29c1IqOHgRZ0s1gbdvcKaAS+pImTDSxLyp4fOdlE4Trfwt2rkkAw6VuKaw8I00vdkif KqGA== X-Forwarded-Encrypted: i=1; AJvYcCUIMCrBQiCl4gYinjs285D3CwkpSc0dyOlyrZY50t5AzxuGLOOvadXR5u70jMORwec3SEQdvgcstA==@kvack.org X-Gm-Message-State: AOJu0YyEv+JeHP4pfrNLQ13P3r6h1FeWoKBjmOQbnahwR6RsxHSG+Jr1 +4OXK62PMTO80ByM3NvTgN09ydUPHMNaIXR4ZRqA4YTfoxEbZOdT X-Gm-Gg: ASbGncuABu2L5HDWIkbp2iimn33ae2EaVOdHaImIgeqdrZlV1TTSyWIcX3fJh03wYr3 ScCtvRXioOJm7Ff81wq0nY+E6piF8vMcB0DHw+ZQi+NKrIYDCboVKQ27OdiTSD+ENP7q/QbmXjQ hcoxw/AlT/DHe48tHHn5nlGM+C1D/9mcmhJJX7IeuPiqZLuoGwyHvBUxVmb3UyTfMy1iPrObCUx 2LOwRBMr12OK7rwKn8mSJfQLH18w1QmVrPCQDpYvgXSv1I2o+0dmdYYmqt2OynklQQi+hDRrL4E pPVMg8Dzc9WTwnGCOYnen9iBK5JfquhBwFlkSDfUtFUR X-Google-Smtp-Source: AGHT+IE/vv1Smr2HKVwTss1S5tFHifeZYvCC4qt2WX7qSbvEhE97vHXCEg2l3mtN64QGaf4gVHTF7g== X-Received: by 2002:a05:6402:5c8:b0:5f0:d893:bf8a with SMTP id 4fb4d7f45d1cf-5f0db82be32mr619706a12.20.1743809554106; Fri, 04 Apr 2025 16:32:34 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5f0880a476bsm3047900a12.72.2025.04.04.16.32.32 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 04 Apr 2025 16:32:32 -0700 (PDT) Date: Fri, 4 Apr 2025 23:32:31 +0000 From: Wei Yang To: Lorenzo Stoakes Cc: Wei Yang , Andrew Morton , Vlastimil Babka , Jann Horn , "Liam R . Howlett" , Suren Baghdasaryan , David Hildenbrand , Matthew Wilcox , Rik van Riel , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] mm/vma: fix incorrectly disallowed anonymous VMA merges Message-ID: <20250404233231.bk62hjwq46vnrpmz@master> Reply-To: Wei Yang References: <20250404125315.5bou5ays7u7sv4rb@master> <2fcd2760-0116-491e-add2-c3277d5bb19b@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2fcd2760-0116-491e-add2-c3277d5bb19b@lucifer.local> User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Queue-Id: E293D180003 X-Rspamd-Server: rspam05 X-Rspam-User: X-Stat-Signature: g4h1omur6srxrpyfz4w6mpqtzm5drf9g X-HE-Tag: 1743809555-973287 X-HE-Meta: U2FsdGVkX19fJkeozfpi2HNRoSInAJ757RW4dcT0wiXeJjecfhBap01zMKVOs5zQhDrzj3xXCbQa25LeIwf4QZuJj28+QQgIfiyv+zpVeJimrDES3V48fD1K42BhE+d95cc7lrEmK/W8yatEm93zHJ52A+/cbz5m0KuC3dCSQIRSebqC2WLeEqJpicwESu0fZ+y01ozqwFoOmskQBBsgzj3as75FrCixcP4cGHU7wJnJPT0zN4HkM3CqEwhpFnSENl2n8OEMGGqhiM9MmsR+Mk6fhBNRzwWR9DdMmYGxNyqaUJVjN5OE5SB6UT4nL81jhKEwX2sXUbmKdYnxE7HVTnLuf+J03Q6MnyFq/W9ag+DaxKhYJjYcDwccxK5J72Z12VgM65/xue25Oo6T1vFPx17F4fsP3RKFwg/q1F6bcwUVVFOUq9LD/DAuaB2ze6cStAsZhp6bkNmvBh7Xfn2UYVAgM5YU4aRkuuUCUot3Y7JON84oH7KwL4c++YRmuqEgqTlAYtTtnzF/T1NPSkK2bc06g8Kgs6f3LtN8pmhcPA1daaOtRE1Njz3Ki0X73YHkvQ8+6Oq6+WvQmZslhOlYtlOY+oh2mkyJSN7ko1Te50uaNmr0m2DSFttzVIuHtcN05R6O2Ij5XqpmG0JdDL2rWRNGFU+I7qWsgq8Mnt8R5a4EIsffNZXzQl2VLEqkSLrlahphiwo/tdgz8/nW42i/WS4x4o2FEvu1Xs0ng+cjK/YxCNAXZlPqjPIJNyudZIUNQFZjTQRkALlLWd4YzjIhnOUZtGu0liuoLutMKPxh4huRLf7sFrEYN50Ij0rm8d++PjGvqjwBGMQFF90FnrPrqcp1B2v2kEvnZ4zH2Y29446SwnrPM24MuhOOhl1dbBFF5nbvzJjVZfBUP8Zvn41HEF9HEpUlUMjz3fm4aOEa3NxE60ztFFzfmwnTHcugQdzAPcWi6z09eAaVWx3Jv/e T82VQAC8 A7bc4fDR547RlLAxGvKxBpVqUz/ECN8FKZj3v5jebMb/AjKAngjnRuKlx3EzFrjHzz0rxmPVPkMMDaWBzet5560vyiXaR7ihkxS23gV+S4cELC4DEFxqZwfM7GDNg+48+Aqr7ydRlukzBkxaw1CnABrY3s2MNE3R5BL3iYKx5+A0H1+SU+8RN+4XbGZC/sjvz+2oU7trRjJ0K8HnKdiHA3MnfHgoLlg3otfi1S/b5KSyULa6UFzqkgZacHjNwrfSNB/rrzHfmOJlbg+pZzDhTIAZ773ozef7JdHRB/ale/hA7NnmsmH6EMh/qRd9AowNafJ1axbrHLcDVarrd5ow40duhCqdjuK+PJq9QGGNcUqae4x814JrxZbkXeCD+pjJQoxQFLE4iItl3FdurE6dyctP4wCeShPmzAs/w9moWw9HFAInn1aoD+4qd0mgMjiuSNwexaxe1z5B+GTY+D8XjKgQPcymaAY6oMas3aGBDDb7q8OiJ1C3GdTSp2ru4o0ks62ewy4OTVsggba3qqGTc18qeQS3MKov7YJCFq8ZCMS1qA7O723QaPe9M4iipcFm3eb7A2ttdUxQwmv8sUn4HrTyGhY/LOWE2xpdrbiOsIvjo7Gvntc4EcuVDOrVuww/AbdwYsgxqyZRzEDhJW+zyUZbBZk4D+Dsd5a0k X-Bogosity: Ham, tests=bogofilter, spamicity=0.000090, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Apr 04, 2025 at 02:04:10PM +0100, Lorenzo Stoakes wrote: >On Fri, Apr 04, 2025 at 12:53:15PM +0000, Wei Yang wrote: >> On Mon, Mar 17, 2025 at 09:15:03PM +0000, Lorenzo Stoakes wrote: >> [...] >> >However, we have a problem here - typically the vma passed here is the >> >destination VMA. >> > >> >For instance in vma_merge_existing_range() we invoke: >> > >> >can_vma_merge_left() >> >-> [ check that there is an immediately adjacent prior VMA ] >> >-> can_vma_merge_after() >> > -> is_mergeable_vma() for general attribute check >> >-> is_mergeable_anon_vma([ proposed anon_vma ], prev->anon_vma, prev) >> > >> >So if we were considering a target unfaulted 'prev': >> > >> > unfaulted faulted >> > |-----------|-----------| >> > | prev | vma | >> > |-----------|-----------| >> > >> >This would call is_mergeable_anon_vma(NULL, vma->anon_vma, prev). >> > >> >The list_is_singular() check for vma->anon_vma_chain, an empty list on >> >fault, would cause this merge to _fail_ even though all else indicates a >> >merge. >> > >> >> Great spot. It is hiding there for 15 years. > >Thanks! > >> >> >Equally a simple merge into a next VMA would hit the same problem: >> > >> > faulted unfaulted >> > |-----------|-----------| >> > | vma | next | >> > |-----------|-----------| >> > >> [...] >> >--- >> > mm/vma.c | 81 +++++++++++++++++++++++--------- >> > tools/testing/vma/vma.c | 100 +++++++++++++++++++++------------------- >> > 2 files changed, 111 insertions(+), 70 deletions(-) >> > >> >diff --git a/mm/vma.c b/mm/vma.c >> >index 5cdc5612bfc1..5418eef3a852 100644 >> >--- a/mm/vma.c >> >+++ b/mm/vma.c >> >@@ -57,6 +57,22 @@ struct mmap_state { >> > .state = VMA_MERGE_START, \ >> > } >> > >> >+/* >> >+ * If, at any point, the VMA had unCoW'd mappings from parents, it will maintain >> >+ * more than one anon_vma_chain connecting it to more than one anon_vma. A merge >> >+ * would mean a wider range of folios sharing the root anon_vma lock, and thus >> >+ * potential lock contention, we do not wish to encourage merging such that this >> >+ * scales to a problem. >> >+ */ >> >> I don't follow here. Take a look into do_wp_page(), where CoW happens. But I >> don't find where it will unlink parent anon_vma from vma->anon_vma_chain. > >Look at anon_vma_clone() in fork case. It's not the point of CoW that's the >issue, it's propagation of AVC's upon fork. > >> >> Per my understanding, the unlink behavior happens in unlink_anon_vma() which >> unlink all anon_vma on vma->anon_vma_chain. And the normal caller of >> unlink_anon_vma() is free_pgtables(). Other callers are on error path to >> release prepared data. From this perspective, I don't see the chance to unlink >> parent anon_vma from vma->anon_vma_chain either. >> >> But maybe I missed something. If it is not too bother, would you mind giving >> me a hint? > >What you're saying is 'we never go back and fix this up once unCoW'd' which is >true, but I don't want to write several page-length essays in comments, and this >is a sensible way of looking at things for the purposes of this check. > >In future, we may want to actually do something like this, if it makes sense. > Ok, this is the future plan instead of current behavior. My personal feeling is it would misleading to readers. I would think if all pages mapping in VMA is Cow'd, the vma->anon_vma_chain becomes singular in current kernel. A page-length comment is not we want, how about "maybe_root_anon_vma"? When vma->anon_vma_chain is empty or singular, it means the (future) vma->anon_vma is the root anon_vma.