public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Zi Yan <ziy@nvidia.com>, Luis Chamberlain <mcgrof@kernel.org>,
	"Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>
Cc: 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 19:05:54 +0200	[thread overview]
Message-ID: <cad74ef8-3543-4fc5-a175-8fc23a88776a@redhat.com> (raw)
In-Reply-To: <B0781266-D168-4DCB-BFCE-3EA01F43F184@nvidia.com>


>>
>>>
>>> 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 :)

> 
>>
>>> 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.

> 
> 
> +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


  reply	other threads:[~2025-09-24 17:06 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-23 16:22 [syzbot] [mm?] WARNING in memory_failure 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 [this message]
2025-09-24 17:52           ` Zi Yan
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=cad74ef8-3543-4fc5-a175-8fc23a88776a@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --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 \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox