Re: [PATCH v1 00/11] Zero page->private when freeing pages

[David Hildenbrand (Arm)]

On 2/23/26 16:22, Christian König wrote:
> On 2/23/26 15:14, David Hildenbrand (Arm) wrote:
> > On 2/23/26 15:06, Christian König wrote:
> > > 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.

Right. We already iterate over all "tail" pages in 
__free_pages_prepare() to clear page flags

	(page + i)->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;

Maybe zeroing page->private there is not too bad.

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

Right, we do have check_pages= to activate the page_expected_state() 
checks, where we will detect such problems.

(including the mapcount being -1 etc.)

--
Cheers,

David