[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250317130718.a5wals252gymjlsk@localhost.localdomain>
Date: Mon, 17 Mar 2025 15:07:18 +0200
From: "Ivan T. Ivanov" <iivanov@...e.de>
To: Piotr Jaroszynski <pjaroszynski@...dia.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, linux-arm-kernel@...ts.infradead.org,
Robin Murphy <robin.murphy@....com>,
Alistair Popple <apopple@...dia.com>,
Raghavendra Rao Ananta <rananta@...gle.com>,
SeongJae Park <sj@...nel.org>, Jason Gunthorpe <jgg@...dia.com>,
John Hubbard <jhubbard@...dia.com>,
Nicolin Chen <nicolinc@...dia.com>, iommu@...ts.linux.dev,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH] [arm64/tlb] Fix mmu notifiers for range-based invalidates
Hi,
On 03-04 00:51, Piotr Jaroszynski wrote:
>
> Update the __flush_tlb_range_op macro not to modify its parameters as
> these are unexepcted semantics. In practice, this fixes the call to
> mmu_notifier_arch_invalidate_secondary_tlbs() in
> __flush_tlb_range_nosync() to use the correct range instead of an empty
> range with start=end. The empty range was (un)lucky as it results in
> taking the invalidate-all path that doesn't cause correctness issues,
> but can certainly result in suboptimal perf.
>
> This has been broken since commit 6bbd42e2df8f ("mmu_notifiers: call
> invalidate_range() when invalidating TLBs") when the call to the
> notifiers was added to __flush_tlb_range(). It predates the addition of
> the __flush_tlb_range_op() macro from commit 360839027a6e ("arm64: tlb:
> Refactor the core flush algorithm of __flush_tlb_range") that made the
> bug hard to spot.
>
> Fixes: 6bbd42e2df8f ("mmu_notifiers: call invalidate_range() when invalidating TLBs")
I think that strictly speaking this should be:
Fixes: 360839027a6e ("arm64: tlb: Refactor the core flush algorithm of __flush_tlb_range")
Regards,
Ivan
Powered by blists - more mailing lists