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 3DA7ED1A42C for ; Sat, 12 Oct 2024 02:16:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C80726B00B0; Fri, 11 Oct 2024 22:16:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2C0E6B00B2; Fri, 11 Oct 2024 22:16:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF4D56B00B4; Fri, 11 Oct 2024 22:16:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8EC2B6B00B0 for ; Fri, 11 Oct 2024 22:16:25 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 93F19C0E79 for ; Sat, 12 Oct 2024 02:16:19 +0000 (UTC) X-FDA: 82663335846.12.90B3068 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id 7CFB9100007 for ; Sat, 12 Oct 2024 02:16:19 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=PMIcQXZX; spf=pass (imf14.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728699245; 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=drHMGJm5ahLi/V0BeUnf6hUOITulM1J/wwIzvUYv1Dc=; b=Rf2ak0WHaZ2go1RsQTbenZPYBy1rlYFqbesthF2r4fz0BqCYnJelWQde3Lmx13vGGOYTL1 uL1vCs5PBdB0Vuz9eq2o6BdZXI2tToqz7u/+wVpL4LlTVEgKMCrpHviz4d4wzUJqudjkGl cSK5YgoCI5k6ImbMfzxl4bUMbn2CTkg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728699245; a=rsa-sha256; cv=none; b=u7ljMgGZe36twdiJBUdI8y65lP65R0CkDjqK2EQj8lQYSZIdIJuQgo4TCfTNP58GkcAqlp du9dKmOaAbwiiBlvD3GZgkQyBA13Uz0/fEsO0OtJK/0pg9GJ+Yp7JDD8zf0PpaKUCkxiR6 3zoj8hMEObHyTYZ5CpWWTAFfG/1HNfg= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=PMIcQXZX; spf=pass (imf14.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B89A85C5DAF for ; Sat, 12 Oct 2024 02:16:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C08ABC4CECF for ; Sat, 12 Oct 2024 02:16:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728699381; bh=JUodbJ31pdXwG1oR2V7v0TetHTfgjIOpHojdVIma3iI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=PMIcQXZXeQj5qtw0siETa1YY9ZgelydhQU6wpPqNjQ0Gt1Ivy9GYk+dv2G9F8o+TF ybSrG9j44z2r8gNPBy+f50kZIcUU5Le1nf1aFDUb8zXCfvAMI6EawCY1YdtkZo4sq9 3KKPhgPlPzZju7MgGJQhawcYIz9wOlQ5zed6W+QTIEyJfB1hHBmGXpgC4p09JR1VtL dX4F7RMaxyLmP/EC7n4LJXPEIWdhteYhIglD7UBkOrHGqQHFkwRCEawc88g6bAbCcY 5wf9fpgCd4mI3pL2M0nGntQSsGUnDKQ7gUaTe2/sJhk4xmm76AOON6Hyq6Bvt+Ftxp GRtR5x+dWRmOA== Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5c924667851so3047906a12.3 for ; Fri, 11 Oct 2024 19:16:21 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWz7HH0kAr2d25HWvFlzSVQ9yJECrr2qteWcw84pY7UoG7sGrdiqxVvzV+otC9sb5pGe3BG9AOFiQ==@kvack.org X-Gm-Message-State: AOJu0YxW16r920N6drP6HnsrXFIdv04KmTqXXSDyozRt8lmpuZm4PugP 1XzaDQOzT6UT7Hy8Co1cpEwJ+2sG2qOw7iuh6neFqAD/chAV6gYeSKta0mZEBUbhPpQ//+Ubk+q G4zFxZtrhLD472UdNbWDAfi3ignI= X-Google-Smtp-Source: AGHT+IHuFRnnHrrgkM7pYwKUrgWiOtG7kV+p2T7XJp2djiBQ20CmZvBlI9kbC33qte/eEVLx+BBS1FsMPLaHGiB9gJA= X-Received: by 2002:a17:907:940c:b0:a8d:29b7:ecf3 with SMTP id a640c23a62f3a-a99b930e9d1mr358486566b.13.1728699380354; Fri, 11 Oct 2024 19:16:20 -0700 (PDT) MIME-Version: 1.0 References: <20241010035048.3422527-1-maobibo@loongson.cn> <20241010035048.3422527-5-maobibo@loongson.cn> In-Reply-To: <20241010035048.3422527-5-maobibo@loongson.cn> From: Huacai Chen Date: Sat, 12 Oct 2024 10:16:07 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/4] LoongArch: Use atomic operation with set_pte and pte_clear function To: Bibo Mao Cc: Andrey Ryabinin , Andrew Morton , David Hildenbrand , Barry Song , loongarch@lists.linux.dev, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7CFB9100007 X-Stat-Signature: gg47m4w5fu61jpoe5b9ng7y4hy443cyx X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1728699379-133558 X-HE-Meta: U2FsdGVkX1/VeixgTpKw9eFXpUGTsZ6FNXcPwXNMoEcxRDBUsP8RFojOCccf99DCYCLFnUouiiq8dbC9NNSBQdN/TZ+rmvqF06n3i9x1f5e2d+dFpnWI2qMVKvHsFBDadsVatGLptvPeK82YcHg4I8YkNn0ukTqUvbhBqt++6x9YWqTSz3UCfd7IVkgrC49sj+xQtgYEMPz9cePPQ4Lm7NuR9fLiJ45BI3LEOl4lWTl9j83OY5VFIrrGRc1kyj/LUt7Hu4p//KqviT0Kx6x+bw3GDLHhSXRqcc2tLgU+4mfRkSfB1uBwvbKLEyMIlrMOz4i6h122JT09t9qLzDdwCQllYxhQhbXRAcVi+cvtfxxsQqEpxvOYBvses0v0nt4OaM4DzFy75JRKT2nnSPGs+GHd++WZ7ZfpDhuQEYoPYPzH54WlIMDYzxQa8gtnh96ZzSuhCJtTWKlTjsdmFCtPgVfy+Hh+qxEJUmB/FA2x24I90/inMFFL2bJKRFesqPXJU6pSoXpfEoRvYPZW1vo6Y/A9f5JP5iUIAAQ6K5tPqz/owBLKoNyr7xRL8EKcjBCQZ0O3DwCHuJWDcelvPS5i4rXxNgG2ZMx0d3kGkzjxJ2jKFk7mEKbv/cmhPhB7WTEGvvLNwTVOnsqRqOd8XDSP8tshtIHcj+dSoXJnEDsfZIA738v5RxngTvuVEt+5hkdA+xnsMgsUVbtLgbb6v4RHhOzVvkChAnisnbqt/utDiD392lPYo5oalM0I9c4U+lqW7U7bu/wBKpbnJTLKXgqb1fOgqgsR7IKRd575eBpqE5IOIsUZZ8Jf+uj/ygkYCyaO34ayga5r+EfLnJbNe+PKjyvSe9zbZ6i6BrssoXGxh9Etp+RBwgTe2j2fpX91uS9x0fLEqUo2b1/kzP7o29uKSaGdvGsfDB96yIILbqJrKfgocTfZAhZV25oJkYoPnaqIKTnNN7/SNCtUlbAgHMZ JnnpdTgM +PNt7pB7YSXwXRSq7q5XUUoDvaK0QxF2enMAyzkQJGSJTMITbo+yg/A1SjVNCZXRuuy7yu5CL0LwCru39Eliz+UVvC3xEwSuk1Dki24ptKwtFgKyuO5V7czhLJXK1THo/CUvM7IfTGArfOIC3Oph2D1JMrsVfmeN6PE0gZXua8aK/sbM5x1z6swKQRHlkPnvC/3tw5Fn6ZCoKsdfmFhmNgETqb7jFFP72bpdQoRNQ1OT0yvmg/Tk2gJbQL9LoU6nKyR0l1e2yavt9wDT6X2TyfkmQCa0PqOBFYfahwjYe2KwyB41+TIb26XrLx59wFs6tF1f9TSoJCr06U6p74ses/mA1mEUe4hoYLtTELrP1UOGqETYnRdkCn+mDFqoXSzS2YWne1xkn4J3Z05PuPuOh99tcmw== 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: Hi, Bibo, On Thu, Oct 10, 2024 at 11:50=E2=80=AFAM Bibo Mao wro= te: > > For kernel space area on LoongArch system, both two consecutive page > table entries should be enabled with PAGE_GLOBAL bit. So with function > set_pte() and pte_clear(), pte buddy entry is checked and set besides > its own pte entry. However it is not atomic operation to set both two > pte entries, there is problem with test_vmalloc test case. > > With previous patch, all page table entries are set with PAGE_GLOBAL > bit at beginning. Only its own pte entry need update with function > set_pte() and pte_clear(), nothing to do with buddy pte entry. > > Signed-off-by: Bibo Mao > --- > arch/loongarch/include/asm/pgtable.h | 44 ++++++++++------------------ > 1 file changed, 15 insertions(+), 29 deletions(-) > > diff --git a/arch/loongarch/include/asm/pgtable.h b/arch/loongarch/includ= e/asm/pgtable.h > index 22e3a8f96213..4be3f0dbecda 100644 > --- a/arch/loongarch/include/asm/pgtable.h > +++ b/arch/loongarch/include/asm/pgtable.h > @@ -325,40 +325,26 @@ extern void paging_init(void); > static inline void set_pte(pte_t *ptep, pte_t pteval) > { > WRITE_ONCE(*ptep, pteval); > +} > > - if (pte_val(pteval) & _PAGE_GLOBAL) { > - pte_t *buddy =3D ptep_buddy(ptep); > - /* > - * Make sure the buddy is global too (if it's !none, > - * it better already be global) > - */ > - if (pte_none(ptep_get(buddy))) { > -#ifdef CONFIG_SMP > - /* > - * For SMP, multiple CPUs can race, so we need > - * to do this atomically. > - */ > - __asm__ __volatile__( > - __AMOR "$zero, %[global], %[buddy] \n" > - : [buddy] "+ZB" (buddy->pte) > - : [global] "r" (_PAGE_GLOBAL) > - : "memory"); > - > - DBAR(0b11000); /* o_wrw =3D 0b11000 */ > -#else /* !CONFIG_SMP */ > - WRITE_ONCE(*buddy, __pte(pte_val(ptep_get(buddy))= | _PAGE_GLOBAL)); > -#endif /* CONFIG_SMP */ > - } > - } > +static inline unsigned long __ptep_get_and_clear(pte_t *ptep) > +{ > + return atomic64_fetch_and(_PAGE_GLOBAL, (atomic64_t *)&pte_val(*p= tep)); > } > > static inline void pte_clear(struct mm_struct *mm, unsigned long addr, p= te_t *ptep) > { > - /* Preserve global status for the pair */ > - if (pte_val(ptep_get(ptep_buddy(ptep))) & _PAGE_GLOBAL) > - set_pte(ptep, __pte(_PAGE_GLOBAL)); > - else > - set_pte(ptep, __pte(0)); > + __ptep_get_and_clear(ptep); With the first patch, a kernel pte always take _PAGE_GLOBAL, so we don't need an expensive atomic operation, just "set_pte(pte_val(ptep_get(ptep)) & _PAGE_GLOBAL)" is OK here. And then we don't need a custom ptep_get_and_clear(). Huacai > +} > + > +#define __HAVE_ARCH_PTEP_GET_AND_CLEAR > +static inline pte_t ptep_get_and_clear(struct mm_struct *mm, > + unsigned long addr, pte_t *ptep) > +{ > + unsigned long val; > + > + val =3D __ptep_get_and_clear(ptep); > + return __pte(val); > } > > #define PGD_T_LOG2 (__builtin_ffs(sizeof(pgd_t)) - 1) > -- > 2.39.3 >