From: "Zi Yan" <ziy@nvidia.com>
To: "Kiryl Shutsemau" <kirill@shutemov.name>
Cc: "David Hildenbrand (Arm)" <david@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Miaohe Lin" <linmiaohe@huawei.com>,
"Naoya Horiguchi" <nao.horiguchi@gmail.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>,
"Usama Arif" <usama.arif@linux.dev>,
"Hao Zhang" <zhanghao1@kylinos.cn>,
"Hao Zhang" <hao_zhang_kdev@163.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] mm/memory-failure: keep the folio, not the poisoned subpage, locked across split
Date: Tue, 14 Jul 2026 13:31:54 -0400 [thread overview]
Message-ID: <DJYH202OLKZF.432DAJWF2MGA@nvidia.com> (raw)
In-Reply-To: <alZljHr4Nk3FOpCP@thinkstation>
On Tue Jul 14, 2026 at 12:40 PM EDT, Kiryl Shutsemau wrote:
> On Tue, Jul 14, 2026 at 11:44:39AM -0400, Zi Yan wrote:
>> There is an alternative, only igrab() when @lock_at is at or beyond the EOF,
>> as I was bouncing ideas with Codex.
>
> I saw this option too, but I wound rather not go this path.
>
> iput() still can lead to inode eviction an bunch of random filesystem
> complexity under us. I don't think we want to think about other
> fs-related locking issues in split context.
Your reasoning makes sense to me. Let's ignore this option.
For your patch 2, we might want something like below to avoid over
rejecting splits. WDYT?
offset = folio_page_idx(folio, lock_at);
if (split_type == SPLIT_TYPE_UNIFORM)
lock_at_index = folio->index + round_down(offset, 1UL << new_order);
else
/* @lock_at in non uniform split is always @folio */
lock_at_index = folio->index;
if (lock_at_index >= end) {
ret = -EBUSY;
goto out_unlock;
}
Also to keep a record in case we want to have @lock_at pointing to any
tail page for non uniform split in the future, something like below is
going to be useful (assisted by Codex).
static pgoff_t split_lock_at_index(struct folio *folio,
unsigned int new_order, struct page *split_at,
struct page *lock_at, enum split_type split_type)
{
unsigned long lock = folio_page_idx(folio, lock_at);
unsigned long split = folio_page_idx(folio, split_at);
int order;
if (split_type == SPLIT_TYPE_UNIFORM)
return folio->index + round_down(lock, 1UL << new_order);
for (order = folio_order(folio) - 1; order >= new_order; order--) {
unsigned long size = 1UL << order;
unsigned long lock_base = round_down(lock, size);
unsigned long split_base = round_down(split, size);
/* folio containing @lock_at will not be split any more */
if (lock_base != split_base)
return folio->index + lock_base;
}
return folio->index + round_down(lock, 1UL << new_order);
}
if (split_lock_at_index(folio, new_order, split_at, lock_at, split_type) >= end) {
ret = -EBUSY;
goto out_unlock;
}
--
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2026-07-14 17:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 12:23 [PATCH v2 0/5] mm: fix inode UAF when splitting a file folio past EOF Kiryl Shutsemau
2026-07-14 12:23 ` [PATCH v2 1/5] mm/memory-failure: keep the folio, not the poisoned subpage, locked across split Kiryl Shutsemau
2026-07-14 13:01 ` David Hildenbrand (Arm)
2026-07-14 14:53 ` Kiryl Shutsemau
2026-07-14 14:58 ` David Hildenbrand (Arm)
2026-07-14 15:44 ` Zi Yan
2026-07-14 16:40 ` Kiryl Shutsemau
2026-07-14 17:31 ` Zi Yan [this message]
2026-07-14 13:05 ` Kiryl Shutsemau
2026-07-14 12:23 ` [PATCH v2 2/5] mm/huge_memory: refuse to split a file folio when the anchor is beyond EOF Kiryl Shutsemau
2026-07-14 12:23 ` [PATCH v2 3/5] mm/huge_memory: remove unused split_huge_page_to_order() Kiryl Shutsemau
2026-07-14 12:23 ` [PATCH v2 4/5] mm/huge_memory: remove unused can_split_folio() Kiryl Shutsemau
2026-07-14 12:23 ` [PATCH v2 5/5] mm/huge_memory: fold split_folio_to_list_to_order() into split_folio_to_order() Kiryl Shutsemau
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=DJYH202OLKZF.432DAJWF2MGA@nvidia.com \
--to=ziy@nvidia.com \
--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=kirill@shutemov.name \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=nao.horiguchi@gmail.com \
--cc=npache@redhat.com \
--cc=ryan.roberts@arm.com \
--cc=stable@vger.kernel.org \
--cc=usama.arif@linux.dev \
--cc=zhanghao1@kylinos.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox