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;
Date:   Thu, 10 Aug 2023 08:58:13 -0700 (PDT)
Subject:     Re: [PATCH -fixes] mm: Add a call to flush_cache_vmap() in vmap_pfn()
In-Reply-To: <mhng-3d3afb21-bd40-4095-ba62-41cf40b782ca@palmer-ri-x1c9>
CC:     dylan@andestech.com, alexghiti@rivosinc.com, urezki@gmail.com,
        Christoph Hellwig <hch@infradead.org>, lstoakes@gmail.com,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org
From:   Palmer Dabbelt <palmer@dabbelt.com>
To:     Christoph Hellwig <hch@infradead.org>, akpm@linux-foundation.org
Message-ID: <mhng-057e1f9e-8320-43b9-a0fe-282b4beffd13@palmer-ri-x1c9>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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.