linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	adrian.hunter@intel.com, Heinz.Egger@linutronix.de,
	thomas.wucher@linutronix.de, tglx@linutronix.de,
	tim.bird@am.sony.com, Marius.Mazarel@ugal.ro,
	artem.bityutskiy@linux.intel.com, nyoushchenko@mvista.com
Subject: Re: UBI fastmap updates
Date: Sun, 08 Jul 2012 14:07:41 +0200	[thread overview]
Message-ID: <4FF9780D.4010709@nod.at> (raw)
In-Reply-To: <20120708144745.36109029@pixies.home.jungo.com>

[-- Attachment #1: Type: text/plain, Size: 3814 bytes --]

Hi Shmulik!

Am 08.07.2012 13:47, schrieb Shmulik Ladkani:
> +
> +		/* TODO: if find_fastmap==1, we do not enter this block at all.
> +		 * shouldn't we? shouldn't we care of compatability of unknown
> +		 * internal volumes OTHER than the fastmap ones, even if
> +		 * find_fastmap==1?
> +		 */
> +

If find_fastmap=1 we scan only the first 64 PEBs (now by using scan_peb()).
When using fastmap can do not care about compatibility of unknown internal volumes
at all.
Fastmap keeps only track of known (and compatible volumes).
Taking care of unknown internal volumes would imply a full scan.

		int lnum = be32_to_cpu(vidh->lnum);
>  
>  		/* Unsupported internal volume */
> @@ -1221,6 +1228,7 @@ static void destroy_ai(struct ubi_attach_info *ai)
>   * scan_all - scan entire MTD device.
>   * @ubi: UBI device description object
>   * @ai: attach info object
> + * TODO: document @start

Tomorrow I'll send another kernel-doc update.
There more tags missing.

>   * This function does full scanning of an MTD device and returns complete
>   * information about it in form of a "struct ubi_attach_info" object. In case
> @@ -1350,6 +1358,11 @@ out_vidh:
>  out_ech:
>  	kfree(ech);
>  out_ai:
> +	/* TODO: doesn't seem clean to destroy 'ai' as it was allocated by the
> +	 * caller, its his responsibility.
> +	 * also looks like it leads to double freee in case 'err' returned is
> +	 * negative
> +	 */

I have to look closer into this.
It looks like the call to destroy_ai() in scan_fast() has to go.

>  	destroy_ai(ai);
>  	return err;
>  }
> @@ -1441,6 +1454,7 @@ int ubi_attach(struct ubi_device *ubi, int force_scan)
>  
>  		err = scan_all(ubi, scan_ai, 0);
>  		if (err) {
> +			/* TODO: hmm... kfree or destroy_ai ? */

True. Must be desroy_ai().

>  			kfree(scan_ai);
>  			goto out_wl;
>  		}
> diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
> index 50b7590..f769c22 100644
> --- a/drivers/mtd/ubi/build.c
> +++ b/drivers/mtd/ubi/build.c
> @@ -1053,6 +1053,7 @@ int ubi_detach_mtd_dev(int ubi_num, int anyway)
>  	ubi_notify_all(ubi, UBI_VOLUME_REMOVED, NULL);
>  	dbg_msg("detaching mtd%d from ubi%d", ubi->mtd->index, ubi_num);
>  
> +	/* TODO: any action on failure? */

What do you expect on failure?
At this point we have either no fastmap or a valid fastmap on flash.
If ubi_update_fastmap() fails it will ensure that no invalid fastmap remains on flash.
See invalidate_fastmap().

> --- a/drivers/mtd/ubi/wl.c
> +++ b/drivers/mtd/ubi/wl.c
> @@ -272,6 +272,10 @@ static int produce_free_peb(struct ubi_device *ubi)
>  		dbg_wl("do one work synchronously");
>  		err = do_work(ubi);
>  		if (err)
> +			/* TODO: in the new locking scheme, produce_free_peb is
> +			 * called under wl_lock taken.
> +			 * so when returning, should reacquire the lock
> +			 */

Which new locking scheme?

