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 0F99EC3DA49 for ; Fri, 26 Jul 2024 08:18:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C7F46B008C; Fri, 26 Jul 2024 04:18:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 977BE6B0095; Fri, 26 Jul 2024 04:18:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83F856B0096; Fri, 26 Jul 2024 04:18:55 -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 644E76B008C for ; Fri, 26 Jul 2024 04:18:55 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 15E4C12173B for ; Fri, 26 Jul 2024 08:18:55 +0000 (UTC) X-FDA: 82381203030.03.818B44F Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) by imf15.hostedemail.com (Postfix) with ESMTP id 12A6AA0008 for ; Fri, 26 Jul 2024 08:18:52 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Yas2g6wg; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf15.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721981893; a=rsa-sha256; cv=none; b=OpK6sITL36MKgem8cjJmpGPU0RFuI5hmMxzyVxVeNDw99ycjNDturcAD1cmGm7sDjQwyyf coIkiUNNbWRHanYLtK+vAwBwPijzzLEXoDPsjCv+UEE2xsVW5uKfZfL0ur8lDb/Wa8ilYy 4+eNaCegddjdgTPdW4S2BPvON6NRP5g= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Yas2g6wg; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf15.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721981893; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gZawXqEBSOKq3l+x6lvnCzwSP/j4q0qgw21LwxEow6w=; b=p9apbqYOZQOjfQeQBrEtgxAAovDSnhReTaljYA8DbjhSTP6HmZRRhE+BoY+3kYPVfsn9Xi Fiu1N9AGpWT61ftaHHa4HAj6/KLELOxGkpJ0kXLck2fNrrv9KxTiI0DYSqzUqGJKPhQ43h /DQca+a8pXxR+tErz4ZGGGWBNg21aJE= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1721981930; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gZawXqEBSOKq3l+x6lvnCzwSP/j4q0qgw21LwxEow6w=; b=Yas2g6wg3Wuakf0TbRE0f6Ed8D4npM9i6I0tlobXpVQtXYaNXSUJVldh1h0kP0+xedybnU c03DY50+fI7KoUYlpAcQDC47BZTNJLAkKPYWmXK5KpJp+OOPwy0zkK5a5gVyfv22C98Auy e5sNYHvLqIpdWCEHCFZn1u/IllksfZI= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [PATCH v1 2/2] mm/hugetlb: fix hugetlb vs. core-mm PT locking X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20240725183955.2268884-3-david@redhat.com> Date: Fri, 26 Jul 2024 16:18:06 +0800 Cc: LKML , Linux Memory Management List , Andrew Morton , Peter Xu , Oscar Salvador , stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20240725183955.2268884-1-david@redhat.com> <20240725183955.2268884-3-david@redhat.com> To: David Hildenbrand X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 12A6AA0008 X-Stat-Signature: qspnxe6mkxaxprxbysjnk81y55udscii X-Rspam-User: X-HE-Tag: 1721981932-675876 X-HE-Meta: U2FsdGVkX18Oo6kMBeNsSN+koT8XXKKZrgVmLH01sX9Dt46Ju1Z9OxiBj47EA+nhEov3CYWYC2SJ8WcTeqRAJ8aQu90ydPK4qGvWLLGsbqCmS+UDdPvREAIsUnImweEKpQnKZ61Cc6GUfhgX8ktAYQWw9l+2J8NH+vRVmRWdPvE/ttOctqp0yio+Ol1xUzHzZrAZaIF277occSSX8sH4r6RFFRYpcnU7HY9OAtMyNRQj0Q/2AV5IQakJxs69A9KHg1FPjmFwUffh7iTSN0pQXIRA4ZMc+W2NbgId3vNNdVZvSMIaVoz3LWAdAq8H8aPfiCnmRzjxDp0G4MEgn3f5kAY1rfYdH5CBXmn0/jIgiShbn4MM4p3C1OLkSZq/NUqG8jTU6DGwqsXJolx1Izld6c1TR6I8HcDqq7bXuelEA8FNFxv65bcdLvIn3Jkfy4ou1Eu/F3WQm9Er+kFlMFGyG8Yg4xm3YDz0vylT8L6afTpwTSUFHvFcwIz8MYm7CPaXXqnfDQ+bQi6XYSnBPWuInrbWaobjMBi9Sn5y1axMIutWvdC4ejAjZzFaIlxpsVnR3/bkG5Vy8vmBQiH+XFv2IAqAzUqB8u7lwfusEE4jMD6/wfjvP7a0Vrfi5e57F2r9YlGYSBUzMulLxgvdwKzzEKbkeR1UhTXw32N3BSWEVvuwWPGn2VQWy6fOmDl91pcD6EyXMui8q2tqot5epF4XG32i2htUdsHomqptZ63EUgma7gExdC9rY/o87K+iTpb+FWy3lZVIBLFuZHEoN4FG/hV5ON0wLVhVED8xwfIMr7DzhQ8v3W+m8vBBJ+hG+zNbXEKRHhOLEaCsNKe9k7RRYXrhTHMPLrqyVq0RH8hXAcPfGFbGbr43F+YyA+s4jR9eILzwBF5NOD+L07hx+HkWKX6SAf/EfPosf4hJgB6L9IGdHtT44rNERUvchovE5uWvkxTu/+7iebN3GiJXTyH smc3sME3 9fAjWabGazBqU/QlucT+upz6ACzc2ENfx9ScEDkpxObc+dTbcCv7DDWEbtcyUPSp3jbrqUBnsgZVUD+jJ4JpVA1kt1JglsTi6liW2f4sW/aOexoecdBJbWKIhmWwTt9k2eAQutEQ7fksZTSImq2+ucRQbAyswFcXaazBauJfGN4IBnUWOiZvLD6vhqgzgqRkxeIaNTiPEocP8xx7XRvgG1GDyLBRydfWbUMwz 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 Jul 26, 2024, at 02:39, David Hildenbrand wrote: >=20 > We recently made GUP's common page table walking code to also walk > hugetlb VMAs without most hugetlb special-casing, preparing for the > future of having less hugetlb-specific page table walking code in the > codebase. Turns out that we missed one page table locking detail: page > table locking for hugetlb folios that are not mapped using a single > PMD/PUD. >=20 > Assume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB > hugetlb folios on arm64 with 4 KiB base page size). GUP, as it walks = the > page tables, will perform a pte_offset_map_lock() to grab the PTE = table > lock. >=20 > However, hugetlb that concurrently modifies these page tables would > actually grab the mm->page_table_lock: with USE_SPLIT_PTE_PTLOCKS, the > locks would differ. Something similar can happen right now with = hugetlb > folios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS. >=20 > Let's make huge_pte_lockptr() effectively uses the same PT locks as = any > core-mm page table walker would. >=20 > There is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb > folio being mapped using two PTE page tables. While hugetlb wants to = take > the PMD table lock, core-mm would grab the PTE table lock of one of = both > PTE page tables. In such corner cases, we have to make sure that both > locks match, which is (fortunately!) currently guaranteed for 8xx as = it > does not support SMP. >=20 > Fixes: 9cb28da54643 ("mm/gup: handle hugetlb in the generic = follow_page_mask code") > Cc: > Signed-off-by: David Hildenbrand Acked-by: Muchun Song Thanks.