From: Artem Bityutskiy <dedekind1@gmail.com>
To: Joel Reardon <joel@clambassador.com>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] UBI: add ubi_lnum_purge function to clear work queue for a lnum
Date: Tue, 15 May 2012 14:40:12 +0300 [thread overview]
Message-ID: <1337082012.2528.181.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205150943470.17750@eristoteles.iwoars.net>
[-- Attachment #1: Type: text/plain, Size: 3501 bytes --]
On Tue, 2012-05-15 at 09:44 +0200, Joel Reardon wrote:
> This is the second part of a patch to allow UBI to force the erasure of
> particular logical eraseblock numbers. In this patch, a new function,
> ubi_lnum_purge, is added that allows the caller to synchronously erase all
> unmapped erase blocks whose LEB number corresponds to the parameter. This
> requires a previous patch that stores the LEB number in struct ubi_work.
>
> This was tested by disabling the call to do_work in ubi thread, which results
> in the work queue remaining unless explicitly called to remove. UBIFS was
> changed to call ubifs_leb_change 50 times for three different LEBs. Then the
> new function was called to clear the queue for the three differnt LEB numbers
> one at a time. The work queue was dumped each time and the selective removal
> of the particular LEB numbers was observed.
>
> Signed-off-by: Joel Reardon <reardonj@inf.ethz.ch>
No objections in general, and I can merge this as soon as you send the
final version. However, for this version I have several notes.
> +/**
> + * ubi_lnum_purge - synchronously erase unmapped PEBs by LEB number.
> + * @ubi_num: UBI device to erase PEBs
> + * @lnum: the LEB number to erase old unmapped PEBs.
> + *
> + * This function is designed to offer a means to ensure that the contents of
> + * old, unmapped LEBs are securely erased without having to flush the entire
> + * work queue of all erase blocks that need erasure. Simply erasing the block
> + * at the time of unmapped is insufficient, as the wear-levelling subsystem
> + * may have already moved the contents. This function navigates the list of
> + * erase blocks that need erasures, and performs an immediate and synchronous
> + * erasure of any erase block that has held data for this particular @lnum.
> + * This may include eraseblocks that held older versions of the same @lnum.
> + * Returns zero in case of success and a negative error code in case of
> + * failure.
> + */
> +int ubi_lnum_purge(int ubi_num, int lnum)
> +{
> + int err;
> + struct ubi_device *ubi;
> +
> + ubi = ubi_get_device(ubi_num);
> + if (!ubi)
> + return -ENODEV;
> +
> + err = ubi_wl_flush_lnum(ubi, lnum);
> + ubi_put_device(ubi);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(ubi_lnum_purge);
Please, do not introduce a separate exported function for this. Instead,
add "lnum" argument to "ubi_wl_flush". Preserve the old behavior if lnum
is -1. Document this at the header comment. In your case you also need
to call mtd->sync() I think.
> + dbg_wl("flush lnum %d", lnum);
> + list_for_each_entry_safe(wrk, tmp, &ubi->works, list) {
> + if (wrk->lnum == lnum) {
> + down_read(&ubi->work_sem);
> + spin_lock(&ubi->wl_lock);
But you cannot walk the ubi->works list without holding the spinlock.
Any one may add/remove elements to/from this list concurrently.
Take the work_sem at the beginning. Release at the very end.
Then you can do something like this:
int found = 1;
while (found) {
found = 0;
spin_lock(&ubi->wl_lock);
list_for_each_entry(wrk, tmp, &ubi->works, list) {
if (wrk->lnum == lnum) {
list_del(&wrk->list);
ubi->works_count -= 1;
ubi_assert(ubi->works_count >= 0);
spin_unlock(&ubi->wl_lock);
err = wrk->func(ubi, wrk, 0);
if (err)
return err;
spin_lock(&ubi->wl_lock);
found = 1;
break;
}
spin_unlock(&ubi->wl_lock);
}
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-05-15 11:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 7:44 [PATCH V2] UBI: add ubi_lnum_purge function to clear work queue for a lnum Joel Reardon
2012-05-15 11:40 ` Artem Bityutskiy [this message]
2012-05-19 9:46 ` Joel Reardon
2012-05-19 10:47 ` Artem Bityutskiy
2012-05-19 10:52 ` Artem Bityutskiy
2012-05-20 11:10 ` [PATCH V3] UBI: modify ubi_wl_flush " Joel Reardon
2012-05-20 19:27 ` [PATCH V4] " Joel Reardon
2012-05-21 11:41 ` Artem Bityutskiy
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=1337082012.2528.181.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=joel@clambassador.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
/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