Re: Subject: Regression: CONFIG_ASYNC_KERNEL_PGTABLE_FREE causes memory exhaustion and stalls on busy Cascade Lake server (6.18.7 only)

[Robert Dinse <nanook@eskimo.com>]

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]


      I have run 6.18.8 on my workstation for two days without incident so I
suspect whatever was broken in 6.18.7 is already corrected, I am now putting
it on the other server which had problems, will know in about 12 hours.

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
  Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
    Knowledgeable human assistance, not telephone trees or script readers.
  See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.

On Sun, 1 Feb 2026, Christophe Leroy (CS GROUP) wrote:

> Date: Sun, 1 Feb 2026 19:16:43 +0100
> From: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
> To: Robert Dinse <nanook@eskimo.com>, akpm@linux-foundation.org
> Cc: linux-mm@kvack.org
> Subject: Re: Subject: Regression: CONFIG_ASYNC_KERNEL_PGTABLE_FREE causes
>     memory exhaustion and stalls on busy Cascade Lake server (6.18.7 only)
> 
>
>
> Le 29/01/2026 à 07:10, Robert Dinse a écrit :
>> 
>> 
>> Reverting to 6.18.6 immediately restores the previous stable behavior.
>> 
>> Attempt to disable CONFIG_ASYNC_KERNEL_PGTABLE_FREE
>> ---------------------------------------------------
>> I attempted to disable the new async kernel page table freeing feature:
>> 
>> - The symbol `CONFIG_ASYNC_KERNEL_PGTABLE_FREE` appears in `.config`
>> - However, it does not appear in xconfig or other configuration frontends
>> - Manually editing `.config` to disable it works only until the next 
>> `make`:
>>    - As soon as I re-run the build, the option is silently re-enabled
>> - I tried to chase the Kconfig dependencies, but the chain was too 
>> convoluted; it appears to be effectively non-user-selectable and forced on 
>> by default for my architecture.
>>
>>  From an operator perspective, this feature as currently implemented is not 
>> workable on a busy machine like this, and the inability to disable it makes 
>> it difficult to bisect or run with a known-good configuration.
>> 
>
> Try reverting commit 9f0a7ab700f8 ("iommu/sva: invalidate stale IOTLB entries 
> for kernel address space") ?
>
> Christophe
>