All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Qiliang Yuan" <qiliang.yuan@linux.dev>,
	"Hugh Dickins" <hughd@google.com>,
	"Baolin Wang" <baolin.wang@linux.alibaba.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jan Kara" <jack@suse.cz>, "Qiliang Yuan" <odys.yuan@gmail.com>,
	"David Hildenbrand (Arm)" <david@kernel.org>
Cc: linux-mm@kvack.org, "kernel test robot" <lkp@intel.com>
Subject: Re: [PATCH] mm/shmem: drop the second folio batch from shmem_undo_range()
Date: Fri, 13 Nov 2026 03:39:29 +0000	[thread overview]
Message-ID: <sashiko-outbox-212134@kernel.org> (raw)
In-Reply-To: <20261111-bug-mm-shmem-undo-frame-v1-1-e50a95b8f9b2@linux.dev>

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] mm/shmem: skipped boundary zeroing on swapin failure in
  shmem_undo_range() [1]
--

commit 785bd3384006f8bb06c3c8f9b1b5d455eba3d449
Author: Qiliang Yuan <qiliang.yuan@linux.dev>

mm/shmem: drop the second folio batch from shmem_undo_range()

This commit removes the second folio_batch from shmem_undo_range() by
passing fbatch directly to delete_from_page_cache_batch() after removing
swap entries, and using truncate_inode_folio() when undoing a failed
fallocate().

> diff --git a/mm/shmem.c b/mm/shmem.c
> index 156469423a866..5bcbdd6078a73 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1352,9 +1352,6 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, uoff_t lend,
>  	index = start;
>  	while (index < end && find_lock_entries(mapping, &index, end - 1,
>  			&fbatch, indices)) {
> -		struct folio_batch remove;
> -
> -		folio_batch_init(&remove);
>  		for (i = 0; i < folio_batch_count(&fbatch); i++) {
>  			folio = fbatch.folios[i];
>  
> @@ -1366,13 +1363,14 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, uoff_t lend,
>  				continue;
>  			}
>  
> -			if (!unfalloc || !folio_test_uptodate(folio)) {
> +			if (!unfalloc)
>  				truncate_cleanup_folio(folio);
> -				folio_batch_add(&remove, folio);
> -			}
> +			else if (!folio_test_uptodate(folio))
> +				truncate_inode_folio(mapping, folio);
>  		}
> -		delete_from_page_cache_batch(mapping, &remove);
>  		folio_batch_remove_exceptionals(&fbatch);
> +		if (!unfalloc)
> +			delete_from_page_cache_batch(mapping, &fbatch);
>  		for (i = 0; i < folio_batch_count(&fbatch); i++)
>  			folio_unlock(fbatch.folios[i]);
>  		folio_batch_release(&fbatch);

[Severity: Critical]
This problem wasn't introduced by this patch, but can shmem_undo_range()
leave partial boundary ranges unzeroed when swapping in a boundary folio
fails [1]?

Later in shmem_undo_range(), shmem_get_partial_folio() is called to fault
in boundary folios at lstart >> PAGE_SHIFT and lend >> PAGE_SHIFT before
passing them to truncate_inode_partial_folio():

mm/shmem.c:shmem_get_partial_folio() {
	...
	folio = NULL;
	shmem_get_folio(inode, index, 0, &folio, SGP_READ);
	return folio;
}

mm/shmem.c:shmem_undo_range() {
	...
	folio = shmem_get_partial_folio(inode, lstart >> PAGE_SHIFT);
	if (folio) {
		same_folio = lend < folio_next_pos(folio);
		folio_mark_dirty(folio);
		truncate_inode_partial_folio(folio, lstart, lend, &start,
					     same_folio ? &end : NULL);
	...
}

If the boundary falls inside a swapped-out entry and shmem_swapin_folio()
fails with -ENOMEM under memory pressure, shmem_get_partial_folio() ignores
the error from shmem_get_folio() and returns NULL.  shmem_undo_range() then
skips truncate_inode_partial_folio() for that boundary while the subsequent
whole_folios loop skips any swap entry crossing start or end, leaving stale
non-zero data in the swap entry that becomes visible on later reads or file
extensions.

[1] https://sashiko.dev/#/bug/linux-c8b370f0-7820-4bcf-bfc3-a27db7a7ba48

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111-bug-mm-shmem-undo-frame-v1-1-e50a95b8f9b2@linux.dev?part=1


      parent reply	other threads:[~2026-11-13  3:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12  3:39 [PATCH] mm/shmem: drop the second folio batch from shmem_undo_range() Qiliang Yuan
2026-11-12  8:05 ` Baolin Wang
2026-11-12  8:33   ` David Hildenbrand (Arm)
2026-11-12  9:11     ` Qiliang Yuan
2026-11-13  3:39 ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-212134@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@kernel.org \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=odys.yuan@gmail.com \
    --cc=qiliang.yuan@linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.