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 A5AF9C7115A for ; Thu, 19 Jun 2025 11:52:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3726D6B0092; Thu, 19 Jun 2025 07:52:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 323566B0093; Thu, 19 Jun 2025 07:52:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 212476B00A2; Thu, 19 Jun 2025 07:52:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1075C6B0092 for ; Thu, 19 Jun 2025 07:52:17 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9A2FF80E4C for ; Thu, 19 Jun 2025 11:52:16 +0000 (UTC) X-FDA: 83571987072.29.D17CB09 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf18.hostedemail.com (Postfix) with ESMTP id 88AA31C000C for ; Thu, 19 Jun 2025 11:52:14 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=XSltles4; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Dv2KOgK5; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=XSltles4; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Dv2KOgK5; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf18.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=osalvador@suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750333934; a=rsa-sha256; cv=none; b=jEWKkeljuSDo5uNW/RXRDTtcIzTF7CJqPZDwcujNz+Po5VNYwICf7S+cvHRs2nkO+0S+dm wFPmDLaMr8OAMV9/0Kqe+mnfNCAHsKKFWq4LIi2pcvv/LNQQGb0SNbI3U1x0DOIMi0/9qC 0hFFJGEslplqCG5ALZPstweTaMSK3/A= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=XSltles4; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Dv2KOgK5; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=XSltles4; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Dv2KOgK5; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf18.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=osalvador@suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750333934; 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=gkbnI9M3+7/OCj+8WkZJ9wTg9dHnjACBL27tJy9YeR4=; b=Bb7O/bYs90MFpZaHiXJB6Xg3BsX0tZ+MZ+/8ZXsnm100hkpG7E9Wo3vyKRA38P6CX7RJh2 tz7NW56udbarhQfdvPjJEWUCdGOdQCqfOWJwKWI0N1tPfAP0zOJXsE5s3jDDNzz4fhMWYY TTt9E+rAJ4vWC8IidxMergpmt60Jddc= 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 84AEF1F38D; Thu, 19 Jun 2025 11:52:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1750333932; 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=gkbnI9M3+7/OCj+8WkZJ9wTg9dHnjACBL27tJy9YeR4=; b=XSltles4LDH0Wdek1UJs4MI/f58R4PWbxs/T3EBZ3M7ej4zF+hp/Fnueg8WuSUgCz0/MFZ YkEv37GuqS0Bluns3XK7Z1JAcnGI7KlK1pp9eZoQ2Tf6ZYrWOgXnxhoQfQ1EfTqaRMxBNT o+r6SKd+HwOnzNpWonhrlNcY0pHluAc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1750333932; 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=gkbnI9M3+7/OCj+8WkZJ9wTg9dHnjACBL27tJy9YeR4=; b=Dv2KOgK5kp3kHgc6sivpwt8ndfJI1bzsQqesqdyNgbhD4/sO0IoIAs/8HLe7BkwiTNhg4z LCWFZe1GwlYVo+Dw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1750333932; 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=gkbnI9M3+7/OCj+8WkZJ9wTg9dHnjACBL27tJy9YeR4=; b=XSltles4LDH0Wdek1UJs4MI/f58R4PWbxs/T3EBZ3M7ej4zF+hp/Fnueg8WuSUgCz0/MFZ YkEv37GuqS0Bluns3XK7Z1JAcnGI7KlK1pp9eZoQ2Tf6ZYrWOgXnxhoQfQ1EfTqaRMxBNT o+r6SKd+HwOnzNpWonhrlNcY0pHluAc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1750333932; 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=gkbnI9M3+7/OCj+8WkZJ9wTg9dHnjACBL27tJy9YeR4=; b=Dv2KOgK5kp3kHgc6sivpwt8ndfJI1bzsQqesqdyNgbhD4/sO0IoIAs/8HLe7BkwiTNhg4z LCWFZe1GwlYVo+Dw== 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 E36FC136CC; Thu, 19 Jun 2025 11:52:11 +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 t8jXM+v5U2g6cgAAD6G6ig (envelope-from ); Thu, 19 Jun 2025 11:52:11 +0000 Date: Thu, 19 Jun 2025 13:52:10 +0200 From: Oscar Salvador To: David Hildenbrand Cc: Andrew Morton , Muchun Song , James Houghton , Peter Xu , Gavin Guo , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/5] mm,hugetlb: Document the reason to lock the folio in the faulting path Message-ID: References: <1297fdd5-3de2-45bc-b146-e14061643fee@redhat.com> <11a1d0f7-ef4e-4836-9bde-d7651eebcd03@redhat.com> <3eb8e1e2-5887-47ed-addc-3be664dd7053@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: paniximy9cmrb67a7na9cxsgis4fghdp X-Rspamd-Queue-Id: 88AA31C000C X-Rspamd-Server: rspam02 X-HE-Tag: 1750333934-565405 X-HE-Meta: U2FsdGVkX1+kt9yFbmgaGI3JpfbcRBmAdda49XycfSaRQf0uGKTWE3ln4IGjc4IYWH/BAPXMpvpza1JKCRt3gaoqpw//ArhjQVmYHoeL4/OKy462ocfYPs2iyaEodXltf7E/afaGhOfsFj/b/RTcvhPJp9UxadmNyT81MmJjgiP9WKq4YMfpBcwV6M1ZS7FbTzBT809IoKsOux6xJShg+aAURHRLexb40+MrNV901N04IsXTZxEcUKgh+qYZWrjC+EzEJJ6fe0/PBf9BVZsdYnsU1eu9tNGLJeDDh4E8MQG8XkkPX/zNo1xRxHjfsqJCZNlQzRnwd/YQfoxQXvw/0yo1gWlUfXfL8K/2/kr0LnAv/xFQrFDDSnTr90DkXJVJX9zknhMA2aalXJAW+m9s8BMOHzH56svOpmzIm+mJYoAb9JDrPCR+ccvY30vRSG/dQ0tXwFr0Xj3jdH7VNr9B90YW3U0MvZHZBCcS4yCvy0/iH3NZT7fW3NKSUkayShmDJqjZhKyDUD22gDcrlL4ET9hyCsLZ7zLq+gcmfvkdnYbkvOWj+dLXMwMOSEygsXW6ZT4nCVeyGsIPYZomujEZzt6EMCH/PHGxHxFjPNxI9kmNTQmlqUjmgEtywmm8DfyQPjYAk7f3SQj2cAWN4tGvkj884rOILZbxJfePmqmughF20KagBsQkvxWr5PvehWg9JYZzQ9eUg9CRmGn9vUTG2Kn0MfA11zqXSV5ASdYUeAEzhhNxZOs59FQed1DvX3U4vsOMHvuliGviXgMYxr/PhSZl7LfF2uosKs0iI6Yrr1HHT0x3ZH209vkR3a49KyVMIjmM63y1ltfQ7VtOqzbNDIbXizkohiMJk78FcW+QBn26r2t7Srxnw/zZtsIKzgiMpE9G+l8cEJ4c9ShKm8goL/tQNjGdsSrY 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 Tue, Jun 17, 2025 at 03:42:09PM +0200, David Hildenbrand wrote: > Yes. As an alternative, keep locking it in the caller and only unlock in the > !anon case? This is what I came up with: What do you think? I just made sure that all hugetlb-LTP tests pass fine (after I fixed an obvious mistake :-S) From 3a0c53a00511abdcf5df53491bbb9295973f24f9 Mon Sep 17 00:00:00 2001 From: Oscar Salvador Date: Wed, 11 Jun 2025 10:05:34 +0200 Subject: [PATCH] mm,hugetlb: Sort out folio locking in the faulting path Recent conversations showed that there was a misunderstanding about why we were locking the folio prior to call in hugetlb_wp(). In fact, as soon as we have the folio mapped into the pagetables, we no longer need to hold it locked, because we know that no concurrent truncation could have happened. There is only one case where the folio needs to be locked, and that is when we are handling an anonymous folio, because hugetlb_wp() will check whether it can re-use it exclusively for the process that is faulting it in. So, pass the folio locked to hugetlb_wp() when that is the case. Suggested-by: David Hildenbrand Signed-off-by: Oscar Salvador --- mm/hugetlb.c | 43 +++++++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 10 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 175edafeec67..04049d0fb70d 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6437,6 +6437,7 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping, pte_t new_pte; bool new_folio, new_pagecache_folio = false; u32 hash = hugetlb_fault_mutex_hash(mapping, vmf->pgoff); + bool folio_locked = true; /* * Currently, we are forced to kill the process in the event the @@ -6602,6 +6603,11 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping, hugetlb_count_add(pages_per_huge_page(h), mm); if ((vmf->flags & FAULT_FLAG_WRITE) && !(vma->vm_flags & VM_SHARED)) { + /* No need to lock file folios. See comment in hugetlb_fault() */ + if (!anon_rmap) { + folio_locked = false; + folio_unlock(folio); + } /* Optimization, do the COW without a second fault */ ret = hugetlb_wp(vmf); } @@ -6616,7 +6622,8 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping, if (new_folio) folio_set_hugetlb_migratable(folio); - folio_unlock(folio); + if (folio_locked) + folio_unlock(folio); out: hugetlb_vma_unlock_read(vma); @@ -6636,7 +6643,8 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping, if (new_folio && !new_pagecache_folio) restore_reserve_on_error(h, vma, vmf->address, folio); - folio_unlock(folio); + if (folio_locked) + folio_unlock(folio); folio_put(folio); goto out; } @@ -6670,7 +6678,7 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, { vm_fault_t ret; u32 hash; - struct folio *folio; + struct folio *folio = NULL; struct hstate *h = hstate_vma(vma); struct address_space *mapping; struct vm_fault vmf = { @@ -6687,6 +6695,7 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, * be hard to debug if called functions make assumptions */ }; + bool folio_locked = false; /* * Serialize hugepage allocation and instantiation, so that we don't @@ -6801,13 +6810,24 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, /* Fallthrough to CoW */ } - /* hugetlb_wp() requires page locks of pte_page(vmf.orig_pte) */ - folio = page_folio(pte_page(vmf.orig_pte)); - folio_lock(folio); - folio_get(folio); - if (flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) { if (!huge_pte_write(vmf.orig_pte)) { + /* + * Anonymous folios need to be lock since hugetlb_wp() + * checks whether we can re-use it exclusively for us in + * case we are the only user. + */ + folio = page_folio(pte_page(vmf.orig_pte)); + folio_get(folio); + if (folio_test_anon(folio)) { + spin_unlock(vmf.ptl); + folio_lock(folio); + folio_locked = true; + spin_lock(vmf.ptl); + if (unlikely(!pte_same(vmf.orig_pte, huge_ptep_get(mm, + vmf.address, vmf.pte)))) + goto out_put_page; + } ret = hugetlb_wp(&vmf); goto out_put_page; } else if (likely(flags & FAULT_FLAG_WRITE)) { @@ -6819,8 +6839,11 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, flags & FAULT_FLAG_WRITE)) update_mmu_cache(vma, vmf.address, vmf.pte); out_put_page: - folio_unlock(folio); - folio_put(folio); + if (folio) { + if (folio_locked) + folio_unlock(folio); + folio_put(folio); + } out_ptl: spin_unlock(vmf.ptl); out_mutex: -- 2.49.0 -- Oscar Salvador SUSE Labs