>  			return err;
>  
>  		spin_lock(&ubi->wl_lock);
> @@ -377,6 +381,7 @@ static struct ubi_wl_entry *find_wl_entry(struct ubi_device *ubi,
>  	 * as anchor PEB, hold it back and return the second best WL entry
>  	 * such that fastmap can use the anchor PEB later. */
>  	if (!ubi->fm_disabled && !ubi->fm && e->pnum < UBI_FM_MAX_START)
> +		/* TODO: do we have a risk returning NULL here? */

How?

>  		return prev_e;
>  
>  	return e;
> @@ -405,6 +410,7 @@ static struct ubi_wl_entry *find_mean_wl_entry(struct ubi_device *ubi,
>  		/* If no fastmap has been written and this WL entry can be used
>  		 * as anchor PEB, hold it back and return the second best
>  		 * WL entry such that fastmap can use the anchor PEB later. */
> +		/* TODO: why this is specific just to < WL_FREE_MAX_DIFF case? */

Because find_wl_entry() already takes care of this.

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2012-07-08 12:07 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-29 15:14 UBI fastmap updates Richard Weinberger
2012-06-29 15:14 ` [PATCH 01/11] UBI: Fastmap: Fix mem leak in error path Richard Weinberger
2012-06-29 15:14 ` [PATCH 02/11] UBI: Fastmap: Amend self_check_eba() Richard Weinberger
2012-06-29 15:14 ` [PATCH 03/11] UBI: Fastmap: Remove forward declaration Richard Weinberger
2012-06-29 15:14 ` [PATCH 04/11] UBI: Fastmap: Move fastmap specific code into ubi_scan_fastmap() Richard Weinberger
2012-06-29 15:14 ` [PATCH 05/11] UBI: Fastmap: Kill TODO Richard Weinberger
2012-06-29 15:14 ` [PATCH 06/11] UBI: Fastmap: Remove unused variable Richard Weinberger
2012-06-29 15:14 ` [PATCH 07/11] UBI: Fastmap: Fix scan regression Richard Weinberger
2012-06-29 15:14 ` [PATCH 08/11] ubi: fastmap: Remove 'ubi' parameter of 'destroy_ai()' Richard Weinberger
2012-06-29 15:14 ` [PATCH 09/11] ubi: fastmap: Do not free 'ai' in 'scan_all()' Richard Weinberger
2012-06-29 15:14 ` [PATCH 10/11] UBI: Fastmap: Disable fastmap per default Richard Weinberger
2012-06-29 15:14 ` [PATCH 11/11] UBI: Fastmap: Add a module parameter to enable fastmap Richard Weinberger
2012-07-01  6:28   ` Rusty Russell
2012-07-01  9:41     ` Richard Weinberger
2012-06-30 10:43 ` UBI fastmap updates Artem Bityutskiy
2012-06-30 10:53   ` Richard Weinberger
2012-06-30 11:24     ` Artem Bityutskiy
2012-06-30 14:24     ` Artem Bityutskiy
2012-07-08 11:47 ` Shmulik Ladkani
2012-07-08 12:07   ` Richard Weinberger [this message]
2012-07-08 15:11     ` Richard Weinberger
2012-07-09  7:37     ` Shmulik Ladkani
2012-07-09  8:19       ` Richard Weinberger
  -- strict thread matches above, loose matches on Subject: below --
2013-09-28 13:55 Richard Weinberger
2013-10-03 16:44 ` Artem Bityutskiy
2012-07-09 12:18 Richard Weinberger
2012-08-02 14:12 ` Artem Bityutskiy
2012-08-02 14:15   ` Richard Weinberger
2012-08-02 14:29     ` Artem Bityutskiy
2012-08-02 14:51       ` Richard Weinberger
2012-08-02 16:17         ` Artem Bityutskiy
2012-08-02 16:32           ` Richard Weinberger
2012-08-02 16:45             ` Artem Bityutskiy
2012-08-02 16:54               ` Richard Weinberger
2012-08-02 17:03               ` Tim Bird
2012-08-02 17:06                 ` Richard Weinberger
2012-08-02 17:40                 ` Artem Bityutskiy
2012-08-02 17:45                   ` Richard Weinberger
2012-08-02 17:59                     ` Artem Bityutskiy
2012-08-02 18:03                       ` Richard Weinberger
2012-08-02 18:15                         ` Artem Bityutskiy
2012-08-05  8:23                     ` Shmulik Ladkani
2012-08-05 14:25                       ` Richard Weinberger
2012-08-02 17:50                 ` Artem Bityutskiy
2012-08-02 14:58 ` Artem Bityutskiy
2012-08-02 14:59   ` Richard Weinberger
2012-08-02 15:18     ` Artem Bityutskiy
2012-08-02 15:19       ` Richard Weinberger
2012-08-06 17:36   ` Richard Weinberger
2012-08-07  4:21     ` Artem Bityutskiy
2012-08-07  7:29       ` Richard Weinberger
2012-08-07 18:53         ` Artem Bityutskiy
2012-08-02 18:50 ` Artem Bityutskiy
2012-08-02 18:56   ` Artem Bityutskiy
2012-08-03  8:47 ` Artem Bityutskiy
2012-08-03  8:56   ` Richard Weinberger
2012-08-17 13:11 ` Artem Bityutskiy
2012-08-17 13:33   ` Richard Weinberger
2012-08-17 13:41     ` Artem Bityutskiy
2012-08-17 13:43       ` Richard Weinberger
2012-08-17 14:06         ` Artem Bityutskiy
2012-07-02 16:23 Richard Weinberger
2012-06-27 15:57 Richard Weinberger
2012-06-23 13:03 Richard Weinberger
2012-06-27  4:20 ` Namjae Jeon
2012-06-27  6:48   ` Nikita V. Youshchenko
2012-06-27  7:17     ` Richard Weinberger
2012-06-18 16:18 UBI Fastmap updates Richard Weinberger

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=4FF9780D.4010709@nod.at \
    --to=richard@nod.at \
    --cc=Heinz.Egger@linutronix.de \
    --cc=Marius.Mazarel@ugal.ro \
    --cc=adrian.hunter@intel.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nyoushchenko@mvista.com \
    --cc=shmulik.ladkani@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.wucher@linutronix.de \
    --cc=tim.bird@am.sony.com \
    /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;
as well as URLs for NNTP newsgroup(s).