All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@nokia.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Matthieu CASTET <matthieu.castet@parrot.com>
Subject: Re: [PATCHv2 7/9] UBIFS: do not write rubbish into truncation scanning node
Date: Sun, 08 Aug 2010 14:03:49 +0300	[thread overview]
Message-ID: <4C5E8F15.9080505@nokia.com> (raw)
In-Reply-To: <1281261452-9868-8-git-send-email-dedekind1@gmail.com>

Artem Bityutskiy wrote:
> From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
> 
> In the scanning code, in 'ubifs_add_snod()', we write rubbish into
> 'snod->key', because we assume that on-flash truncation nodes have a key, but
> they do not. If the other parts of UBIFS then mistakenly try to look-up
> the truncation node key (they should not do this, but may do because of a bug),
> we can succeed and corrupt TNC. It looks like we did have such a situation in
> 'sort_nodes()' in gc.c.
> 
> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
> ---
>  fs/ubifs/scan.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/ubifs/scan.c b/fs/ubifs/scan.c
> index 96c5253..a0a305c 100644
> --- a/fs/ubifs/scan.c
> +++ b/fs/ubifs/scan.c
> @@ -212,7 +212,6 @@ int ubifs_add_snod(const struct ubifs_info *c, struct ubifs_scan_leb *sleb,
>  	case UBIFS_DENT_NODE:
>  	case UBIFS_XENT_NODE:
>  	case UBIFS_DATA_NODE:
> -	case UBIFS_TRUN_NODE:

There is another bug in ubifs_recover_size_accum() that expects a truncate node
to have a key.  That would be fixed by using trun_key_init() here.

>  		/*
>  		 * The key is in the same place in all keyed
>  		 * nodes.

  reply	other threads:[~2010-08-08 11:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-08  9:57 [PATCHv2 0/9] UBIFS: recent patches Artem Bityutskiy
2010-08-08  9:57 ` [PATCHv2 1/9] UBIFS: switch to RO mode after synchronizing Artem Bityutskiy
2010-08-08  9:57 ` [PATCHv2 2/9] UBIFS: do not treat ENOSPC specially Artem Bityutskiy
2010-08-08  9:57 ` [PATCHv2 3/9] UBIFS: fix assertion warning Artem Bityutskiy
2010-08-08  9:57 ` [PATCHv2 4/9] UBIFS: do not look up truncation nodes Artem Bityutskiy
2010-08-08  9:57 ` [PATCHv2 5/9] UBIFS: do not use key type in list_sort Artem Bityutskiy
2010-08-08  9:57 ` [PATCHv2 6/9] UBIFS: improve assertion in node comparison functions Artem Bityutskiy
2010-08-08  9:57 ` [PATCHv2 7/9] UBIFS: do not write rubbish into truncation scanning node Artem Bityutskiy
2010-08-08 11:03   ` Adrian Hunter [this message]
2010-08-08 11:08     ` Adrian Hunter
2010-08-08 13:59       ` Artem Bityutskiy
2010-08-22  4:25       ` Artem Bityutskiy
2010-08-08  9:57 ` [PATCHv2 8/9] UBIFS: fix assertion warnings in comparison function Artem Bityutskiy
2010-08-08  9:57 ` [PATCHv2 9/9] UBIFS: introduce list sorting debugging checks 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=4C5E8F15.9080505@nokia.com \
    --to=adrian.hunter@nokia.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthieu.castet@parrot.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 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.