Re: [PATCH 08/16] mm/shmem: stop retrying folios that cannot be split

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

On 10/26/26 17:36, Kiryl Shutsemau wrote:
> On Mon, Oct 26, 2026 at 10:40:41AM +0100, David Hildenbrand (Arm) wrote:
>> From: Chris Mason <mason@kernel.org>
>>
>> A fault or collapse can insert a large folio crossing EOF after
>> shmem_undo_range() has handled the boundary folios. If splitting that
>> folio fails, truncate_inode_partial_folio() retains it when it is dirty.
>> The final scan then repeatedly finds it because it restarts from an
>> unchanged start.
>>
>> Truncation keeps the inode lock and ignores fatal signals while looping.
>> A concurrent unlink() can then block other directory operations while
>> holding the directory lock and waiting for the file's lock.
>>
>> Advance start past the retained folio, whose truncated part has already
>> been zeroed. Do not move start backwards if the failed split has shrunk
>> the folio.
>>
>> Fix generated by an LLM and sent by Chris Mason in private.
>>
>> Fixes: 55ac8bbe358b ("mm/shmem: fix race in shmem_undo_range w/THP")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Chris Mason <mason@kernel.org>
>> [ david: split fixes, simplify descriptions, adjust comments ]
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> 
> Any reason, this should not be in the same patch as 07/16?
> It is the same failure mode in the same function.

I decided to split because it's a slightly different error mode (failing to
discard vs. endless loop) and tackles two different commits.

-- 
Cheers,

David