Re: [PATCH v3 02/18] mm/huge_memory: fix rejection of swap cache folios with a mapping

["David Hildenbrand (Arm)" <david@kernel.org>]

On 8/27/26 16:33, Kiryl Shutsemau wrote:
> On Fri, Aug 21, 2026 at 02:55:15AM +0800, Kairui Song via B4 Relay wrote:
>> From: Kairui Song <kasong@tencent.com>
>>
>> A folio in the swap cache cannot be split if it has a mapping (shmem).
>> The split code does a defensive check for this in
>> __folio_freeze_and_split_unmapped, after the folio ref has been frozen
>> and the NR_SHMEM_THPS/NR_FILE_THPS counters have been decremented. It
>> rejects the split and returns -EINVAL without unfreezing the folio or
>> restoring the counters. That error path is buggy: if it is ever taken,
>> it leaves the folio frozen and stuck, skews the counters, and fires
>> the VM_WARN_ON_ONCE_FOLIO for a state that is actually legitimate.
> 
> If you are going to repost this, could you make "This error path is
> buggy" a new paragraph?
> 
>>
>> Check for this case up front in folio_check_splittable and return
>> -EBUSY before any state is modified, so the split routine always backs
>> out cleanly.
>>
>> Also fix a bracket style issue that checkpatch.pl keeps complaining
>> about.
>>
>> Fixes: 00527733d0dc ("mm/huge_memory: add two new (not yet used) functions for folio_split()")
>> Fixes: 714b056c8321 ("mm/huge_memory: convert VM_BUG* to VM_WARN* in __folio_split")
> 
> This is inert bug, right? I don't think we want the commit to be
> backported. I expect stable machinery to pick it up based on Fixes.
> 
> Is there a way to express "not stable material" while keeping Fixes: in
> place?
In mm, stable never picks stuff up automatically.

it's usually best to write in the patch description why the decision was made
that it should or should not be, stable material.

-- 
Cheers,

David