From: Greg KH on
On Wed, Dec 02, 2009 at 08:48:43AM +0200, Artem Bityutskiy wrote:
> From: Sebastian Andrzej Siewior <sebastian(a)breakpoint.cc>
>
> ubiupdatevol -t does the following:
> - ubi_start_update()
> - set_update_marker()
> - for all LEBs ubi_eba_unmap_leb()
> - clear_update_marker()
> - ubi_wl_flush()
>
> ubi_wl_flush() physically erases all PEB, once it returns all PEBs are
> empty. clear_update_marker() has the update marker written after return.
> If there is a power cut between the last two functions then the UBI
> volume has no longer the "update" marker set and may have some valid
> LEBs while some of them may be gone.
> If that volume in question happens to be a UBIFS volume, then mount
> will fail with
>
> |UBIFS error (pid 1361): ubifs_read_node: bad node type (255 but expected 6)
> |UBIFS error (pid 1361): ubifs_read_node: bad node at LEB 0:0
> |Not a node, first 24 bytes:
> |00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> if there is at least one valid LEB and the wear-leveling worker managed
> to clear LEB 0.
>
> The patch waits for the wl worker to finish prior clearing the "update"
> marker on flash. The two new LEB which are scheduled for erasing after
> clear_update_marker() should not matter because they are only visible to
> UBI.
>
> Signed-off-by: Sebastian Andrzej Siewior <sebastian(a)breakpoint.cc>
> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy(a)nokia.com>
> Cc: stable(a)kernel.org
> Cc: linux-kernel(a)vger.kernel.org
> ---
> drivers/mtd/ubi/upd.c | 20 +++++++++++---------


I'm not the mtd or ubi maintainer, so why did you send this to me?

confused,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Artem Bityutskiy on
On Wed, 2009-12-02 at 16:42 +0100, ext Greg KH wrote:
> On Wed, Dec 02, 2009 at 08:48:43AM +0200, Artem Bityutskiy wrote:
> > From: Sebastian Andrzej Siewior <sebastian(a)breakpoint.cc>
> >
> > ubiupdatevol -t does the following:
> > - ubi_start_update()
> > - set_update_marker()
> > - for all LEBs ubi_eba_unmap_leb()
> > - clear_update_marker()
> > - ubi_wl_flush()
> >
> > ubi_wl_flush() physically erases all PEB, once it returns all PEBs are
> > empty. clear_update_marker() has the update marker written after return.
> > If there is a power cut between the last two functions then the UBI
> > volume has no longer the "update" marker set and may have some valid
> > LEBs while some of them may be gone.
> > If that volume in question happens to be a UBIFS volume, then mount
> > will fail with
> >
> > |UBIFS error (pid 1361): ubifs_read_node: bad node type (255 but expected 6)
> > |UBIFS error (pid 1361): ubifs_read_node: bad node at LEB 0:0
> > |Not a node, first 24 bytes:
> > |00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >
> > if there is at least one valid LEB and the wear-leveling worker managed
> > to clear LEB 0.
> >
> > The patch waits for the wl worker to finish prior clearing the "update"
> > marker on flash. The two new LEB which are scheduled for erasing after
> > clear_update_marker() should not matter because they are only visible to
> > UBI.
> >
> > Signed-off-by: Sebastian Andrzej Siewior <sebastian(a)breakpoint.cc>
> > Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy(a)nokia.com>
> > Cc: stable(a)kernel.org
> > Cc: linux-kernel(a)vger.kernel.org
> > ---
> > drivers/mtd/ubi/upd.c | 20 +++++++++++---------
>
>
> I'm not the mtd or ubi maintainer, so why did you send this to me?

Sorry, I thought the protocol to get to -stable is to send to you and CC
stable. I maintain UBI and just wanted to send this patch to -stable. I
googled a bit and could not find the right way.

