From: "Bityutskiy, Artem" <artem.bityutskiy@intel.com>
To: "richard@nod.at" <richard@nod.at>
Cc: "dedekind1@gmail.com" <dedekind1@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 1/4] UBI: Ensure that all fastmap work is done upon WL shutdown
Date: Tue, 30 Sep 2014 07:53:40 +0000 [thread overview]
Message-ID: <1412063620.2379.12.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <542A548A.7040308@nod.at>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2310 bytes --]
On Tue, 2014-09-30 at 08:58 +0200, Richard Weinberger wrote:
> Am 30.09.2014 08:26, schrieb Artem Bityutskiy:
> > On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
> >> ...otherwise the deferred work might run after datastructures
> >> got freed and corrupt memory.
> >
> > How can this happend? The background thread is stopped by this time
> > already, so what are the other possibilities? And why is this
> > fastmap-only?
>
> This has nothing do to with the background thread.
> Fastmap has a work queue. If one fastmap work has been
> scheuled we have to wait for it.
I expected a bit more explanation. But OK, here is what I think.
UBI consists of subsystems. Subsystems try to be more or less
independent, whenever possible. They expose interface functions for
other subsystems. Of course the split is not ideal, but we do our best.
* wl.c does wear-levelling.
* wl.c does not do fastmap.
* fastmap.c does fastmap.
* I am unhappy seeing yet another ifdef to wl.c
* I am unhappy seeing wl.c calling 'flush_work(&ubi->fm_work)', because
fastmap.c should deal with 'fm_work'. Or said differently, wl.c is not a
fastmap queue baby-sitter. fastmap.c is.
Most UB subsystems have the init and close function. May be adding one
for fastmap would help? Then you could flush whatever from
'ubi_wl_close()' ?
Historically the work queue was implemented in wl.c because wl.c was the
only user of it.
If this layout is not good enough, we should probably extend it, may be
separate work queue management out of wl.c.
But populating wl.c with macros and little "take care of this fatmap
bit" stuff is a not going to lead to better code structure.
--
Best Regards,
Artem Bityutskiy
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next prev parent reply other threads:[~2014-09-30 7:53 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-29 22:20 UBI: Fastmap fixes - round one Richard Weinberger
2014-09-29 22:20 ` [PATCH 1/4] UBI: Ensure that all fastmap work is done upon WL shutdown Richard Weinberger
2014-09-30 6:26 ` Artem Bityutskiy
2014-09-30 6:58 ` Richard Weinberger
2014-09-30 7:53 ` Bityutskiy, Artem [this message]
2014-09-30 8:07 ` Richard Weinberger
2014-10-03 12:52 ` Artem Bityutskiy
2014-10-02 13:05 ` Tanya Brokhman
2014-10-02 13:18 ` Richard Weinberger
2014-09-29 22:20 ` [PATCH 2/4] UBI: Fastmap: Calc fastmap size correctly Richard Weinberger
2014-10-02 13:14 ` Tanya Brokhman
2014-10-02 13:18 ` Richard Weinberger
2014-10-02 14:04 ` Tanya Brokhman
2014-10-03 14:38 ` Artem Bityutskiy
2014-09-29 22:20 ` [PATCH 3/4] UBI: Fastmap: Care about the protection queue Richard Weinberger
2014-10-02 13:28 ` Tanya Brokhman
2014-10-02 13:32 ` Richard Weinberger
2014-10-02 14:14 ` Tanya Brokhman
2014-10-03 14:31 ` Artem Bityutskiy
2014-10-03 19:06 ` Richard Weinberger
2014-10-13 13:17 ` Artem Bityutskiy
2014-10-13 14:30 ` Richard Weinberger
2014-10-13 15:23 ` Artem Bityutskiy
2014-10-13 15:28 ` Bityutskiy, Artem
2014-10-13 21:04 ` Richard Weinberger
2014-10-14 10:23 ` Artem Bityutskiy
2014-10-14 12:21 ` Tanya Brokhman
2014-10-14 13:02 ` Artem Bityutskiy
2014-10-14 13:35 ` Tanya Brokhman
2014-10-16 10:06 ` Richard Weinberger
2014-10-16 10:15 ` Artem Bityutskiy
2014-10-16 11:07 ` Richard Weinberger
2014-10-20 14:46 ` Artem Bityutskiy
2014-10-20 15:17 ` Richard Weinberger
2014-10-20 15:40 ` Artem Bityutskiy
2014-10-20 15:59 ` Richard Weinberger
2014-10-20 16:09 ` Artem Bityutskiy
2014-10-20 16:17 ` Richard Weinberger
2014-10-20 20:46 ` Richard Weinberger
2014-09-29 22:20 ` [PATCH 4/4] UBI: Fastmap: Ensure that only one fastmap work is scheduled Richard Weinberger
2014-09-30 6:45 ` Bityutskiy, Artem
2014-09-30 6:59 ` Richard Weinberger
2014-09-30 7:39 ` Bityutskiy, Artem
2014-09-30 7:44 ` Richard Weinberger
2014-10-02 14:22 ` Tanya Brokhman
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=1412063620.2379.12.camel@sauron.fi.intel.com \
--to=artem.bityutskiy@intel.com \
--cc=dedekind1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome