linux-kernel - Re: [PATCH] mm/hugetlb: Convert &folio->page to folio

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: <D92A9T1LIKBC.1V2UOQWI6BVY4@nvidia.com>
Date: Wed, 09 Apr 2025 13:27:55 -0400
From: "Zi Yan" <ziy@...dia.com>
To: "Matthew Wilcox" <willy@...radead.org>, <nifan.cxl@...il.com>
Cc: <muchun.song@...ux.dev>, <mcgrof@...nel.org>,
 <a.manzanares@...sung.com>, <dave@...olabs.net>,
 <akpm@...ux-foundation.org>, <david@...hat.com>, <linux-mm@...ck.org>,
 <linux-kernel@...r.kernel.org>, "Fan Ni" <fan.ni@...sung.com>
Subject: Re: [PATCH] mm/hugetlb: Convert &folio->page to folio_page(folio,
 0)

On Tue Apr 8, 2025 at 11:15 PM EDT, Matthew Wilcox wrote:
> On Tue, Apr 08, 2025 at 05:49:10PM -0700, nifan.cxl@...il.com wrote:
>> From: Fan Ni <fan.ni@...sung.com>
>> 
>> Convert the use of &folio->page to folio_page(folio, 0) where struct
>> filio fits in. This is part of the efforts to move some fields out of
>> struct page to reduce its size.
>
> Thanks for sending the patch.  You've mixed together quite a few things;
> I'd suggest focusing on one API at a time.
>
<snip>

>> @@ -3403,7 +3405,7 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>>  	if (new_order)
>>  		folio_set_order(folio, new_order);
>>  	else
>> -		ClearPageCompound(&folio->page);
>> +		ClearPageCompound(folio_page(folio, 0));
>>  }
>
> I might be inclined to leave this one alone; this whole function needs
> to be rewritten as part of the folio split.

You mean __split_folio_to_order() needs a rewrite or
a folio version of ClearPageCompound()? Some thing like
__folio_clear_compound()?

>
>>  		folio_split_memcg_refs(folio, old_order, split_order);
>> -		split_page_owner(&folio->page, old_order, split_order);
>> +		split_page_owner(folio_page(folio, 0), old_order, split_order);
>>  		pgalloc_tag_split(folio, old_order, split_order);
>
> Not sure if split_folio_owner is something that should exist.  Haven't
> looked into it.

page owner info seems to be per page, but it should be OK to have
split_folio_owner() and do page level operations inside.

>
>>  		 */
>> -		free_page_and_swap_cache(&new_folio->page);
>> +		free_page_and_swap_cache(folio_page(new_folio, 0));
>>  	}
>
> free_page_and_swap_cache() should be converted to be
> free_folio_and_swap_cache().
>
>>  
>> -	return __folio_split(folio, new_order, &folio->page, page, list, true);
>> +	return __folio_split(folio, new_order, folio_page(folio, 0), page,
>> +			     list, true);
>>  }
>
> Probably right.

Yes, this is uniform split, using first page as split_at works.

>
>>  {
>> -	return __folio_split(folio, new_order, split_at, &folio->page, list,
>> -			false);
>> +	return __folio_split(folio, new_order, split_at, folio_page(folio, 0),
>> +			     list, false);
>>  }
>
> Ditto.

Right. For non-uniform split, caller holds the folio lock, so lock_at,
which tells the folio containing lock_at to keep locked when returning to caller,
is the first page.

>
>>  
>> -	return split_huge_page_to_list_to_order(&folio->page, list, ret);
>> +	return split_huge_page_to_list_to_order(folio_page(folio, 0), list,
>> +						ret);
>>  }
>
> Ditto.

Yes. And there are two additional instances in include/linux/huge_mm.h
(Yeah, the header file of mm/huge_memory.c is huge_mm.h).


-- 
Best Regards,
Yan, Zi