Re: [syzbot] [mm?] WARNING in memory_failure

["Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>]

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

I am not aware of any place in the LBS path where we supply the
min_order. truncate_inode_partial_folio() calls try_folio_split(), which
takes care of splitting in min_order chunks. So we embedded the
min_order in the MM functions that performs the split instead of the
caller passing the min_order. Probably, that is why this problem is
being exposed now where people are surprised by seeing a large folio
even though they asked to split folios to order-0.

As you concluded, we will not be breaking anything wrt LBS as we
just refuse to split if it doesn't match the min_order. The only issue I
see is we might be exacerbating ENOMEM errors as we are not splitting as
many folios with this change. But the solution for that is simple, add
more RAM to the system ;)

Just for clarity, are we talking about changing the behaviour just the
try_to_split_thp_page() function or all the split functions in huge_mm.h?

-- 
Pankaj