[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