From: Zi Yan <ziy@nvidia.com>
To: David Hildenbrand <david@redhat.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
"Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
syzbot <syzbot+e6367ea2fdab6ed46056@syzkaller.appspotmail.com>,
akpm@linux-foundation.org, linmiaohe@huawei.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
nao.horiguchi@gmail.com, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [mm?] WARNING in memory_failure
Date: Wed, 24 Sep 2025 13:52:00 -0400 [thread overview]
Message-ID: <E82638DD-9E5D-4C69-AA0F-7DDC0E3D109B@nvidia.com> (raw)
In-Reply-To: <cad74ef8-3543-4fc5-a175-8fc23a88776a@redhat.com>
On 24 Sep 2025, at 13:05, David Hildenbrand wrote:
>>>
>>>>
>>>> What I can think of is:
>>>> 0. split code always does a split to allowed minimal order,
>>>> namely max(fs_min_order, order_from_caller);
>>>
>>> Wouldn't max mean "allowed maximum order" ?
>>>
>>> I guess what you mean is "split to this order or smaller" -- min?
>>
>> But LBS imposes a fs_min_order that is not 0. When a caller asks
>> to split to 0, folio split code needs to use fs_min_order instead of 0.
>> Thus the max.
>
> I'd say, the point is that if someone wants to split to 0 but that is impossible, then we should fail :)
I agree.
>
>>
>>>
>>>> 1. if split order cannot reach to order_from_caller, it just return fails,
>>>> so most of the caller will know about it;
>>>
>>> Yes, I think this would be the case here: if we cannot split to order-0, we can just fail right away.
>>>
>>>> 2. for LBS code, when it sees a split failure, it should check the resulting
>>>> folio order against fs min_order. If the orders match, it regards it as
>>>> a success.
>>>>
>>>> At least, most of the code does not need to be LBS aware. WDYT?
>>>
>>> Is my understand correct that it's either that the caller wants to
>>>
>>> (a) Split to order-0 -- no larger folio afterwards.
>>>
>>> (b) Split to smallest order possible, which might be the mapping min order.
>>
>> Right. IIRC, most of callers are (a), since folio split was originally
>> called by code that cannot handle THPs (now large folios). For (b),
>> I actually wonder if there exists such a caller.
>>
>>> If so, we could keep the interface simpler than allowing to specify arbitrary orders as request.
>>
>> We might just need (a), since there is no caller of (b) in kernel, except
>> split_folio_to_order() is used for testing. There might be future uses
>> when kernel wants to convert from THP to mTHP, but it seems that we are
>> not there yet.
>>
>
> Even better, then maybe selected interfaces could just fail if the min-order contradicts with the request to split to a non-larger (order-0) folio.
Yep. Let’s hear what Luis and Pankaj will say about this.
>
>>
>>
>> +Luis and Pankaj for their opinions on how LBS is going to use split folio
>> to any order.
>>
>> Hi Luis and Pankaj,
>>
>> It seems that bumping split folio order from 0 to mapping_min_folio_order()
>> instead of simply failing the split folio call gives surprises to some
>> callers and causes issues like the one reported by this email. I cannot think
>> of any situation where failing a folio split does not work. If LBS code
>> wants to split, it should supply mapping_min_folio_order(), right? Does
>> such caller exist?
>>
>> Thanks.
>>
>>
>> Best Regards,
>> Yan, Zi
>>
>
>
> --
> Cheers
>
> David / dhildenb
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2025-09-24 17:52 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 16:22 syzbot
2025-09-24 11:32 ` David Hildenbrand
2025-09-24 15:03 ` Zi Yan
2025-09-24 15:35 ` David Hildenbrand
2025-09-24 16:33 ` Zi Yan
2025-09-24 17:05 ` David Hildenbrand
2025-09-24 17:52 ` Zi Yan [this message]
2025-09-25 12:02 ` Pankaj Raghav (Samsung)
2025-09-25 14:24 ` Zi Yan
2025-09-25 16:23 ` Yang Shi
2025-09-25 16:48 ` David Hildenbrand
2025-09-25 17:26 ` Yang Shi
2025-09-29 11:08 ` Pankaj Raghav (Samsung)
2025-09-29 15:20 ` Zi Yan
2025-09-29 16:13 ` David Hildenbrand
2025-10-01 1:51 ` Zi Yan
2025-10-01 2:06 ` syzbot
2025-10-01 2:13 ` Zi Yan
2025-10-01 4:51 ` syzbot
2025-10-01 23:58 ` jane.chu
2025-10-02 0:38 ` Zi Yan
2025-10-02 2:04 ` Zi Yan
2025-10-02 2:50 ` syzbot
2025-10-02 5:23 ` jane.chu
2025-10-02 13:54 ` Zi Yan
2025-10-02 17:47 ` jane.chu
2025-10-09 7:39 ` Miaohe Lin
2025-10-10 15:25 ` Zi Yan
2025-10-02 17:54 ` jane.chu
2025-10-02 18:45 ` Zi Yan
2025-10-03 4:02 ` jane.chu
2025-10-02 18:33 ` Zi Yan
2025-10-02 19:09 ` syzbot
2025-10-02 7:25 ` David Hildenbrand
2025-09-29 17:29 ` jane.chu
2025-09-29 17:49 ` jane.chu
2025-09-29 18:23 ` jane.chu
2025-09-29 20:15 ` Zi Yan
2025-09-29 20:52 ` jane.chu
2025-09-30 2:51 ` Miaohe Lin
2025-09-30 4:35 ` jane.chu
2025-09-30 6:31 ` Miaohe Lin
2025-10-01 18:15 ` jane.chu
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=E82638DD-9E5D-4C69-AA0F-7DDC0E3D109B@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=kernel@pankajraghav.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=nao.horiguchi@gmail.com \
--cc=syzbot+e6367ea2fdab6ed46056@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox