All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@sigma-star.at>
To: Martin Townsend <mtownsend1973@gmail.com>
Cc: hs@denx.de, u-boot@lists.denx.de, kmpark@infradead.org,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH] ubi: Fix filesystem corruption on detach when fastmap enabled
Date: Wed, 17 Jan 2018 16:47:15 +0100	[thread overview]
Message-ID: <1612877.xbAM7MeHb7@blindfold> (raw)
In-Reply-To: <CABatt_y_6D+unmRT_L3nScxN=RnPuAxSiykSwPkwNp6298OakQ@mail.gmail.com>

Martin,

Am Dienstag, 16. Januar 2018, 15:13:04 CET schrieb Martin Townsend:
> > Martin, can you please explain what corruption you see?
> > From reading the code I'd assume that you miss volumes but a full scan
> > would recover everything.
> 
> I didn't do much analysis of the corruption I'm afraid.  When I tried
> to reattach the the c->empty flag was set to true and indeed all the
> EBA tables were reporting an empty filesystem even after a reboot.

Sounds like what I'd expect.

> Not sure if this was recoverable, how do you trigger a full scan?

Booting a kernel without Fastmap support. B-)

> > For Linux I suggest this fix:
> > 
> > From 48287459cf8717cffac5aed423937cd7ba4360ab Mon Sep 17 00:00:00 2001
> > From: Richard Weinberger <richard@nod.at>
> > Date: Tue, 16 Jan 2018 14:12:46 +0100
> > Subject: [PATCH] ubi: fastmap: Don't flush fastmap work on detach
> > 
> > At this point UBI volumes have already been free()'ed and fastmap can no
> > longer access these data structures.
> > 
> > Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL
> > sub- system")
> > Signed-off-by: Richard Weinberger <richard@nod.at>
> > Cc: stable@vger.kernel.org
> > ---
> > 
> >  drivers/mtd/ubi/fastmap-wl.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/mtd/ubi/fastmap-wl.c b/drivers/mtd/ubi/fastmap-wl.c
> > index 4f0bd6b4422a..69dd21679a30 100644
> > --- a/drivers/mtd/ubi/fastmap-wl.c
> > +++ b/drivers/mtd/ubi/fastmap-wl.c
> > @@ -362,7 +362,6 @@ static void ubi_fastmap_close(struct ubi_device *ubi)
> > 
> >  {
> >  
> >         int i;
> > 
> > -       flush_work(&ubi->fm_work);
> > 
> >         return_unused_pool_pebs(ubi, &ubi->fm_pool);
> >         return_unused_pool_pebs(ubi, &ubi->fm_wl_pool);
> > 
> > --
> > 2.13.6
> > 
> > In U-Boot you can do the same.
>
> Richard: This will work but just want to check that ubi_wl_close is
> supposed to never write out to the filesystem or will never do so in
> future, if so maybe a something in the comments above ubi_wl_close to
> ensure this?

Hmm, not sure if I got this question.
The filesystem sits above UBI. If we reach ubi_wl_close() all users ontop of 
UBI are gone. There is no UBIFS mounted anymore.

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@sigma-star.at>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ubi: Fix filesystem corruption on detach when fastmap enabled
Date: Wed, 17 Jan 2018 16:47:15 +0100	[thread overview]
Message-ID: <1612877.xbAM7MeHb7@blindfold> (raw)
In-Reply-To: <CABatt_y_6D+unmRT_L3nScxN=RnPuAxSiykSwPkwNp6298OakQ@mail.gmail.com>

Martin,

Am Dienstag, 16. Januar 2018, 15:13:04 CET schrieb Martin Townsend:
> > Martin, can you please explain what corruption you see?
> > From reading the code I'd assume that you miss volumes but a full scan
> > would recover everything.
> 
> I didn't do much analysis of the corruption I'm afraid.  When I tried
> to reattach the the c->empty flag was set to true and indeed all the
> EBA tables were reporting an empty filesystem even after a reboot.

Sounds like what I'd expect.

> Not sure if this was recoverable, how do you trigger a full scan?

Booting a kernel without Fastmap support. B-)

> > For Linux I suggest this fix:
> > 
> > From 48287459cf8717cffac5aed423937cd7ba4360ab Mon Sep 17 00:00:00 2001
> > From: Richard Weinberger <richard@nod.at>
> > Date: Tue, 16 Jan 2018 14:12:46 +0100
> > Subject: [PATCH] ubi: fastmap: Don't flush fastmap work on detach
> > 
> > At this point UBI volumes have already been free()'ed and fastmap can no
> > longer access these data structures.
> > 
> > Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL
> > sub- system")
> > Signed-off-by: Richard Weinberger <richard@nod.at>
> > Cc: stable at vger.kernel.org
> > ---
> > 
> >  drivers/mtd/ubi/fastmap-wl.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/mtd/ubi/fastmap-wl.c b/drivers/mtd/ubi/fastmap-wl.c
> > index 4f0bd6b4422a..69dd21679a30 100644
> > --- a/drivers/mtd/ubi/fastmap-wl.c
> > +++ b/drivers/mtd/ubi/fastmap-wl.c
> > @@ -362,7 +362,6 @@ static void ubi_fastmap_close(struct ubi_device *ubi)
> > 
> >  {
> >  
> >         int i;
> > 
> > -       flush_work(&ubi->fm_work);
> > 
> >         return_unused_pool_pebs(ubi, &ubi->fm_pool);
> >         return_unused_pool_pebs(ubi, &ubi->fm_wl_pool);
> > 
> > --
> > 2.13.6
> > 
> > In U-Boot you can do the same.
>
> Richard: This will work but just want to check that ubi_wl_close is
> supposed to never write out to the filesystem or will never do so in
> future, if so maybe a something in the comments above ubi_wl_close to
> ensure this?

Hmm, not sure if I got this question.
The filesystem sits above UBI. If we reach ubi_wl_close() all users ontop of 
UBI are gone. There is no UBIFS mounted anymore.

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y

  reply	other threads:[~2018-01-17 15:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 19:03 [U-Boot] [PATCH] ubi: Fix filesystem corruption on detach when fastmap enabled Martin Townsend
2018-01-15 11:30 ` Heiko Schocher
2018-01-15 12:13   ` Martin Townsend
2018-01-16  5:43     ` Heiko Schocher
2018-01-16  9:11       ` Martin Townsend
2018-01-16 13:22         ` Richard Weinberger
2018-01-16 14:13           ` Martin Townsend
2018-01-17 15:47             ` Richard Weinberger [this message]
2018-01-17 15:47               ` Richard Weinberger
2018-01-17 22:02               ` Martin Townsend
2018-01-17 22:02                 ` [U-Boot] " Martin Townsend

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=1612877.xbAM7MeHb7@blindfold \
    --to=richard@sigma-star.at \
    --cc=hs@denx.de \
    --cc=kmpark@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mtownsend1973@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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.