On 2/23/26 15:14, David Hildenbrand (Arm) wrote: > On 2/23/26 15:06, Christian König wrote: >> On 2/23/26 14:46, Christoph Hellwig wrote: >>> On Sun, Feb 22, 2026 at 10:26:30PM -0500, Zi Yan wrote: >>>> Hi all, >>>> >>>> Based on a recent discussion with David Hildenbrand on page->private >>>> is not zero when a page is freed[1], this patchset is trying to fix all >>>> users do not zero ->private when freeing a page and add checks to make >>>> sure all freed pages have ->private set to zero. For compound pages, >>>> both head page and tail pages need to have ->private set to zero. >>> >>> Requiring the user to clear a field before freeing is just a way to >>> awkward interface. Don't do that. >> >> Completely agree. This is just asking for trouble. >> >> The cache line(s) backing this struct page are most likely accessed anyway >> on free/alloc. So I don't see much extra overhead. > > I think the question is more around handling non-head pages when freeing > larger orders. But maybe the overhead of zeroing page->private it there as > well in __free_pages_prepare() is tolerable.
Good point, sounds like that is a bit more than I thought it would be. > I'll note, though, that we already require page->mapping and page->memcg_data > of pages to be zeroed by the caller, so it's not completely crazy. (see > page_expected_state) Well that's not defensive at all, basically everybody which forgets to do that can cause hard to debug trouble. Maybe that practice should be reconsidered. Regards, Christian.
