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 19:02, Kiryl Shutsemau wrote:
> On Thu, Aug 27, 2026 at 06:00:33PM +0200, David Hildenbrand (Arm) wrote:
>> On 8/20/26 20:55, 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.
>>>
>>> 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")
>>> Reviewed-by: Zi Yan <ziy@nvidia.com>
>>> Signed-off-by: Kairui Song <kasong@tencent.com>
>>> ---
>>>  mm/huge_memory.c | 27 ++++++++++++++++-----------
>>>  1 file changed, 16 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index ced400f72d43..a6759a14e057 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -3878,6 +3878,9 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
>>>  int folio_check_splittable(struct folio *folio, unsigned int new_order,
>>>  			   enum split_type split_type)
>>>  {
>>> +	bool is_anon = folio_test_anon(folio);
>>> +	bool is_swapcache = folio_test_swapcache(folio);
>>
>> Both const please.
> 
> I see a lot of const everywhere in mm code now. I feel I missed the memo.
> Do they make a difference? 

You tell the compiler that you expect this not not be an ordinary variable but
instead ... a constant.

Any future code changes that would try to modify this variable will get a
friendly greeting from the compiler stating that someone assumes this value to
never change.

The compiler can't do that for you if you don't tell it about what you consider
constant.

-- 
Cheers,

David