Message ID | 20230809164633.1556126-1-alexghiti@rivosinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c44e:0:b0:3f2:4152:657d with SMTP id w14csp2981888vqr; Wed, 9 Aug 2023 11:05:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEXn5FAJYzp2ZVKF3NxZGU+ScTTO0106NqaeR/sL2d1Rp9hCnrOJiaglqXrT2Ew/pQJUg8V X-Received: by 2002:a05:6830:4d7:b0:6bc:a68b:ca44 with SMTP id s23-20020a05683004d700b006bca68bca44mr3902430otd.6.1691604339653; Wed, 09 Aug 2023 11:05:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691604339; cv=none; d=google.com; s=arc-20160816; b=yLZQzD7QCjST5rlj8VvXYrasJMoNfWgUkj7w9L+ANnzxCX6NwgSoE3f0qE5ydTG2eD octVdr36EG9cNBTD3xrr1U+aiBeeIqHMIIzznsFLSvkcscrt9q1xjCfNWobhpttpZinl kJcdWSRLzSCbfTkBSsH4ruIWDI6ifoFbd+TMMkB3gH00OgKY2aoII9NmeaiJ6sm4x34u Yi30qaTkh+UaWGd+/2YVvCorCa2dpGvbGrnacZllaPvD1xSq0gD77KVgZ88yHSst5O36 dechKRd07zwtthBMkpOkM+WkZIWfgDgJIyEyEohkMhoQiABTHkZEGfeBg+A3FiK3yqdf JM5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=LCB6J9xjkovo4nsL5var8Yeba5WXNTY3HlVH4wMSnQo=; fh=fK/KvvNEU+uRDhepm0sV8+BQY7zVeOUl2LNcr0uBTz4=; b=uNHq4JVB7iI6jKofLC+KQEl5iX3G8wWaMklJGVf5k58HfGlYwjuUnAmj8R7nZtRP6w 1cxPGvSG39Fb08W03Wa0AV9P3EMJMjoFwWEgZabsT9NNdpbXfGnWgZ75KkwVaMNVhMr0 q0JTkw9G1Oau7+oP0HKacTlb+x3hZVGH4iVgRxIZUW9Nfg7fc6vR6ky1Y22tvGpRqcvg 7hyB09miWSrvt+FlPX6PAuWbxf+V8LHbctABhkv2vtNf6rGWgN/MqH4I8GjmnIsjuQ/a zltEUSsa+QSGxUxeCEg42qQACm5FiiGz/C/fX8B5JgDUYTqkYpSQrOsw4xzWNRBRWmOI eCrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=ToePmrNn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w1-20020a631601000000b005579e1fc429si9459975pgl.669.2023.08.09.11.05.24; Wed, 09 Aug 2023 11:05:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=ToePmrNn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231223AbjHIQqj (ORCPT <rfc822;craechal@gmail.com> + 99 others); Wed, 9 Aug 2023 12:46:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231216AbjHIQqi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 9 Aug 2023 12:46:38 -0400 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 507F61BFA for <linux-kernel@vger.kernel.org>; Wed, 9 Aug 2023 09:46:37 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-3fe426b8583so61887105e9.2 for <linux-kernel@vger.kernel.org>; Wed, 09 Aug 2023 09:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1691599596; x=1692204396; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=LCB6J9xjkovo4nsL5var8Yeba5WXNTY3HlVH4wMSnQo=; b=ToePmrNnppd/Is0E7PAd+j29Nv5DFUjvi18bOflnM9U2nXEfSB4OmJTuUoQ+iE5SVW fJUPqV1RGbk2gV9dolFc9ZA4vRjS7062kNecnkUCSYw5YOarLb2c591nRpZMWLUfzKhJ tXlk/4tkJZN6qDfR9O6NFRsVPP3bms2MF3nF1rtBgVW8vsoWqXEPT4ohPmfp1CizLkbC J8X+dsSG43psOtrhYnaPM0mpNlYW19TqZtbRr+o2Pam9vbKY+bNz1eh9hpmBAq6J73lH db/hm3ocMgPBYXxSYtKUcaw0SmXAz2f+gZZ2XCjSYvjHtM2UdmX2qXVdNpIvKLmq7sbY BqwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691599596; x=1692204396; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LCB6J9xjkovo4nsL5var8Yeba5WXNTY3HlVH4wMSnQo=; b=O4zHZ12Iy1tSOo0zMv0Vy+s47WAzxwROA53gxmpI1Kr3q+aCUnIgEbJrkWbSut8fIL vu7gUZ55yQOUa1GhcdezdL14ZTXgpORWacC8shEmbHOE2VCeC4IprqI1czTEqr0HR699 Lo4cQ4JiWxNP9IyCmXFp8+mP6v1tzHmMtgZkG2No/lhw6xvuqxR2BZF5adk11vkg0BfL Lix8lK2QMm8fIdRDLCJSTYZ3330LZs0i3WysIyvs8x4a2aN8tzXA6fICmASvomxjaDwS VdeYArGJCvachOfMszRJmz4OK+Zjk0NNe0FoBW18mND2poJFgNKSCdUAXSD4sQdvLveD 23xg== X-Gm-Message-State: AOJu0YxBjDVXbrd67zTEt5WXCFtE2qZ/ZS7Daxk9v3M/3ZvbRxd3WQZm X24As/TvP7qL6bY7w5bLEKAgnw== X-Received: by 2002:a1c:4c12:0:b0:3fb:a0fc:1ba1 with SMTP id z18-20020a1c4c12000000b003fba0fc1ba1mr2651739wmf.35.1691599595638; Wed, 09 Aug 2023 09:46:35 -0700 (PDT) Received: from alex-rivos.ba.rivosinc.com (amontpellier-656-1-456-62.w92-145.abo.wanadoo.fr. [92.145.124.62]) by smtp.gmail.com with ESMTPSA id p19-20020a05600c205300b003fe17901fcdsm2453431wmg.32.2023.08.09.09.46.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Aug 2023 09:46:34 -0700 (PDT) From: Alexandre Ghiti <alexghiti@rivosinc.com> To: Andrew Morton <akpm@linux-foundation.org>, Uladzislau Rezki <urezki@gmail.com>, Christoph Hellwig <hch@infradead.org>, Lorenzo Stoakes <lstoakes@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Alexandre Ghiti <alexghiti@rivosinc.com>, Dylan Jhong <dylan@andestech.com> Subject: [PATCH -fixes] mm: Add a call to flush_cache_vmap() in vmap_pfn() Date: Wed, 9 Aug 2023 18:46:33 +0200 Message-Id: <20230809164633.1556126-1-alexghiti@rivosinc.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773775711973429025 X-GMAIL-MSGID: 1773775711973429025 |
Series |
[-fixes] mm: Add a call to flush_cache_vmap() in vmap_pfn()
|
|
Commit Message
Alexandre Ghiti
Aug. 9, 2023, 4:46 p.m. UTC
flush_cache_vmap() must be called after new vmalloc mappings are
installed in the page table in order to allow architectures to make sure
the new mapping is visible.
Fixes: 3e9a9e256b1e ("mm: add a vmap_pfn function")
Reported-by: Dylan Jhong <dylan@andestech.com>
Closes: https://lore.kernel.org/linux-riscv/ZMytNY2J8iyjbPPy@atctrx.andestech.com/
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
---
mm/vmalloc.c | 4 ++++
1 file changed, 4 insertions(+)
Comments
On Wed, 9 Aug 2023 18:46:33 +0200 Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > flush_cache_vmap() must be called after new vmalloc mappings are > installed in the page table in order to allow architectures to make sure > the new mapping is visible. Thanks. What are the user-visible effects of this bug?
On Wed, Aug 09, 2023 at 06:46:33PM +0200, Alexandre Ghiti wrote: > flush_cache_vmap() must be called after new vmalloc mappings are > installed in the page table in order to allow architectures to make sure > the new mapping is visible. Looks good. I somehow vaguely remember seing a patch like this floating around before as part of a series, but if that didn't make it it certainly should now. Reviewed-by: Christoph Hellwig <hch@lst.de>
Hi Andrew, On Wed, Aug 9, 2023 at 8:46 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Wed, 9 Aug 2023 18:46:33 +0200 Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > > > flush_cache_vmap() must be called after new vmalloc mappings are > > installed in the page table in order to allow architectures to make sure > > the new mapping is visible. > > Thanks. What are the user-visible effects of this bug? It could lead to a panic since on some architectures (like powerpc), the page table walker could see the wrong pte value and trigger a spurious page fault that can not be resolved (see commit f1cb8f9beba8 ("powerpc/64s/radix: avoid ptesync after set_pte and ptep_set_access_flags")). But actually the patch is aiming at riscv: the riscv specification allows the caching of invalid entries in the TLB, and since we recently removed the vmalloc page fault handling, we now need to emit a tlb shootdown whenever a new vmalloc mapping is emitted (https://lore.kernel.org/linux-riscv/20230725132246.817726-1-alexghiti@rivosinc.com/). That's a temporary solution, there are ways to avoid that :) Thanks, Alex
On Wed, Aug 09, 2023 at 06:46:33PM +0200, Alexandre Ghiti wrote: > flush_cache_vmap() must be called after new vmalloc mappings are > installed in the page table in order to allow architectures to make sure > the new mapping is visible. > > Fixes: 3e9a9e256b1e ("mm: add a vmap_pfn function") > Reported-by: Dylan Jhong <dylan@andestech.com> > Closes: https://lore.kernel.org/linux-riscv/ZMytNY2J8iyjbPPy@atctrx.andestech.com/ > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> > --- > mm/vmalloc.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 93cf99aba335..228a4a5312f2 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2979,6 +2979,10 @@ void *vmap_pfn(unsigned long *pfns, unsigned int count, pgprot_t prot) > free_vm_area(area); > return NULL; > } > + > + flush_cache_vmap((unsigned long)area->addr, > + (unsigned long)area->addr + count * PAGE_SIZE); > + > return area->addr; > } > EXPORT_SYMBOL_GPL(vmap_pfn); > -- > 2.39.2 > Hi Alex, Looks good to me. Thanks. Reviewed-by: Dylan Jhong <dylan@andestech.com> Best regards, Dylan Jhong
On Wed, 09 Aug 2023 15:25:19 PDT (-0700), Christoph Hellwig wrote: > On Wed, Aug 09, 2023 at 06:46:33PM +0200, Alexandre Ghiti wrote: >> flush_cache_vmap() must be called after new vmalloc mappings are >> installed in the page table in order to allow architectures to make sure >> the new mapping is visible. > > Looks good. I somehow vaguely remember seing a patch like this floating > around before as part of a series, but if that didn't make it it > certainly should now. > > Reviewed-by: Christoph Hellwig <hch@lst.de> I think we're likely to end up with performance problems around here, but at least it's correct. If someone has performance Dylan: this fixes your breakage as well, right? I've queued it up for testing, but I doubt QEMU would find any issues here. My build box has been slow lately, but it should end up in fixes later today.
On Thu, 10 Aug 2023 08:13:56 PDT (-0700), Palmer Dabbelt wrote: > On Wed, 09 Aug 2023 15:25:19 PDT (-0700), Christoph Hellwig wrote: >> On Wed, Aug 09, 2023 at 06:46:33PM +0200, Alexandre Ghiti wrote: >>> flush_cache_vmap() must be called after new vmalloc mappings are >>> installed in the page table in order to allow architectures to make sure >>> the new mapping is visible. >> >> Looks good. I somehow vaguely remember seing a patch like this floating >> around before as part of a series, but if that didn't make it it >> certainly should now. >> >> Reviewed-by: Christoph Hellwig <hch@lst.de> > > I think we're likely to end up with performance problems around here, > but at least it's correct. If someone has performance > > Dylan: this fixes your breakage as well, right? > > I've queued it up for testing, but I doubt QEMU would find any issues > here. My build box has been slow lately, but it should end up in fixes > later today. Sorry about that, I'm in the wrong thread -- I meant to be over here <https://lore.kernel.org/all/20230725132246.817726-1-alexghiti@rivosinc.com/>. Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> but I'm not taking this via the RISC-V tree unless someone asks.
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 93cf99aba335..228a4a5312f2 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2979,6 +2979,10 @@ void *vmap_pfn(unsigned long *pfns, unsigned int count, pgprot_t prot) free_vm_area(area); return NULL; } + + flush_cache_vmap((unsigned long)area->addr, + (unsigned long)area->addr + count * PAGE_SIZE); + return area->addr; } EXPORT_SYMBOL_GPL(vmap_pfn);