Re: [PATCH v6 0/7] Fix stale IOTLB entries for kernel address space

[Dave Hansen <dave.hansen@intel.com>]

On 10/14/25 22:38, Baolu Lu wrote:
> On 10/15/25 08:43, Andrew Morton wrote:
>>> This solution introduces a deferred freeing mechanism for kernel page
>>> table pages, which provides a safe window to notify the IOMMU to
>>> invalidate its caches before the page is reused.
>>
>> Thanks for working on this.
>>
>> Can we expect any performance impact from this?  Have any measurements
>> been performed?
> 
> This change only defers page table page freeing, allows for batch-
> freeing of page table pages, and notifies the IOMMU driver to invalidate
> the related caches. It doesn't impose any overhead in any critical path;
> therefore, I don't see any potential performance impact.

Thankfully, freeing kernel page tables just isn't a common operation.
It's also done right next to a big fat flush_tlb_kernel_range() which is
going to IPI the whole world. So I'd expect this new gunk to be in the
noise behind all those IPIs.

We should double check that 0day has had a go at this series and hasn't
found anything. But other than that, I don't think we need to do any
specific performance testing on it.

>> Only [7/7] has a cc:stable, even though that patch is not at all
>> backportable.  Please give some thought and suggestions regarding
>> whether you think we should backport this into earlier kernels.
> 
> Yes. We should backport this series to stable kernels.
> 
>> If "yes" then the size and scope of the series looks problematic.  Is
>> it possible to put together something simple and expedient just to plug
>> the hole in older kernels?
> 
> Squashing some patches is one way. But would it be workable to backport
> this series manually? Say, could we send a pull request to the stable
> mailing list after this series has landed?
I honestly think we should just disable SVA in old kernels at compile
time, or at least default it to be disabled at runtime. That's the
simplest thing.

The other alternative is to have arch_vmap_pmd_supported() return false
when SVA is active, or maybe when it's supported on the platform.

Either of those are 10-ish lines of code and easy to backport.