All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kiryl Shutsemau <kirill@shutemov.name>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,  Zi Yan <ziy@nvidia.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	 "Liam R . Howlett" <liam@infradead.org>,
	Nico Pache <npache@redhat.com>,
	 Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
	Barry Song <baohua@kernel.org>,
	 Lance Yang <lance.yang@linux.dev>,
	Hao Zhang <hao_zhang_kdev@163.com>,
	 Hao Zhang <zhanghao1@kylinos.cn>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 stable@vger.kernel.org
Subject: Re: [PATCH] mm: thp: pin the inode across a file folio split
Date: Tue, 14 Jul 2026 11:29:38 +0100	[thread overview]
Message-ID: <alYPE1CDJE4HaP1J@thinkstation> (raw)
In-Reply-To: <alV3oLwvbeQsagsA@thinkstation>

On Tue, Jul 14, 2026 at 12:45:41AM +0100, Kiryl Shutsemau wrote:
> On Mon, Jul 13, 2026 at 04:13:41PM -0700, Andrew Morton wrote:
> > On Mon, 13 Jul 2026 18:09:15 +0100 Kiryl Shutsemau <kirill@shutemov.name> wrote:
> > 
> > > From: "Kiryl Shutsemau (Meta)" <kirill@shutemov.name>
> > > 
> > > __folio_split() looks up mapping = folio->mapping for a file-backed
> > > folio and keeps dereferencing it after the split completes:
> > > shmem_uncharge(mapping->host) for folios dropped beyond EOF and
> > > i_mmap_unlock_read(mapping) on the way out.
> > > 
> > > Nothing holds an inode reference for that duration. The split relies on
> > > the folio the caller keeps locked (@lock_at) to pin the inode through
> > > the page cache: while it is locked and present,
> > > truncate_inode_pages_final() in evict() cannot make progress. But the
> > > split drops @lock_at from the page cache when it falls beyond EOF (the
> > > @end handling in __folio_freeze_and_split_unmapped()), while keeping it
> > > locked for the caller. That removes the last pin, and a concurrent final
> > > iput() can then evict and RCU-free the inode before __folio_split() is
> > > done touching mapping.
> > > 
> > > This is reachable from memory_failure(): poisoning a tail page of a
> > > shmem THP that straddles EOF makes try_to_split_thp_page() split at that
> > > page, so the dropped @lock_at is the folio returned locked. The result
> > > is a use-after-free, e.g.:
> > > 
> > >   BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790
> > >    i_mmap_unlock_read include/linux/fs.h:537 [inline]
> > >    __folio_split+0x732/0x1640 mm/huge_memory.c:4100
> > >    try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675
> > >    memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470
> > > 
> > >   Freed by task 4601:
> > >    shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177
> > >    i_callback+0x4c/0xa0 fs/inode.c:326
> > >    destroy_inode+0x144/0x1e0 fs/inode.c:402
> > >    evict+0x57f/0xac0 fs/inode.c:870
> > > 
> > > Pin the inode with igrab() before the split and drop the reference with
> > > iput() after the last mapping dereference. igrab() returns NULL only if
> > > the inode is already being evicted (i_count 0 and I_FREEING set), which
> > > a split racing eviction can observe; there is nothing safe to split
> > > then, so return -EBUSY, which callers already handle.
> > 
> > Sashiko is worried about iput() while holding folio_lock():
> > 
> > 	https://sashiko.dev/#/patchset/20260713170915.239819-1-kirill@shutemov.name
> 
> Sashiko is right. If iput() drops the last reference and
> @lock_at is still in page cache we would self-deadlock.
> 
> I don't see an obvious solution. Will think more tomorrow.

Andrew, please drop the patch. Zi and I are discussing possible
alternatives.

https://lore.kernel.org/all/alYNlDNMQy0Fl2VB@thinkstation/

-- 
  Kiryl Shutsemau / Kirill A. Shutemov


      reply	other threads:[~2026-07-14 10:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-13 17:09 [PATCH] mm: thp: pin the inode across a file folio split Kiryl Shutsemau
2026-07-13 19:10 ` Zi Yan
2026-07-13 23:13 ` Andrew Morton
2026-07-13 23:45   ` Kiryl Shutsemau
2026-07-14 10:29     ` Kiryl Shutsemau [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=alYPE1CDJE4HaP1J@thinkstation \
    --to=kirill@shutemov.name \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=hao_zhang_kdev@163.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=npache@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=zhanghao1@kylinos.cn \
    --cc=ziy@nvidia.com \
    /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.