linux-kernel - RE: [PATCH 3/3] mtd: spinand: Wait for the erase op to finish before writing a bad block marker

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] [day] [month] [year] [list]

Date:   Mon, 17 Feb 2020 11:30:18 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Schrempf Frieder' <frieder.schrempf@...tron.de>,
        Miquel Raynal <miquel.raynal@...tlin.com>
CC:     Boris Brezillon <bbrezillon@...nel.org>,
        Jeff Kletsky <git-commits@...ycomm.com>,
        liaoweixiong <liaoweixiong@...winnertech.com>,
        Peter Pan <peterpandong@...ron.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        Richard Weinberger <richard@....at>
Subject: RE: [PATCH 3/3] mtd: spinand: Wait for the erase op to finish before
 writing a bad block marker

From: Schrempf Frieder
> Sent: 17 February 2020 11:19
> > Schrempf Frieder <frieder.schrempf@...tron.de> wrote on Tue, 11 Feb
> > 2020 16:35:53 +0000:
> >
> >> From: Frieder Schrempf <frieder.schrempf@...tron.de>
> >>
> >> Currently when marking a block, we use spinand_erase_op() to erase
> >> the block before writing the marker to the OOB area without waiting
> >> for the operation to succeed. This can lead to the marking failing
> >> silently and no bad block marker being written to the flash.
> >>
> >> To fix this we reuse the spinand_erase() function, that already does
> >> everything we need to do before actually writing the marker.
> >>
> >
> > Thanks a lot for this series!
> >
> > Yet I don't really understand the point of waiting for the erasure if
> > it failed: we don't really care as programming (1 -> 0) cells is always
> > possible. Are you sure this lead to an error?
> 
> We don't care about the result of the erase operation, but I think we
> still need to wait for it to be done and the STATUS_BUSY bit to be
> cleared. Otherwise it seems like the program operation to set the marker
> can get ignored by the chip. At least that's my explanation for the
> behavior I was observing.

Serial flash devices won't allow any accesses while an erase or write
in in progress.
So while you don't need to wait for either to finish, you do need
to remember that one is 'pending' and wait for it to finish
before any further accesses (apart from reads of the status register).

How many writes you can do to an area (that clear 1s) and the size
of the area will be device dependant.
IIRC one device I've used allows 2 writes to each 16bit word.
This allows either two separate byte writes or one write of
a 16bit (or 32bit) value followed by a second write of all 0s
the 'erase' the value without doing a erase-rewrite cycle.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)