linux-kernel - Re: [PATCHv2 1/2] arm: Cleanup sanity_check

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 5 Jan 2017 23:17:25 -0500 (EST)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Laura Abbott <labbott@...hat.com>
cc:     Russell King <rmk+kernel@...linux.org.uk>,
        Grygorii Strashko <grygorii.strashko@...com>,
        linux-arm-kernel@...ts.infradead.org, lilja.magnus@...il.com,
        festevam@...il.com, linux-kernel@...r.kernel.org,
        Laura Abbott <lauraa@...eaurora.org>
Subject: Re: [PATCHv2 1/2] arm: Cleanup sanity_check_meminfo

On Thu, 5 Jan 2017, Laura Abbott wrote:

> 
> The logic for sanity_check_meminfo has become difficult to
> follow. Clean up the code so it's more obvious what the code
> is actually trying to do. Additionally, meminfo is now removed
> so rename the function to better describe it's purpose.

s/it's/its/

> Signed-off-by: Laura Abbott <lauraa@...eaurora.org>
> Signed-off-by: Laura Abbott <labbott@...hat.com>
> ---
> v2: Fixed code so b9a019899f61 ("ARM: 8590/1: sanity_check_meminfo():
> avoid overflow on vmalloc_limit") should stay fixed. The casting and assignment
> still seem ugly.

Are you referring to the initial vmalloc_limit assignment?

> @@ -1172,43 +1170,19 @@ void __init sanity_check_meminfo(void)
>  	for_each_memblock(memory, reg) {
>  		phys_addr_t block_start = reg->base;
>  		phys_addr_t block_end = reg->base + reg->size;
> -		phys_addr_t size_limit = reg->size;
>  
> -		if (reg->base >= vmalloc_limit)
> -			highmem = 1;
> -		else
> -			size_limit = vmalloc_limit - reg->base;
>  
> -
[...]

This leaves a spurious empty line. One was already there before your 
patch but this would be a good opportunity to remove it.

Other than that...

Reviewed-by: Nicolas Pitre <nico@...aro.org>


Nicolas