linux-kernel - Re: [PATCH] mm/huge_memory: move writeback and truncation checks early

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]

Date: Thu, 25 Apr 2024 11:40:48 +0200
From: David Hildenbrand <david@...hat.com>
To: Luis Chamberlain <mcgrof@...nel.org>, akpm@...ux-foundation.org,
 ziy@...dia.com, linux-mm@...ck.org
Cc: fstests@...r.kernel.org, linux-xfs@...r.kernel.org,
 linux-kernel@...r.kernel.org, willy@...radead.org, hare@...e.de,
 john.g.garry@...cle.com, p.raghav@...sung.com, da.gomez@...sung.com
Subject: Re: [PATCH] mm/huge_memory: move writeback and truncation checks
 early

On 25.04.24 00:57, Luis Chamberlain wrote:
> We should check as early as possible if we should bail due to writeback
> or truncation. This will allow us to add further sanity checks earlier
> as well.
> 
> This introduces no functional changes.
> 
> Signed-off-by: Luis Chamberlain <mcgrof@...nel.org>
> ---
>   mm/huge_memory.c | 23 +++++++++++------------
>   1 file changed, 11 insertions(+), 12 deletions(-)
> 
> While working on min order support for LBS this came up as an improvement
> as we can check for the min order early earlier, so this sets the stage
> up for that.
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 86a8c7b3b8dc..32c701821e0d 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3055,8 +3055,17 @@ int split_huge_page_to_list_to_order(struct page *page, struct list_head *list,
>   	if (new_order >= folio_order(folio))
>   		return -EINVAL;
>   
> -	/* Cannot split anonymous THP to order-1 */
> -	if (new_order == 1 && folio_test_anon(folio)) {
> +	if (folio_test_writeback(folio))
> +		return -EBUSY;
> +

Why earlier than basic input parameter checks (new_order?

Sorry, but I don't see the reason for that change. It's all happening 
extremely early, what are we concerned about?

It's likely better to send that patch with the actual patch "to add 
further sanity checks earlier as well", and why they have to be that early.

-- 
Cheers,

David / dhildenb