On Fri, Jan 16, 2026 at 08:17:22PM +0100, Vlastimil Babka wrote: > >> +#ifdef NR_PAGES_IN_LARGE_FOLIO > >> + /* > >> + * This pointer math looks odd, but new_page could have been > >> + * part of a previous higher order folio, which sets _nr_pages > >> + * in page + 1 (new_page). Therefore, we use pointer casting to > >> + * correctly locate the _nr_pages bits within new_page which > >> + * could have modified by previous higher order folio. > >> + */ > >> + ((struct folio *)(new_page - 1))->_nr_pages = 0; > >> +#endif > > > > This seems too weird, why is it in the loop? There is only one > > _nr_pages per folio. > > I suppose we could be getting say an order-9 folio that was previously used > as two order-8 folios? And each of them had their _nr_pages in their head > and we can't know that at this point so we have to reset everything?
Er, did I miss something - who reads _nr_pages from a random tail page? Doesn't everything working with random tail pages read order, compute the head page, cast to folio and then access _nr_pages? > Or maybe you mean that stray _nr_pages in some tail page from previous > lifetimes can't affect the current lifetime in a wrong way for something > looking at said page? I don't know immediately. Yes, exactly. Basically, what bytes exactly need to be set to what in tail pages for the system to work? Those should be set. And if we want to have things set on free that's fine too, but there should be reasons for doing stuff, and this weird thing above makes zero sense. Jason
