lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <996d8153-a69a-4075-aa1a-945ffe3630e9@gmail.com>
Date: Sat, 6 Dec 2025 17:36:06 +0000
From: Usama Arif <usamaarif642@...il.com>
To: Kiryl Shutsemau <kas@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Muchun Song <muchun.song@...ux.dev>, David Hildenbrand <david@...nel.org>,
 Oscar Salvador <osalvador@...e.de>, Mike Rapoport <rppt@...nel.org>,
 Vlastimil Babka <vbabka@...e.cz>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Matthew Wilcox <willy@...radead.org>, Zi Yan <ziy@...dia.com>,
 Baoquan He <bhe@...hat.com>, Michal Hocko <mhocko@...e.com>,
 Johannes Weiner <hannes@...xchg.org>, Jonathan Corbet <corbet@....net>,
 kernel-team@...a.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org
Subject: Re: [PATCH 04/11] mm: Rework compound_head() for power-of-2
 sizeof(struct page)


>> hmm my understanding reviewing up until this patch of the series is that everything works
>> the same as old code when struct page is not a power of 2. Returning page here means you dont
>> fix page head when sizeof(struct page) is not a power of 2?
> 
> There's no change for non-power-of-2 sizeof(struct page) as there's no
> fake heads because there's no HVO for such cases.


Yeah, I forgot that while reviewing :). I see its mentioned in vmemmap_dedup.rst as well.
I think might be good to add a reminder in the commit message that HVO doesn't apply to
non-power-of-2 sizeof(struct page), but no strong preference :)

> 
> See hugetlb_vmemmap_optimizable_size() as I mentioned in the comment.
> 
>>
>>>  	/*
>>>  	 * Only addresses aligned with PAGE_SIZE of struct page may be fake head
>>>  	 * struct page. The alignment check aims to avoid access the fields (
>>> @@ -223,10 +230,13 @@ static __always_inline const struct page *page_fixed_fake_head(const struct page
>>>  		 * because the @page is a compound page composed with at least
>>>  		 * two contiguous pages.
>>>  		 */
>>> -		unsigned long head = READ_ONCE(page[1].compound_info);
>>> +		unsigned long info = READ_ONCE(page[1].compound_info);
>>>  
>>> -		if (likely(head & 1))
>>> -			return (const struct page *)(head - 1);
>>> +		if (likely(info & 1)) {
>>> +			unsigned long p = (unsigned long)page;
>>> +
>>> +			return (const struct page *)(p & info);
>>
>> Would it be worth writing a comment over here similar to what you have in set_compound_head
>> to explain why this works? i.e. compound_info contains the mask derived from folio order that
>> can be applied to the virtual address to get the head page.
> 
> But this code is about to be deleted. Is it really worth it?

Ack, hadn't gotten to that commit.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