It might not be very common, but we can end up with shmem files that are composed only of swapin-error/poison markers. Such markers are not counted in info->alloced. Consequently, shmem_setattr() can skip shmem_truncate_range(), leaving the markers behind. Truncating the file to zero and growing it again will result in reads failing with -EIO instead of returning zeroes. Check whether the mapping contains entries, in addition to info->alloced, before skipping the truncation. Keep the info->alloced check so that shmem_recalc_inode(), called at the end of shmem_undo_range(), can fix up accounting after reclaim has emptied the mapping. Fixes: 6cec2b95dadf ("mm/shmem: fix infinite loop when swap in shmem error at swapoff time") Cc: stable@vger.kernel.org Signed-off-by: David Hildenbrand (Arm) --- mm/shmem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/shmem.c b/mm/shmem.c index f5b5c9a312c53..45f6c34f161e4 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -1602,7 +1602,8 @@ static int shmem_setattr(const struct mnt_idmap *idmap, if (oldsize > holebegin) unmap_mapping_range(inode->i_mapping, holebegin, 0, 1); - if (info->alloced) + /* Swapin-error markers are not counted in alloced. */ + if (info->alloced || !mapping_empty(inode->i_mapping)) shmem_truncate_range(inode, newsize, (loff_t)-1); /* unmap again to remove racily COWed private pages */ -- 2.43.0