From: Artem Bityutskiy <dedekind1@gmail.com>
To: Adrian Hunter <adrian.hunter@nokia.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Matthieu CASTET <matthieu.castet@parrot.com>
Subject: Re: [PATCH 5/7] UBIFS: do not look up junk nodes
Date: Sat, 07 Aug 2010 15:45:01 +0300 [thread overview]
Message-ID: <1281185101.1175.78.camel@localhost.localdomain> (raw)
In-Reply-To: <4C5D4C5D.3090204@nokia.com>
Adrian, thanks for review!
On Sat, 2010-08-07 at 15:06 +0300, Adrian Hunter wrote:
> Artem Bityutskiy wrote:
> > From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
> >
> > When moving nodes, do not try to look up truncation and padding nodes in TNC,
> > because they do not exist there. This bug was most probably harmless, because
> > the TNC look-up probably failed for all padding and truncation nodes, but it
>
> The scan does not return padding nodes.
Oh yes.
> > could also succeed and lead to various "interesting" errors.
>
> Why would it succeed?
In 'ubifs_add_snod()' we call call 'key_read(c, &ino->key, &snod->key)'
for truncation nodes. However, 'struct ubifs_trun_node' does not have
key, so we read something else, and may happen to succeed in TNC lookup
then.
I guess the 'ubifs_add_snod()' should be fixed. Then key for truncation
nodes will be zero, and TNC lookup wont's succeed for sure, but it is
safer still to avoid look up for anything but data/ino/dent/xent nodes,
I think, no?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-08-07 12:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-07 8:26 [PATCH 0/7] UBIFS: recent patches Artem Bityutskiy
2010-08-07 8:26 ` [PATCH 1/7] UBIFS: switch to RO mode after synchronizing Artem Bityutskiy
2010-08-07 8:26 ` [PATCH 2/7] UBIFS: do not treat ENOSPC specially Artem Bityutskiy
2010-08-08 17:51 ` Vitaly Wool
2010-08-09 5:56 ` Artem Bityutskiy
2010-08-07 8:26 ` [PATCH 3/7] UBIFS: fix assertion warning Artem Bityutskiy
2010-08-07 8:26 ` [PATCH 4/7] UBIFS: fix GC sroting Artem Bityutskiy
2010-08-07 12:11 ` Adrian Hunter
2010-08-07 12:51 ` Artem Bityutskiy
2010-08-07 8:26 ` [PATCH 5/7] UBIFS: do not look up junk nodes Artem Bityutskiy
2010-08-07 12:06 ` Adrian Hunter
2010-08-07 12:45 ` Artem Bityutskiy [this message]
2010-08-07 8:26 ` [PATCH 6/7] UBIFS: do not use key type in list_sort compariosn fuction Artem Bityutskiy
2010-08-07 8:26 ` [PATCH 7/7] UBIFS: introduce list sorting debugging checks Artem Bityutskiy
2010-08-09 13:18 ` [PATCH 0/7] UBIFS: recent patches Matthieu CASTET
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=1281185101.1175.78.camel@localhost.localdomain \
--to=dedekind1@gmail.com \
--cc=adrian.hunter@nokia.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 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).