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 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.