linux-kernel - Re: [PATCH] mm/page_isolation: do not isolate the max order page

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: <29022300-6d8e-0532-7abc-6d11ab1db04a@redhat.com>
Date:   Thu, 3 Dec 2020 17:26:31 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Vlastimil Babka <vbabka@...e.cz>,
        Muchun Song <songmuchun@...edance.com>,
        akpm@...ux-foundation.org
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [PATCH] mm/page_isolation: do not isolate the max order page

On 03.12.20 01:03, Vlastimil Babka wrote:
> On 12/2/20 1:21 PM, Muchun Song wrote:
>> The max order page has no buddy page and never merge to other order.
>> So isolating and then freeing it is pointless.
>>
>> Signed-off-by: Muchun Song <songmuchun@...edance.com>
> 
> Acked-by: Vlastimil Babka <vbabka@...e.cz>
> 
>> ---
>>  mm/page_isolation.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
>> index a254e1f370a3..bddf788f45bf 100644
>> --- a/mm/page_isolation.c
>> +++ b/mm/page_isolation.c
>> @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype)
>>  	 */
>>  	if (PageBuddy(page)) {
>>  		order = buddy_order(page);
>> -		if (order >= pageblock_order) {
>> +		if (order >= pageblock_order && order < MAX_ORDER - 1) {
>>  			pfn = page_to_pfn(page);
>>  			buddy_pfn = __find_buddy_pfn(pfn, order);
>>  			buddy = page + (buddy_pfn - pfn);
> 
> Hm I wonder if order == MAX_ORDER - 1, then the buddy can actually be a
> !pfn_valid() in some corner case? pfn_valid_within(buddy_pfn) that follows would
> only catch it on archs with holes in zone. Then is_migrate_isolate_page(buddy)
> might access an invalid buddy. So this might be actually a bug fix and not just
> optimization, just the bug hasn't been observed in practice.

I think we have no users that isolate/unisolate close to holes.

CMA regions are properly aligned (to max of page_order /
max_order_nr_pages) and don't contain holes.

virtio-mem does not apply as it knows its range has no holes.

gigantic pages are aligned naturally and we check that there are no
holes upfront.

There are no other users.


I don't see a need for stable/fixes.

-- 
Thanks,

David / dhildenb