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
