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 303C8C61DB2 for ; Fri, 13 Jun 2025 08:55:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AA8B6B0089; Fri, 13 Jun 2025 04:55:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 95B536B008A; Fri, 13 Jun 2025 04:55:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8986E6B008C; Fri, 13 Jun 2025 04:55:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6B7726B0089 for ; Fri, 13 Jun 2025 04:55:14 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D481F8156B for ; Fri, 13 Jun 2025 08:55:13 +0000 (UTC) X-FDA: 83549768106.05.8EC66D0 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf28.hostedemail.com (Postfix) with ESMTP id A01E8C0008 for ; Fri, 13 Jun 2025 08:55:11 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jZQqOHzX; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="CM/ltyGK"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jZQqOHzX; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="CM/ltyGK"; spf=pass (imf28.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749804912; h=from:from:sender: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=c5y82HogrTTA90h0Vyr5go8d6/BO1h3781RVLmsOTU0=; b=x7bBXu8Bhg0lHHheb5xLOYc4OwNvef4bHaluKv83PajTbRDgvPDK7Lhb13iEhJqF+R+L+H ur4EQGSrjSil4AaU/kn+bZK+4LTtVs324fIunMNSABztIFAffOG/nR7dgpCFHNveRGDVXu s54U3A4ieha4oQoWdiqviw+LgZ51zaA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749804912; a=rsa-sha256; cv=none; b=R4ul2WC7ZG+IQET1c5nQZYBY77B71BFkbMjDrSVZum1iFK8tHjQrEBxICRHYioQFiT4ypO OiPztXYKryKdJnvK5iwzQqPjQIi4b9pq79oQZoGACBJh5NB905euCWT76kzJt/EbUGxRfy w9yZS1N6bXUKgSWjdecIvxzoVvhNXRc= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jZQqOHzX; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="CM/ltyGK"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jZQqOHzX; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="CM/ltyGK"; spf=pass (imf28.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 258931F84C; Fri, 13 Jun 2025 08:55:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1749804910; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=c5y82HogrTTA90h0Vyr5go8d6/BO1h3781RVLmsOTU0=; b=jZQqOHzXE7Z/b2l5VdMpSHZkRX7AWce+zrGWHs8KJjilmOLRIg0hjtSwEQZjGXMwzVALR6 x44DzXbcxKkRKn1VZEOarU1o40Ftgi5QtZkLi8O4XO9stDobc9B/PbQmVFHdhPoRHLher8 BkI+RD0KLhCKEpkyAcJtbZUrGXjqs0I= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1749804910; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=c5y82HogrTTA90h0Vyr5go8d6/BO1h3781RVLmsOTU0=; b=CM/ltyGK/xwKApDFgjj3C+NIEGaVLtm0q6+kmIJ7LfRHhFYXR/rrGS+mdB5y0YxK+EzkCT IcPSrPCCCWG/ZzBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1749804910; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=c5y82HogrTTA90h0Vyr5go8d6/BO1h3781RVLmsOTU0=; b=jZQqOHzXE7Z/b2l5VdMpSHZkRX7AWce+zrGWHs8KJjilmOLRIg0hjtSwEQZjGXMwzVALR6 x44DzXbcxKkRKn1VZEOarU1o40Ftgi5QtZkLi8O4XO9stDobc9B/PbQmVFHdhPoRHLher8 BkI+RD0KLhCKEpkyAcJtbZUrGXjqs0I= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1749804910; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=c5y82HogrTTA90h0Vyr5go8d6/BO1h3781RVLmsOTU0=; b=CM/ltyGK/xwKApDFgjj3C+NIEGaVLtm0q6+kmIJ7LfRHhFYXR/rrGS+mdB5y0YxK+EzkCT IcPSrPCCCWG/ZzBQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A6E0313782; Fri, 13 Jun 2025 08:55:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id omoWJm3nS2jtMQAAD6G6ig (envelope-from ); Fri, 13 Jun 2025 08:55:09 +0000 Date: Fri, 13 Jun 2025 10:55:08 +0200 From: Oscar Salvador To: Andrew Morton Cc: David Hildenbrand , Muchun Song , James Houghton , Peter Xu , Gavin Guo , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/5] Misc rework on hugetlb_fault Message-ID: References: <20250612134701.377855-1-osalvador@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250612134701.377855-1-osalvador@suse.de> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: A01E8C0008 X-Stat-Signature: 18qfjqsjsnrfzj76a3fy5xe4udatm51a X-HE-Tag: 1749804911-233012 X-HE-Meta: U2FsdGVkX18rWxIAxWtdDixS8ubNUinEkn6bXNvANSZo0MswYMsYbFC+89rLH/K5k7TiW5B/z5JnimgpnZRiCRwKyHcWUGYzlaJZSROisOM+ahrakZLzDm2imutJOcRSMs+VZ4/hv8CHRL1XuofClEs9a40Tz/jhSPqTWSWjZ47vJq1B4Wx3dOFJnshyQeiqfjcZbteBZSRXGSwJMEvqq5mTWMbO+z0gqknyFWUvFvfN4+b+LS4uMTTlMIiC5fYcwL3K6y00+aBMfevt/NgV14edGJH8mD0P+lOnEwXn7JSC4Cu3Bo6TPig8MS2CR//capS6czOCNfkOhvsnwK/STaRDy9xFQh1yr53iFYmRqVFS4WR4hb9o2C2iyVhnK61+PwZEgY/JURAcBkhQ+moDbIOGsXSiD+XL7nvdqoSGp7n7AHYzeTRq1h5rDfenkmJtrc6/oWWlA9v4waj0F8TDBVEaea9+HuALR+ZROdWgMIeEFeACq1sfSiqR7ZfyC8OQHT7PZM29BR8TevPM/0D1OslQXIRfL2K8qlzQ248bIb1D3R7Hz29prjRqdPlVO0PERD1QJucOgMicAgAmKf/JNHYEeR0wGb3cSmjwKx+E3vy9JGwnEODoGmA31tli+ttvctVYHAy50Ti9jbos0kAyty5as80C/NZK7S/Y2XCzzGeK9RboBDOs1LeYZd3DdzrAS6lc/O8f3WtNM2kNdWJyNmZgfbklgaf1632ZDfAxwpH+Gj64IOQ2GrXfh9Yie+7poahFdVffg6it3ew5n1u8BC2vXE6ilANL/LUliN4ddu16kmoGkMNKUDXcL4Zfy/3gsaE9S2fcJ58bhikvWCZaTmujmo+PcqLi5UCOkgMPC7OBVe3JQQj3VqYoaedWF/B1KSRZxe+TefksJKsFvOHdES9oo5cdz/bh7WBYOhH2HTzaYH3in0W25zSPW/3lTx3TVsbVHGXiCAx/s+lGwC/ w5iQiFdv g7R9xxOiXjzF3z5vSSEkm62ggCHKAQB6B5Bh5+TncCDog9cnFjjSalVqP7ywb//c0Ozj4PcdWOFbvoCsHDc2JEiih3AKuHBRNMjMTezmVRFq1l8EIHqsXNKcF5Gnfx4qPW+s8hbrsEwO3ga7RJvKz6tQwlqWkJJv7KOo5qrou+NhD5iCpJVsGJJ2M3mo7AqDDN0adJjxw5pQv/59rxQkDykeCrfdyE5utezj1VtczS6xc4tZfJHRzGYTS6SbTergmAUais67EWWIijI1N76LDeAHU8kFvXICuoXnQfP5cEdWeH8SE43hM00XtTUYADYFzX2mSTSx0IUQG22UHPB5EDq6jPO+C/S1J2uNKfN8U8xf+SnPno0hEC5s6EqRPdFbBxtJNeF4EfxBw34Y= 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 Thu, Jun 12, 2025 at 03:46:56PM +0200, Oscar Salvador wrote: > This is a new version of the RFC I sent a couple of weeks ago [1]. > It's the conclusion of the discussions that ocurred in that thread. > > Patch#1 is the fix for the deadlock. > Patch#2 is to document why we take the lock, so none of us have to spend > time again in figuring that out. > Patch#3-5 are a bit of cleanup (removing obsolete comments etc.) Andrew told me that this is very vague for a coverletter, and while this patchset is sort of a refactor/clenaup/fixup mix, I acknowledge that it is far from optimal to get people some context. So let me try again, and I apologyze. " This patchset aims to give some love to the hugetlb faulting path, doing so by removing obsolete comments that are no longer true, documenting in a clear way the reason we take certain locks, and changing the mechanism we use to determine whether we are COWing a private mapping already. The most important patch of the series is #1, as it fixes a deadlock that was described in [1], where two processes were holding the same lock for the folio in the pagecache, and then deadlocked in the mutex. Looking up and locking the folio in the pagecache was done to check whether that folio was the same folio we had mapped in our pagetables, meaning that if it was different we knew that we already mapped that folio privately, so any further CoW would be made on a private mapping, which lead us to the question: __Was the reservation for that address consumed?__ That is all we care about, because if it was indeed consumed and we are the owner and we cannot allocate more folios, we need to unmap the folio from the processes pagetables and make it exclusive for us. We figured we do not need to look up the folio at all, and it is just enough to check whether the folio we have mapped is anonymous, which means we mapped it privately, so the reservation was indeed consumed. Patch#2 follows a bit more to the trend on why we need to lock the folio from the pagetables, whether it is anonymous or not. For anonymous folios we need the lock in order to check whether we can re-use exclusively for us, while for file folios we need to hold the lock to make the folio stable throughout the copy. We also hold it even if we are read-faulting, just to make sure it does not go away. For this last case, we are already covered by the hugetlb_mutex, but in order to bring hugetlb closer to the general faulting path, let us rely on the lock instead, as do_read_fault() does. Patch#3 is a merely correctness issue if you will, while Patch#4 and Patch#5 remove obsolete comments and assumptions that are no longer true. [1] https://lore.kernel.org/lkml/20250513093448.592150-1-gavinguo@igalia.com/ " Shame on me, this should have been the cover letter. -- Oscar Salvador SUSE Labs