linux-kernel - Re: [PATCH] nand_base: optimize checking of erased buffers

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:   Wed, 17 May 2017 13:39:16 +0200
From:   Mason <slash.tmp@...e.fr>
To:     Pavel Machek <pavel@....cz>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>
Cc:     Richard Weinberger <richard@....at>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        mark.marshall@...cronenergy.com, b44839@...escale.com,
        prabhakar@...escale.com
Subject: Re: [PATCH] nand_base: optimize checking of erased buffers

On 17/05/2017 13:27, Mason wrote:

> On 21/04/2017 12:51, Pavel Machek wrote:
> 
>> If we see ~0UL in flash, there's no need for hweight, and no need to
>> check number of bitflips. So this should be net win.
>>
>> Signed-off-by: Pavel Machek <pavel@...x.de>
>>
>> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
>> index b0524f8..96c27ec 100644
>> --- a/drivers/mtd/nand/nand_base.c
>> +++ b/drivers/mtd/nand/nand_base.c
>> @@ -1357,7 +1357,10 @@ static int nand_check_erased_buf(void *buf, int len, int bitflips_threshold)
>>  
>>  	for (; len >= sizeof(long);
>>  	     len -= sizeof(long), bitmap += sizeof(long)) {
>> -		weight = hweight_long(*((unsigned long *)bitmap));
> 
> I hadn't noticed this earlier. There is, obviously, an implicit
> requirement that 'buf' must be 4-byte aligned on 32-bit platforms,
> and 8-byte aligned on 64-bit platforms.
> 
> This is not true for my platform, as the ecc pointer is
> chip->oob_poi + 10

Doh! As Boris points out, the prologue/epilogue handle
all alignment & size issues.

Regards.