linux-kernel - Re: [PATCH 1/1] mm/page_poison: slightly optimize check_poison

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: <8d40e74e-c68b-4f94-ae1e-42c4430d55e2@redhat.com>
Date: Wed, 21 Aug 2024 13:28:08 +0200
From: David Hildenbrand <david@...hat.com>
To: Zhen Lei <thunder.leizhen@...wei.com>,
 Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] mm/page_poison: slightly optimize check_poison_mem()

On 21.08.24 09:53, Zhen Lei wrote:
> When the debug information needs to be suppressed due to ratelimit,
> it is unnecessary to determine the end of the corrupted memory.
> 
> Signed-off-by: Zhen Lei <thunder.leizhen@...wei.com>
> ---
>   mm/page_poison.c | 7 ++++---
>   1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/page_poison.c b/mm/page_poison.c
> index 3e9037363cf9d85..23fa799214720f1 100644
> --- a/mm/page_poison.c
> +++ b/mm/page_poison.c
> @@ -55,14 +55,15 @@ static void check_poison_mem(struct page *page, unsigned char *mem, size_t bytes
>   	if (!start)
>   		return;
>   
> +	if (!__ratelimit(&ratelimit))
> +		return;
> +
>   	for (end = mem + bytes - 1; end > start; end--) {
>   		if (*end != PAGE_POISON)
>   			break;
>   	}
>   
> -	if (!__ratelimit(&ratelimit))
> -		return;
> -	else if (start == end && single_bit_flip(*start, PAGE_POISON))
> +	if (start == end && single_bit_flip(*start, PAGE_POISON))
>   		pr_err("pagealloc: single bit error\n");
>   	else
>   		pr_err("pagealloc: memory corruption\n");

This way, you will be ratelimiting on every function call, possibly 
skipping PAGE_POISON checks even if there was no prior corruption detected?

-- 
Cheers,

David / dhildenb