Re: [PATCH v3 07/15] mm/shmem: stop retrying folios that cannot be split

[Balbir Singh <balbirs@nvidia.com>]

On Wed, Oct 28, 2026 at 10:55:05AM +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>
> Tested-by: Gregory Price (Meta) <gourry@gourry.net>
> [ david: split fixes, simplify descriptions, adjust comments ]
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
>  mm/shmem.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/mm/shmem.c b/mm/shmem.c
> index eddd5870be07..50d526edc2d4 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1481,6 +1481,15 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, uoff_t lend,
>  						index = start;
>  						break;
>  					}
> +				} else if (folio->mapping) {
> +					/*
> +					 * Splitting failed, but the part in the
> +					 * range is already zeroed. The folio
> +					 * was not dropped, so skip it when
> +					 * restarting the scan to avoid retrying
> +					 * it forever.
> +					 */
> +					start = max(start, folio_next_index(folio));
>  				}
>  			}
>  			folio_unlock(folio);
> 


Reviewed-by: Balbir Singh <balbirs@nvidia.com>