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 8113EC369D9 for ; Thu, 1 May 2025 01:18:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6701A6B009E; Wed, 30 Apr 2025 21:18:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F84A6B00A1; Wed, 30 Apr 2025 21:18:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 470136B00A4; Wed, 30 Apr 2025 21:18:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 243046B009E for ; Wed, 30 Apr 2025 21:18:50 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1272A1D0134 for ; Thu, 1 May 2025 01:18:50 +0000 (UTC) X-FDA: 83392579620.02.BFB4968 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf09.hostedemail.com (Postfix) with ESMTP id 11A53140002 for ; Thu, 1 May 2025 01:18:47 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Axv2RVNr; spf=pass (imf09.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.53 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=1746062328; 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=buwUSlS7iEVrH/m6Xzic7WPuufqccacCKhokCKCBl2w=; b=Ch5mxGqdG3pj9kbP2YCEO0QWwKzioV+/Q5e4PYimvkOvsax/KUAAnWRsLQP0zrIlNdAXa8 IedVnrCs3ho4izYWjycFMvYdUG2cs9jAJZYMGp5J2BMaIf0EvasRWSpCDdboSBdNbU6s5x 5sK0oCv8RdyjEUmr/mymFVLsGRZB/yQ= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Axv2RVNr; spf=pass (imf09.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.53 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=1746062328; a=rsa-sha256; cv=none; b=btnYRD6C7qrQmhu3/UKBqQgHLnq8vGxWVFhAsbnLUu9KRudQNEHwjGKzgHjYEGBFbzPP1U JJbIhXn1doODzVE9TvqgbqS0IvnrHargQ+9BBJaaKbzPxToTZxCdVuoxHubQ95M9YkyOBe sxVVCq/KfciSuQts5szd7Qu8MEE1wpY= Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-acb615228a4so305992366b.0 for ; Wed, 30 Apr 2025 18:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746062326; x=1746667126; 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=buwUSlS7iEVrH/m6Xzic7WPuufqccacCKhokCKCBl2w=; b=Axv2RVNr6HpVncgVxldI6ARh0jgx08yYbc3ZrBAqbcQSfLR3KqQ0P8tzZSNPJFT/m4 SOBcJKlpuzXTpfM8wCJcnjaHxcOaVl/lFR5hkZ6KB2oPfOjfV6+Fd/Gg0lWrEL4k86Lo NvlecIHwe2U41+NZ7/5Q3Bx9L6xjm7GMgqnWikt8fRq8esIn+MZnWa8pQhceWeeztF8U LgxERD+393PQ2hVIdTuWEyQ1ICykPk6ScbO4k5SKNlrY+YeCmMmpH6GwXEjmDUUiNm96 EcM/3oCkuUNNCza/IZ8ny/eThdu50YnxJ62Z/Sl8ZuMHuNXCgeMUHvyOYUpV4IuqO+CZ zxXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746062326; x=1746667126; 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=buwUSlS7iEVrH/m6Xzic7WPuufqccacCKhokCKCBl2w=; b=WVDse7eQYsUiosOCThG6l1/UNmOPUyhWGxQqN8YD71VXc3y+8Ac5peNa4zr9mRV6+n CxIk0zjULE5XMvJZMsQsbrXViJa7IoS34jIhesuV18srdcxEOgb9cKt8F5pXhOoA126b cfYWqjCLzWblec4K26aOaJGQ1P/syelNUTLTGblvBCq1h7U/J5zA6wbS+ukbKK+3m4gx XPIq0Sq4mbaFBnPaLt27oR1+V9TTarANSCvIkfhE+YDSg0Dwr8+Smt6B0vDhpVcb/wtB YVJqB121vPmS0DuzPx2vtcKAC3Km3ucBEgXHs+VAQpc4NS5i0aU2Qo4gabRRCFNPsS2r aydQ== X-Forwarded-Encrypted: i=1; AJvYcCU2ruRJNdq6PDcQ5fuZkaSXpAScU3BWHm30LsLySfhbS67LREjNBVQ70TXbV6Kv8NbfVChPUg5LYQ==@kvack.org X-Gm-Message-State: AOJu0YyObQgNG2tzNFlHTVS3Zl0Ci0nU8C0GGIlqIRpE/hzqc3GsnF9n v34qG/WncesMzW8QpmCdaragvAG1lmy9GbK2kfBvi9JeA7HistkI X-Gm-Gg: ASbGncv7nTf3JVAN+6CBf6XyIhC0Yuj5ibNNgNSjs7HM3AC/y4rBIkX6goSn4lfdLu2 edzVal7gNGAwsgT85Jh29nUWWZHuZDowCJSWimQDrMAVh0kfSq/BXSDBgX1yHaBG0wl3YkEPRRI Iqqkq2JPCVpPx3bJImXhXStfzsIex1P3wfa/mW3GaDzU1TWET7JI5w5FkL98DkJ63EVxS+DM4/O YWYTYkMmELUeD86CGG+CYlP2mcxqvNSGtnbmBcw+xJPqShfrMntUmMZJ+76d7pMs7hAr+dKHq0c gNx1wBih5fe3E8O3ua+6i5IaSqsyforyxDNYR36yXhltu72UEo4= X-Google-Smtp-Source: AGHT+IHQdFsCgwAedDrVKruzmw1YWcu3XgOYfrqpDjIFjH+NnJt/gdX6kuCX5txwMnFkkN3KXxmypA== X-Received: by 2002:a17:906:7092:b0:ac7:81b0:62c9 with SMTP id a640c23a62f3a-aceff3c3c61mr33880766b.20.1746062326124; Wed, 30 Apr 2025 18:18:46 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ace6edafec7sm988202666b.165.2025.04.30.18.18.45 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 30 Apr 2025 18:18:45 -0700 (PDT) Date: Thu, 1 May 2025 01:18:45 +0000 From: Wei Yang To: Lorenzo Stoakes Cc: Wei Yang , Andrew Morton , Vlastimil Babka , Jann Horn , "Liam R . Howlett" , Suren Baghdasaryan , Matthew Wilcox , David Hildenbrand , Pedro Falcato , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 01/10] mm/mremap: introduce more mergeable mremap via MREMAP_RELOCATE_ANON Message-ID: <20250501011845.ktbfgymor4oz5sok@master> Reply-To: Wei Yang References: <87e668d54927bb4ccdb7d374275e0662de667697.1745307301.git.lorenzo.stoakes@oracle.com> <20250430004703.63rumj4znewlbc2h@master> <8c052822-5365-4178-8e06-ecd4f917cf8a@lucifer.local> <20250430154119.a5ljf5t5tutqzim5@master> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 11A53140002 X-Stat-Signature: ihtz7jqswg8bf11a7485ynfzzprnj11o X-HE-Tag: 1746062327-173350 X-HE-Meta: U2FsdGVkX1/KM4UJofZMOxJOzuIU+G8s4P+H3nXBgdPQRj80ecXBr2aHzEH0kT8KrGmLKa7WnYd+PoMRI9Q3impjH3Ob87DijRFB8L+LzpHeGO8e+KO6ag5QOwQwDs64QKrlRYaodUMadm0Vr++R4qpaawP4CVA+JI0xq/BQAYVHETj80XQa4YiC9myZQsrM7jtJyTqx9/wuoxddrKawFrWi3RkKzER5rk+K4EEV/Ib2UINNbYqI1kHNUScHqls0yuW60rrJ+US87INsIoU/oLTWpozxosexX6CfNbzU568zXtHvGM8HxpoxxsoK0fWE+zOnuw6P5gBz1b2NbNhtcO2Lcck59gj1B0BzQrRyvfNS7JWfOUL8n/Ui1UMracQ69Av/5dcfaGjqtIZsm3Ur6Ny6H1VNlUx4g4e89q3ORvIGIUfN1l9kr0Z0ZJX77bFfnlFCTM9nB5GBTcFPG+J4aIFZV/CosUYO6R8KcKCdxX1t0stxrFEB+Z7e+5eLs8O3N6PkFH4KMxmSAW1/P921tWx69pyYRhFmX6PZNUNeY52THBugcQ5j+gUcUGSEz5IxyJmDhtgheOLyrhMuhKYsvW2ef3tFV7WD8OVUzZ6F4WlyHaczVDz27eEOmC660tLh8Wo5kLQWPkXW0jqnR15dsLvn4buA+VR18QqKK84L/jLovb+X4Aqf87gCO8SzUAPS8N0XyGmWJynLuHgXBJApMB19nQ176QMna9ql2bcGv0PxxYZYXjp9wXaxFzAgsmrAZV9LEj9JiCjS5bv/PjsqzG3sfcPBLOlYrvANAQiA5U1maYfgAY9Jnqttl0hxn4EkuYzRH99x63yG7+S8+nz/EvcdDuhhGEJyGldwdOJpZfDW8tTvSXLBth1cYVeikI7oy1vYmOO5d5ccQ6pGLs2Jka2VhWEQchvG4mj0jXWZDXjO19O81MsVL/zu/AHdUxR1CglgKvOhcLabeWkzo7z SmjDa1V2 8bY4IiSGHQZqRWCmWMGGOEPcgZNx3BBQg1dtFhTLKHgmLwP8zQ3tCGMfM8N4LWC8tPNOaOnkZjBldBfU19/e/uDBjhJ9ZDFSOLG4gfDd3dhyT56FuWzEXNrrhPP1jewDf6IOCl0Cqb8tVTxvOjn7UBVDeQMO+bQ8zIqnJDynohVH2rGmpnfZs/U+8K1tAsjmjBrc+XUDyo5CVPyeBy40fquEUZqFEtz2VmnGb2oFSDDzRFuTbwgDmVFq7AIjewhaCtLEnCxZgCZvXwObgw1Dz6PCo1TNxJKctMMX8zyFxlhXTIacZqIjILfeLM/+Hn42txm36JvA6tBlotkHXY9qd4iM1CHTy7Qw2kLNzEuKYddG+vTyLiq5wNqEzspzRSJsgQf5/KWLPqnUw1bpwpgZuDnjy3l7RU8ZvfcqLfyiCUzbs1fsEJ2Pbgc+cRfoT49LjX8dgYifkGEi73Fw/ApevyQ4bokgKomrHY93N3AJsny0Uhu8GZ5Tu9a5OX0V+f1PR/aushjn4hVQxSOuoaddWhqYlToW7aLOwl8PYDZPfSgyC3uvchK43V2/EVhz7xx+QncK8khKXDQHP1PoiLVpBbr//y0sn6GdmHfRWrbJIt3Ns1cQ6qVULojPBTAoI6B+8/99FzWQ8WPIA5cO3TRu+XfVGfCPbPF26wqIA+Wp9bTnj/K8RuX4V0YXRaqiMPEBNTMKT0ZZ91iQiO3045O3ckU0g1DTB1eiqyqHvOnwN2OzAKUuIl2IFSJdqDJboSC6FUddXhvHISPP33o4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Wed, Apr 30, 2025 at 05:07:40PM +0100, Lorenzo Stoakes wrote: >On Wed, Apr 30, 2025 at 03:41:19PM +0000, Wei Yang wrote: >> On Wed, Apr 30, 2025 at 02:15:24PM +0100, Lorenzo Stoakes wrote: >> >On Wed, Apr 30, 2025 at 12:47:03AM +0000, Wei Yang wrote: >> >> On Tue, Apr 22, 2025 at 09:09:20AM +0100, Lorenzo Stoakes wrote: >> >> [...] >> >> >+bool vma_had_uncowed_children(struct vm_area_struct *vma) >> >> >+{ >> >> >+ struct anon_vma *anon_vma = vma ? vma->anon_vma : NULL; >> >> >+ bool ret; >> >> >+ >> >> >+ if (!anon_vma) >> >> >+ return false; >> >> >+ >> >> >+ /* >> >> >+ * If we're mmap locked then there's no way for this count to change, as >> >> >+ * any such change would require this lock not be held. >> >> >+ */ >> >> >+ if (rwsem_is_locked(&vma->vm_mm->mmap_lock)) >> >> >+ return anon_vma->num_children > 1; >> >> >> >> Hi, Lorenzo >> >> >> >> May I have a question here? >> > >> >Just ask the question. >> > >> >> Thanks. >> >> My question is the function is expected to return true, if we have forked a >> vma from this one, right? >> >> IMO there are cases when it has one forked child and anon_vma->num_children == 1, >> which means folios are not exclusively mapped. But the function would return >> false. >> >> Or maybe I misunderstand the logic here. > >I mean, it'd be helpful if you delineated which cases these were? > Sorry, I should be more specific. >Presumably you're thiking of something like: > >1. Process 1: VMA A is established. num_children == 1 (self-reference is counted). >2. Process 2: Process 1 forks, VMA B references A, a->num_children++ >3. Process 3: Process 2 forks, VMA C is established (maybe you think b->num_children++?) Maybe this is the key point. Will explain below at ***. >4. Unmap vma B, oops, a->num_children == 1 but it still has C! > >But that won't happen, as VMA C will be referencing a->anon_vma, so in reality >a->anon_vma->num_children == 3, then after unmap == 2. > The case here could be handled well, I am thinking a little different one. Here is the case I am thinking about. If my understanding is wrong, please correct me. a VMA A +-----------+ +-----------+ | | ---> | av| == a +-----------+ +-----------+ \ \ |\ VMA B | \ +-----------+ | > | av| == b | +-----------+ \ \ VMA C \ +-----------+ > | av| == c +-----------+ 1. Process 1: VMA A is established, num_children == 1 2. Process 2: Process 1 forks, a->num_children++ and b->num_children == 0 3. Process 3: Process 2 forks, b->num_children++ => b->number_children == 1 If vma_had_uncowed_children(VMA B), we would check b->number_children and return false since it is not greater than 1. But we do have a child process 3. *** Come back the b->num_children. After re-read your example, I guess this is the key point. In anon_vma_fork(), we do anon_vma->parent->num_children++. So when fork VMA C, we increase b->num_children instead of a->num_children. To verify this, I did a quick test in my test cases in test_fork_grand_child[1]. I see b->num_children is increased to 1 after C is forked. Will reply in that thread and hope that would be helpful to communicate the case. Well, if I am not correct, feel free to correct me :-) [1]: http://lkml.kernel.org/r/20250429090639.784-3-richard.weiyang@gmail.com >References to the originally faulted-in anon_vma is propagated through the >forks. > >anon_vma logic is tricky, one of many reasons I want to (significantly) rework >it. > >Though sadly there is a lot of _essential_ complexity, I do think we can do >better. > -- Wei Yang Help you, Help me