From: Artem Bityutskiy <dedekind1@gmail.com>
To: akpm@linux-foundation.org
Cc: neilb@suse.de, linux-mtd@lists.infradead.org,
avorontsov@ru.mvista.com, dwmw2@infradead.org
Subject: Re: [patch 1/5] jffs2: fix memory corruption in jffs2_read_inode_range()
Date: Tue, 09 Feb 2010 15:26:32 +0200 [thread overview]
Message-ID: <1265721992.2006.153.camel@localhost> (raw)
In-Reply-To: <201002022243.o12Mh9er019176@imap1.linux-foundation.org>
On Tue, 2010-02-02 at 14:43 -0800, akpm@linux-foundation.org wrote:
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> In 2.6.23 kernel, commit a32ea1e1f925399e0d81ca3f7394a44a6dafa12c ("Fix
> read/truncate race") fixed a race in the generic code, and as a side
> effect, now do_generic_file_read() can ask us to readpage() past the
> i_size, which seems to be correctly handled by the block routines (e.g.
> block_read_full_page() fills the page with zeroes in case if somebody is
> trying to read past the last inode's block).
>
> JFFS2 doesn't handle this, instead jffs2_read_inode_range() is trying to
> lookup the fragments which do not belong to anything, and
> jffs2_lookup_node_frag() happily returns "the closest smaller match" which
> is OK for most cases (I guess), but in our case there wasn't anything
> meaningful to lookup in the first place.
>
> After we found the bogus fragment, the code can branch to 'Filling frag
> hole' case that does
>
> memset(buf, 0, min(end, frag->ofs + frag->size) - offset);
>
> and since 'frag' is bogus, its ofs + size can be smaller than the real
> 'offset' (i.e. index << PAGE_CACHE_SHIFT), and so the code turns into
>
> memset(buf, 0, <huge unsigned negative>);
>
> Hopefully, in most cases the corruption is fatal, and quickly causing
> random oopses, like this:
>
> root@10.0.0.4:~/ltp-fs-20090531# ./testcases/kernel/fs/ftest/ftest01
> Unable to handle kernel paging request for data at address 0x00000008
> Faulting instruction address: 0xc01cd980
> Oops: Kernel access of bad area, sig: 11 [#1]
> [...]
> NIP [c01cd980] rb_insert_color+0x38/0x184
> LR [c0043978] enqueue_hrtimer+0x88/0xc4
> Call Trace:
> [c6c63b60] [c004f9a8] tick_sched_timer+0xa0/0xe4 (unreliable)
> [c6c63b80] [c0043978] enqueue_hrtimer+0x88/0xc4
> [c6c63b90] [c0043a48] __run_hrtimer+0x94/0xbc
> [c6c63bb0] [c0044628] hrtimer_interrupt+0x140/0x2b8
> [c6c63c10] [c000f8e8] timer_interrupt+0x13c/0x254
> [c6c63c30] [c001352c] ret_from_except+0x0/0x14
> --- Exception: 901 at memset+0x38/0x5c
> LR = jffs2_read_inode_range+0x144/0x17c
> [c6c63cf0] [00000000] (null) (unreliable)
>
> This patch fixes the issue, plus fixes all LTP tests on NAND/UBI with
> JFFS2 filesystem that were failing since 2.6.23 (seems like the bug above
> also broke the truncation).
>
> Note that the bug is only reproducible with write-buffered MTD devices
> (e.g. NAND, UBI), which is a mystery to me (though I didn't look close
> enough, possibly there is a race between gc and wbuf code, but I don't see
> it and obviously it isn't that fatal).
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Neil Brown <neilb@suse.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
All 5 patches you sent in this series are also sitting in my l2-mtd-2.6
tree.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-02-09 13:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-02 22:43 [patch 1/5] jffs2: fix memory corruption in jffs2_read_inode_range() akpm
2010-02-02 22:50 ` Anton Vorontsov
2010-02-09 13:26 ` Artem Bityutskiy [this message]
2010-02-09 13:30 ` Anton Vorontsov
2010-02-09 13:33 ` 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=1265721992.2006.153.camel@localhost \
--to=dedekind1@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=avorontsov@ru.mvista.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=neilb@suse.de \
/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