From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Richard Weinberger" <richard.weinberger@gmail.com>,
"Jörg Pfähler" <pfaehler@isse.de>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: UBI: recover_peb and power cut safety
Date: Fri, 17 Jun 2016 09:37:20 +0300 [thread overview]
Message-ID: <1466145440.15435.2.camel@gmail.com> (raw)
In-Reply-To: <CAFLxGvwydtMa3wizdfC1K1Ti2pn=OuJ9UF2wTMFqt-kw2xFO3g@mail.gmail.com>
On Thu, 2016-06-16 at 12:03 +0200, Richard Weinberger wrote:
> Forgot to CC Artem.
>
> On Thu, Jun 16, 2016 at 11:46 AM, Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
> >
> > Jörg,
> >
> > On Thu, Jun 16, 2016 at 10:37 AM, Jörg Pfähler <pfaehler@isse.de>
> > wrote:
> > >
> > > Hi,
> > >
> > > I would greatly appreciate some clarification with respect to
> > > power cut safety
> > > during writing of an erase block in UBI, specifically power cut
> > > safety of
> > > recover_peb.
> > >
> > > During a normal write operation (ubi_eba_write_leb in
> > > mtd/ubi/eba.c) UBI tries
> > > to move the contents of the block (and the new contents) to a new
> > > location via
> > > recover_peb, if the write fails. However, recover_peb does not
> > > seem to use the
> > > capability to exchange the (logical) block atomically (as
> > > ubi_eba_atomic_leb_change in mtd/ubi/eba.c does). Specifically,
> > > it does not
> > > seem to write the amount of data and its checksum to the VID
> > > header. Thus, if
> > > the system crashes in the middle of recover_peb before the
> > > old/broken block
> > > could be erased, we are left with a newer version of the block
> > > (the sequence
> > > number in the header is increased by recover_peb), but without
> > > having moved
> > > all the contents of the old block. This would obviously lead to
> > > data loss.
> > > Thus, It seems to me that recover_peb (and therefore
> > > ubi_eba_write_leb) is not
> > > power cut safe or is there some other mechanism distinct from the
> > > one used by
> > > ubi_eba_atomic_leb_change to achieve this? If not I would suggest
> > > using
> > > ubi_eba_atomic_leb_change in ubi_eba_write_leb instead of
> > > recover_peb.
> > Hmm, you are right, if ubi_eba_write() is facing -EIO from the MTD
> > driver we can
> > lose the whole erase block upon power cut.
> > So you found a bug. :-)
> >
> > Artem, can you tell more on this?
> > I'd guess that recover_peb() is older than
> > ubi_eba_atomic_leb_change() and
> > therefore it was not used.
> > And nobody noticed so far since the condition is hard to hit.
> >
> > That said, switching to ubi_eba_atomic_leb_change() seems like a
> > good
> > plan to me.
> > Jörg, please send a patch and explain how you tested it.
Yes indeed, very bad bug, good catch.
next prev parent reply other threads:[~2016-06-17 6:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 8:37 UBI: recover_peb and power cut safety Jörg Pfähler
2016-06-16 9:46 ` Richard Weinberger
2016-06-16 10:03 ` Richard Weinberger
2016-06-17 6:37 ` Artem Bityutskiy [this message]
2016-06-20 13:48 ` Jörg Pfähler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1466145440.15435.2.camel@gmail.com \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=pfaehler@isse.de \
--cc=richard.weinberger@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.