--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on
On Thu, Dec 03, 2009 at 09:01:45AM +0200, Artem Bityutskiy wrote:
> On Wed, 2009-12-02 at 16:42 +0100, ext Greg KH wrote:
> > On Wed, Dec 02, 2009 at 08:48:43AM +0200, Artem Bityutskiy wrote:
> > > From: Sebastian Andrzej Siewior <sebastian(a)breakpoint.cc>
> > >
> > > ubiupdatevol -t does the following:
> > > - ubi_start_update()
> > > - set_update_marker()
> > > - for all LEBs ubi_eba_unmap_leb()
> > > - clear_update_marker()
> > > - ubi_wl_flush()
> > >
> > > ubi_wl_flush() physically erases all PEB, once it returns all PEBs are
> > > empty. clear_update_marker() has the update marker written after return.
> > > If there is a power cut between the last two functions then the UBI
> > > volume has no longer the "update" marker set and may have some valid
> > > LEBs while some of them may be gone.
> > > If that volume in question happens to be a UBIFS volume, then mount
> > > will fail with
> > >
> > > |UBIFS error (pid 1361): ubifs_read_node: bad node type (255 but expected 6)
> > > |UBIFS error (pid 1361): ubifs_read_node: bad node at LEB 0:0
> > > |Not a node, first 24 bytes:
> > > |00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > >
> > > if there is at least one valid LEB and the wear-leveling worker managed
> > > to clear LEB 0.
> > >
> > > The patch waits for the wl worker to finish prior clearing the "update"
> > > marker on flash. The two new LEB which are scheduled for erasing after
> > > clear_update_marker() should not matter because they are only visible to
> > > UBI.
> > >
> > > Signed-off-by: Sebastian Andrzej Siewior <sebastian(a)breakpoint.cc>
> > > Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy(a)nokia.com>
> > > Cc: stable(a)kernel.org
> > > Cc: linux-kernel(a)vger.kernel.org
> > > ---
> > > drivers/mtd/ubi/upd.c | 20 +++++++++++---------
> >
> >
> > I'm not the mtd or ubi maintainer, so why did you send this to me?
>
> Sorry, I thought the protocol to get to -stable is to send to you and CC
> stable. I maintain UBI and just wanted to send this patch to -stable. I
> googled a bit and could not find the right way.

Look in the Documentation/stable_kernel_rules.txt that shows all you
need is the Cc: stable(a)kernel.org section in the Signed-off-by area like
you did.

So when this goes into Linus's tree, I'll automatically get it in the
right inbox and know to apply it to the -stable tree.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Artem Bityutskiy on
On Fri, 2009-12-04 at 02:58 +0100, ext Greg KH wrote:
> On Thu, Dec 03, 2009 at 09:01:45AM +0200, Artem Bityutskiy wrote:
> > On Wed, 2009-12-02 at 16:42 +0100, ext Greg KH wrote:
> > > On Wed, Dec 02, 2009 at 08:48:43AM +0200, Artem Bityutskiy wrote:
> > > > From: Sebastian Andrzej Siewior <sebastian(a)breakpoint.cc>
> > > >
> > > > ubiupdatevol -t does the following:
> > > > - ubi_start_update()
> > > > - set_update_marker()
> > > > - for all LEBs ubi_eba_unmap_leb()
> > > > - clear_update_marker()
> > > > - ubi_wl_flush()
> > > >
> > > > ubi_wl_flush() physically erases all PEB, once it returns all PEBs are
> > > > empty. clear_update_marker() has the update marker written after return.
> > > > If there is a power cut between the last two functions then the UBI
> > > > volume has no longer the "update" marker set and may have some valid
> > > > LEBs while some of them may be gone.
> > > > If that volume in question happens to be a UBIFS volume, then mount
> > > > will fail with
> > > >
> > > > |UBIFS error (pid 1361): ubifs_read_node: bad node type (255 but expected 6)
> > > > |UBIFS error (pid 1361): ubifs_read_node: bad node at LEB 0:0
> > > > |Not a node, first 24 bytes:
> > > > |00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > > >
> > > > if there is at least one valid LEB and the wear-leveling worker managed
> > > > to clear LEB 0.
> > > >
> > > > The patch waits for the wl worker to finish prior clearing the "update"
> > > > marker on flash. The two new LEB which are scheduled for erasing after
> > > > clear_update_marker() should not matter because they are only visible to
> > > > UBI.
> > > >
> > > > Signed-off-by: Sebastian Andrzej Siewior <sebastian(a)breakpoint.cc>
> > > > Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy(a)nokia.com>
> > > > Cc: stable(a)kernel.org
> > > > Cc: linux-kernel(a)vger.kernel.org
> > > > ---
> > > > drivers/mtd/ubi/upd.c | 20 +++++++++++---------
> > >
> > >
> > > I'm not the mtd or ubi maintainer, so why did you send this to me?
> >
> > Sorry, I thought the protocol to get to -stable is to send to you and CC
> > stable. I maintain UBI and just wanted to send this patch to -stable. I
> > googled a bit and could not find the right way.
>
> Look in the Documentation/stable_kernel_rules.txt that shows all you
> need is the Cc: stable(a)kernel.org section in the Signed-off-by area like
> you did.
>
> So when this goes into Linus's tree, I'll automatically get it in the
> right inbox and know to apply it to the -stable tree.

Oh, thanks a lot!

--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/