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 D5151CF259D for ; Mon, 14 Oct 2024 06:33:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4BE926B0083; Mon, 14 Oct 2024 02:33:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 46DAD6B0088; Mon, 14 Oct 2024 02:33:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 334B66B0089; Mon, 14 Oct 2024 02:33:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 15ED46B0083 for ; Mon, 14 Oct 2024 02:33:40 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 785B91C5538 for ; Mon, 14 Oct 2024 06:33:31 +0000 (UTC) X-FDA: 82671241632.22.8E5FB25 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 981FA140005 for ; Mon, 14 Oct 2024 06:33:33 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=inT2a268; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728887462; 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=dHL7qSQDr4q3t54MX6F81H3RUEf2/M8zrpm3YnELdw8=; b=zUSPMqScYDeTliC09RdkztgbV9egmTYwZDbNA7gVGpeJMIebh7ZuyxDo35Geyw/4oug6mP Ka9Wzt6nIFpHKAmQ9mCDmB1SbXq1j1bxIsxa3MS9u1TGqXptCvRs/o4eS9siK0jTEhswsQ vFqiV82Hr4cG/1WrfeZjpjzjfi/Py1w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728887462; a=rsa-sha256; cv=none; b=OaAvdDIYDAc5KrJth9fkXzDNFCtBRtXhQyE2IP0huYdBoFpr1sQbqpoOOi2xD7ctK2JlXx cHq2rdnuuE0XrZozaFtOqX/dXkMo2Cu1DG3/92ntZYquxVkmfm1+/D4ppUaDGw5yeslgzI KtcftF1bX8CLUl5N66ghr/BX6j6tLQU= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=inT2a268; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CB7085C5A3D for ; Mon, 14 Oct 2024 06:33:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E21EAC4AF09 for ; Mon, 14 Oct 2024 06:33:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728887616; bh=1vFIJKT9gpEeD+/OKW1YiSfLCdrShPFpH5UoS6vW8VU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=inT2a2682JG1bWQrfgQodr9TTrAksApY4Za0ZtA4CXwtkC7P0SBrQz3pmvzxddajk BeSLzkg07RJZDkityEtwBVB369EBv7oDHCRc2+DTglCgAV4UZdDf5yY8YIsRiZQfog 6IfbXxcQUktY/ju2EMMMTDZOkHej5w1GlE/uHeI2iR2rAQM1I7w7xqJ0odqewJ+FIV CwmxZ3IEe6802+DYvWbCyP72Pv5Qp62Pq/NErkm4mTvG0+5wKSDDRFVbdV/owc7h/2 +k4m/4iwrO978JJTii5qLSBma7AjE52mDlxzbrSDFqGmxXsMYEtu2uXn91282jrWn2 NDH7z7sN8X4dw== Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-a99c0beaaa2so457013866b.1 for ; Sun, 13 Oct 2024 23:33:36 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCW3U4DitaDyer60Ap7IIOzd9LTX/bA4l3QIFXGtQYWY3PK3k/do8oIPs+1DJBBopNETsMCyJeIvug==@kvack.org X-Gm-Message-State: AOJu0YxXtBtwTu0fwLOrLyHAQ/hobxDa1S4fuiQNQvOQx05r9yK5ReKT SXYYiRMa6QCtHzwiK9MbUGaOYlJZp0nN0syJiW4oDKv7x10L6dZSxJFgdIQiyIVpbf+exQQ7xCH bVSa3Qrwg7yVcDmX6bkqvIHS9lUo= X-Google-Smtp-Source: AGHT+IGZ/pvSEGOj2aDr3UCuPoEvLIEwFDanfdCCKGheVeO9c+rk7OR+rdL3ExZXprAgiHJej2PQMPfVqYcxsuOXJPo= X-Received: by 2002:a17:907:368d:b0:a99:5466:2556 with SMTP id a640c23a62f3a-a99b966b636mr1020625266b.61.1728887615477; Sun, 13 Oct 2024 23:33:35 -0700 (PDT) MIME-Version: 1.0 References: <20241014035855.1119220-1-maobibo@loongson.cn> <20241014035855.1119220-4-maobibo@loongson.cn> In-Reply-To: <20241014035855.1119220-4-maobibo@loongson.cn> From: Huacai Chen Date: Mon, 14 Oct 2024 14:33:24 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/3] LoongArch: Remove pte buddy set 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-Server: rspam07 X-Rspamd-Queue-Id: 981FA140005 X-Stat-Signature: amszgp63i8a9jfki867qjmhca5xsjzua X-Rspam-User: X-HE-Tag: 1728887613-932262 X-HE-Meta: U2FsdGVkX1+sSYByxNWoZAbyHAQdcKmWwBpxHECmebKOKy5mAnRTF63A7Cx6wzziD9ThxUCBQzEv6keMy/5JK1IYFPHjkcmyegwR4wkrj9ET0yjlQnDeAhaKRywG5aM/spKU0LtjKtnigkJSD9/0pgzyPIBJ/gklZYoOWkKXd5lk1I7AYv11sfxJRw2mPoFqHStuEC+RrEY9Gbjg8fJz2uZdDLh2YwTQKHdqCFYQ7kCYM8jx73cSE2gXEQWYvocOQMICqjLmje2b11HVbMF0G/rMCkSUlY1rWtLq7rlCBjnOKJab8giYsZVVHVY0BNqa0FgLzuljw5TAroLiUUx3Xa+pFd6MjbBIwZqlCWppwi9r8O69YijP6/CBaYp0fZ7lVdggbuGXkTU2LS4H4u2ZWjp0HHHYt6amQtdlZJIl2orKGRaodPdP5i1EuxKwCLx4fqG1e2AN9UkfmewYub/EBoU3cxjJh2KUnYi3z3ShHOCcK0r5gBuGSGLrNqiQJQ7Pt9oeXepbTt+gjy8gXwqc7HV8lC9TAG4CDUDvZ/Y6LnvkrXJjLHYyxa4zo1a7Itf7R/AyzAgExPXFb2Aq+qkn1C9/HPN4y+b0aGjZmHX7ye1lIlBAZD5FWNDqI59k/s/CAPssjpPCnS20qwi6IHw9itvSKpDSIe8ZjqtmsMdcF3ap745oTpUv77E1ffGQabLiKo7yEyZmuL8VnkKHUP87YdetLcq+iu7OUvdJilYKnzz4p0eEij9iLCyymciTsjh65/H3NEdiTscVHUMDGqDsQRAcrRJxpt4D/kdT1K9N2vBsQI5QJDjdS7OlAEINYMX/5s09ZfVnlo0tDfiCTyWLT/O7jMg+GM3dstO7vHGiqpvffaTFPEcB1IMFxPE3lyxBA9syOCXs52FYCl6qc4z02IRjwI6f/eP4FpqvD3q//ne4VOP27P8W6iTYYhQGYlxk3To1eKasXu9B9eM9wyw sR6nsrar UFirIsNOqbY8f4cP1hFx945F8cQMMKTS3BZp3WUlhqS+ncr3QCiT6JwZY37eTj6zLMdQtqVbiJT/guwBaWGkmDVxbhIrdSZUpdhCFyE6WC04L5w+4K71sUPLtKGiyn7Bs1OCp7Vw8o/LkWzfG2rcJQ9LvpFKdRGNUSgGT7ZlGtacZF37FgoXS/ggvVO4eUaoVQwaDcwZN+T90jyh/SjRffRSWohnx3YkN5JAuIOKBaD2wFBHLZ8jUSFinzhVyy1Ui6b+rCyavoSw1PETb7ZPm7ET48AXDcxzpjo7gEcab6LhqMc1qOa7oRFAzUkuL1Hx1qzc2wDFqDRsk0WGXBGlWnPlitUmDFdDTps+67gIdSpY3IRG2meCyRuoh8h4nDqgUoqAAX8gHE1mzRHyd9DUADCdvLQ== 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, The old code tries to fix the same problem in the first patch, so this patch can also be squashed to the first one (and it is small enough now). Others look good to me. Huacai On Mon, Oct 14, 2024 at 11:59=E2=80=AFAM Bibo Mao wro= te: > > For kernel address 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 pte buddy entry. > > Signed-off-by: Bibo Mao > --- > arch/loongarch/include/asm/pgtable.h | 35 ++++------------------------ > 1 file changed, 5 insertions(+), 30 deletions(-) > > diff --git a/arch/loongarch/include/asm/pgtable.h b/arch/loongarch/includ= e/asm/pgtable.h > index 22e3a8f96213..bc29c95b1710 100644 > --- a/arch/loongarch/include/asm/pgtable.h > +++ b/arch/loongarch/include/asm/pgtable.h > @@ -325,40 +325,15 @@ 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 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)); > + pte_t pte; > + > + pte =3D ptep_get(ptep); > + pte_val(pte) &=3D _PAGE_GLOBAL; > + set_pte(ptep, pte); > } > > #define PGD_T_LOG2 (__builtin_ffs(sizeof(pgd_t)) - 1) > -- > 2.39.3 > >