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
