From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 8C0A1273D77 for ; Sat, 24 Jan 2026 18:52:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=67.231.145.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769280740; cv=none; b=dHoyl7PZaiFNs9pBMCdAILFp518IXR4ZQ4tOK8k25fptM+50qdrbM2AjqTNqNDvJtmb73TwnjokQSWAUtpILHwrXxowRuYeDURcA0jfJ7MiqBZ0hTq2VW/nVktWY9Qe6lW3q11kuWdUAz6LkUbTQ8G1vwHA/b0YaT0Wjb+6X4lM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769280740; c=relaxed/simple; bh=mPNrPh041QkJr8us5L+MXKEI76kxIU8OGpEkZSCxOfs=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VEOAOpWdVlybimHUY/q5KXQtuTeTwi3bQ2t+VH3PCYkABOQgoUhw6KAQcUo0/WFl4iYoZZKQPo9IhY6BLcR11n0FdFfCOQY6gUW4/9eBfF7A+ppoyufeSSvybqwZxtQEJk0LTXsiHXMcqHfejDNfBCKC9p/llz1FW0mK8iDuj/o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=meta.com; spf=pass smtp.mailfrom=meta.com; dkim=pass (2048-bit key) header.d=meta.com header.i=@meta.com header.b=o1chr7v9; arc=none smtp.client-ip=67.231.145.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=meta.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=meta.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=meta.com header.i=@meta.com header.b="o1chr7v9" Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 60OAmNx33979789; Sat, 24 Jan 2026 10:46:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=s2048-2025-q2; bh=cW+1ftD0Dn7OqF1vQTlFaX5dTZfhVWFeJzH1lpwdqxw=; b=o1chr7v9q1Tw Dnq9/THrymZWT/c3ZVIC0JNaEoubZZEAiTbnhIFbe1mPiN+iJddGW4K+1A1saN9y JGIiN5EWFnfL5UwBoX+1ds7pG94sYAwDjBV52tkREkj7K8IrhZLjEJCc5nMMBptF mttAeot9WEsNDr9UCVj6CkhB8Xku9STlCG7iFuGXPch1g7kOutSQFcCZvBR3XJTD AskZ2+KKKkhpewfjKQLzAY1spb0F8Y8bOs+ygbYN7aZcNhAJzUEfWZtSnjB+Dj9k /J2gNuqZ6FnUrcu+lqlzB68gLdqbYIxOovz31W0zuzNhURjuI7a35BFkmdMMnIxZ +RZlER8/Zg== Received: from mail.thefacebook.com ([163.114.134.16]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 4bvvn1j225-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 24 Jan 2026 10:46:22 -0800 (PST) Received: from devbig003.atn7.facebook.com (2620:10d:c085:208::f) by mail.thefacebook.com (2620:10d:c08b:78::c78f) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.29; Sat, 24 Jan 2026 18:46:20 +0000 From: Chris Mason To: "Liam R. Howlett" CC: Chris Mason , Andrew Morton , , , Suren Baghdasaryan , Lorenzo Stoakes , "Pedro Falcato" , David Hildenbrand , "Vlastimil Babka" , Michal Hocko , Jann Horn , , , , , , , Matthew Wilcox Subject: Re: [PATCH v3 11/11] mm: Use unmap_desc struct for freeing page tables. Date: Sat, 24 Jan 2026 10:45:51 -0800 Message-ID: <20260124184555.3936797-1-clm@meta.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260121164946.2093480-12-Liam.Howlett@oracle.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Authority-Analysis: v=2.4 cv=X8df6WTe c=1 sm=1 tr=0 ts=6975137e cx=c_pps a=CB4LiSf2rd0gKozIdrpkBw==:117 a=CB4LiSf2rd0gKozIdrpkBw==:17 a=vUbySO9Y5rIA:10 a=VkNPw1HP01LnGYTKEx00:22 a=yPCof4ZbAAAA:8 a=nrObawGzxuk_COoAWlAA:9 X-Proofpoint-ORIG-GUID: GITbP4S9OHpGmi_jCuU0UxlbrxrvKwyY X-Proofpoint-GUID: GITbP4S9OHpGmi_jCuU0UxlbrxrvKwyY X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTI0MDE1MiBTYWx0ZWRfX3q99NYI7yFEm URREbCwqTH9E/wJRa+SwfPkA739ORfji8LuLRFj8dyKvpXzzZZiJOl6DvYZTFuUZV/A1Kc80h7N Ux8wyWW18NHhKM3yavYOEOvHfXkvhq7NeknPrHGlyTnaSozx0TSz83zqxijd7VbRbwJsygKsXSn q7FaNj++5Q1Y5jwvwDlpWB3dpBQA4BdRA1AnUpmC8UsytUNhpR/1bHqfQLPJjZtoYrpXM+pPsQG P0orOuHlpVEewLBvJ3Bzi6RFutWgZ8pAUcPVVmUE4ZJ7+fFFtPO8uTUO73/BXW6bSAk7gpjCLqv TJ5sO+0Qh9uUGeewWi9yuTKktzmkEzv82+1h/S3biVwaWgoNaBni9H4dYmT4YyNhYOZntumY6hl TIbuh/QmlSm5uz/DkgQIzKKiJnouBFV+UpjsLD+3cmoCla+V0rozH0sjMKjp+PrOizBHCZXt3ZE kcTE3wGxK8YRGIgLkhw== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.20,FMLib:17.12.100.49 definitions=2026-01-24_03,2026-01-22_02,2025-10-01_01 On Wed, 21 Jan 2026 11:49:46 -0500 "Liam R. Howlett" wrote: > Pass through the unmap_desc to free_pgtables() because it almost has > everything necessary and is already on the stack. > > Updates testing code as necessary. > > No functional changes intended. > Hi everyone, I'm running some more aggressive prompts through linux-next and this one was flagged. Apologies in advance if it's way off: > diff --git a/mm/memory.c b/mm/memory.c > --- a/mm/memory.c > +++ b/mm/memory.c [ ... ] > -void free_pgtables(struct mmu_gather *tlb, struct ma_state *mas, > - struct vm_area_struct *vma, unsigned long pg_start, > - unsigned long pg_end, unsigned long vma_end, > - bool mm_wr_locked) > +void free_pgtables(struct mmu_gather *tlb, struct unmap_desc *unmap) > { > struct unlink_vma_file_batch vb; > + struct ma_state *mas = unmap->mas; > + struct vm_area_struct *vma = unmap->first; > > /* > * Note: USER_PGTABLES_CEILING may be passed as the value of pg_end and > - * may be 0. Underflow is expected in this case. Otherwise the > - * pagetable end is exclusive. > - * vma_end is exclusive. > - * The last vma address should never be larger than the pagetable end. > + * may be 0. The underflow here is fine and expected. > + * The vma_end is exclusive, which is fine until we use the mas_ instead > + * of the vma iterators. > + * For freeing the page tables to make sense, the vma_end must be larger > + * than the pg_end, so check that after the potential underflow. ^^^^ The old comment said "should never be larger" but the new comment says "must be larger". The WARN_ON_ONCE fires when vma_end > pg_end, so "must be larger" appears backwards? > + */ > + WARN_ON_ONCE(unmap->vma_end - 1 > unmap->pg_end - 1); ^^^^ On the exit_mmap() path, unmap_all_init() sets vma_end = ULONG_MAX while pg_end = USER_PGTABLES_CEILING. On ARM, USER_PGTABLES_CEILING is defined as TASK_SIZE (around 3GB), not zero. Before this change, exit_mmap() explicitly passed both vma_end and pg_end as USER_PGTABLES_CEILING, so the WARN_ON_ONCE would never trigger. After this change, exit_mmap() uses the unmap struct from unmap_all_init() which sets vma_end = ULONG_MAX but pg_end = USER_PGTABLES_CEILING. On ARM this means: WARN_ON_ONCE(ULONG_MAX - 1 > TASK_SIZE - 1) This would fire on every process exit on ARM systems. Is this intended? > diff --git a/mm/mmap.c b/mm/mmap.c > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1307,10 +1307,10 @@ void exit_mmap(struct mm_struct *mm) > */ > mm_flags_set(MMF_OOM_SKIP, mm); > mmap_write_lock(mm); > + unmap.mm_wr_locked = true; > mt_clear_in_rcu(&mm->mm_mt); > - vma_iter_set(&vmi, vma->vm_end); > - free_pgtables(&tlb, &vmi.mas, vma, FIRST_USER_ADDRESS, > - USER_PGTABLES_CEILING, USER_PGTABLES_CEILING, true); > + vma_iter_set(&vmi, unmap.tree_reset); > + free_pgtables(&tlb, &unmap); The old call passed USER_PGTABLES_CEILING for both pg_end and vma_end. The new code uses unmap_all_init() which sets pg_end = USER_PGTABLES_CEILING but vma_end = ULONG_MAX. This changes the semantics of the WARN_ON_ONCE check in free_pgtables().