linux-kernel - Re: [GIT PULL] mtd: Changes for v5.13-rc4

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, 26 May 2021 18:46:12 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-mtd <linux-mtd@...ts.infradead.org>,
        Richard Weinberger <richard@....at>,
        Tudor Ambarus <Tudor.Ambarus@...rochip.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Frieder Schrempf <frieder.schrempf@...tron.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] mtd: Changes for v5.13-rc4

Hi Linus,

Linus Torvalds <torvalds@...ux-foundation.org> wrote on Wed, 26 May
2021 06:20:35 -1000:

> On Wed, May 26, 2021 at 5:59 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> >
> > Raw NAND:
> > * txx9ndfmc, tmio, sharpsl, ndfc, lpc32xx_slc, fsmc, cs553x:
> >   - Fix external use of SW Hamming ECC helper  
> 
> Why are these guys all pointlessly duplicating the ecc wrapper
> functions for their ecc 'correct' functions?
> 
> The whole "the Hamming software ECC engine has been updated to become
> a proper and independent ECC engine" excuse makes no sense. If
> multiple chips just want a basic sw hamming helper, then they should
> have one. Not have to be forced to each write their own pointless
> wrapper like this.
> 
> These chip drivers just want 'ecc_sw_hamming_correct()' with the
> proper arguments, and it seems entirely wrong to duplicate the helper
> five times or whatever. There should just be a generic helper - the
> way there used to be.
> 
> In fact, I would generally strongly recommend that if there used to be
> a generic helper that different chip drivers used (ie the old
> rawnand_sw_hamming_correct()), then such a helper should be left alone
> and not change the semantics of it.

I am not happy neither with the fix (which I wrote myself) as my first
goal was to uniformize the way the Hamming helpers are being called (as
part of a much bigger work). I assumed that all drivers either used the
Hamming software engine or simply didn't, without thinking about the
"intermediate" situations where a particular driver would just want to
call a particular Hamming helper to workaround its "missing" hardware
capabilities.

Unfortunately when I spotted that many drivers were broken by my rework
I decided to provide per-driver fixes, while, as you suggest, I should
probably have declared a generic 'hamming correct' core helper and use
that directly instead of duplicating the logic in each broken driver.

> The new "proper independent ECC engine" that had new semantics should
> have been the one that got a new name, rather than breaking an old and
> existing helper function and then making the chip drivers pointlessly
> write their own new helper functions.
> 
> I've pulled this, but under protest. The patch honestly just looks
> like mindless duplication.

Thanks.

Miquèl