Re: [PATCH v9 2/8] mm/huge_memory: add two new (not yet used) functions for folio_split()

[Hugh Dickins <hughd@google.com>]

On Wed, 5 Mar 2025, Zi Yan wrote:
> On 5 Mar 2025, at 15:50, Hugh Dickins wrote:
> >
> > (Historically, there was quite a lot of difficulty in getting the order
> > of events in __split_huge_page_tail() to be safe: I wonder whether we
> > shall see a crop of new weird bugs from these changes. I note that your
> > loops advance forwards, whereas the old ones went backwards: but I don't
> > have anything to say you're wrong.  I think it's mainly a matter of how
> > the first tail or two gets handled: which might be why you want to
> > folio_set_order(folio, new_order) at the earliest opportunity.)
> 
> I am worried about that too. In addition, in __split_huge_page_tail(),
> page refcount is restored right after new tail folio split is done,
> whereas I needed to delay them until all new after-split folios
> are done, since non-uniform split is iterative and only the after-split
> folios NOT containing the split_at page will be released. These
> folios are locked and frozen after __split_folio_to_order() like
> the original folio. Maybe because there are more such locked frozen
> folios than before?

Sorry, I gave up trying to work out what you're asking me there.
Let's assume I don't know the answer.

Hugh