From: "Sachin P. Sant" <sachinp@in.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: Paul Mackerras <paulus@samba.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@csn.ul.ie>,
linuxppc-dev@ozlabs.org, linux-ext4@vger.kernel.org,
Jan Kara <jack@ucw.cz>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Crash (ext3 ) during 2.6.29-rc6 boot
Date: Tue, 24 Feb 2009 12:08:37 +0530 [thread overview]
Message-ID: <49A395ED.5030607@in.ibm.com> (raw)
In-Reply-To: <20090223155116.GB5764@atrey.karlin.mff.cuni.cz>
Jan Kara wrote:
> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> somehow got beyond end of the page referenced by bh->b_data. So it means
> that le16_to_cpu(entry->e_value_offs) + size > page_size. But
> ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in
> particular checks whether e_value_offs + e_value_size isn't greater than
> bh->b_size. So I see no way how memcpy can get beyond end of the page.
> Sachin, is the problem reproducible? If yes, can you send us contents
>
Yes, i am able to recreate this problem easily. As i had mentioned if the
earlier kernel is booted with selinux enabled and then 2.6.29-rc6 is booted
i get this crash. But if i specify selinux=0 at command line, 2.6.29-rc6 boots
without any problem.
> of the page just before the faulting address (i.e., for current fault it
> would be 0xc00000003f370000-0xc00000003f37ffff). As far as I can
> remember powerpc monitor could dump it.
>
Here is the page dump. This time it crashed while accessing address
0xc00000002d670000.
Unable to handle kernel paging request for data at address 0xc0000
0002d670000
Faulting instruction address: 0xc000000000039574
cpu 0x1: Vector: 300 (Data Access) at [c00000004288b0b0]
pc: c000000000039574: .memcpy+0x74/0x244
lr: c0000000001b497c: .ext3_xattr_get+0x288/0x2f4
sp: c00000004288b330
msr: 8000000000009032
1:mon> d 0xc00000002d660000
............................... <SNIP> ...............................
c00000002d66efd0 0000000000000000 0000000000000000 |................|
c00000002d66efe0 0000000000000000 0000000000000000 |................|
c00000002d66eff0 0000000000000000 0000000000000000 |................|
c00000002d66f000 000002ea00040000 01000000e200d20a |................|
c00000002d66f010 0000000000000000 0000000000000000 |................|
c00000002d66f020 0706e40f00000000 1b000000e200d20a |................|
c00000002d66f030 73656c696e757800 0000000000000000 |selinux.........|
c00000002d66f040 0000000000000000 0000000000000000 |................|
c00000002d66f050 0000000000000000 0000000000000000 |................|
c00000002d66f060 0000000000000000 0000000000000000 |................|
............................... <SNIP> ...............................
c00000002d66ff60 0000000000000000 0000000000000000 |................|
c00000002d66ff70 0000000000000000 0000000000000000 |................|
c00000002d66ff80 0000000000000000 0000000000000000 |................|
c00000002d66ff90 0000000000000000 0000000000000000 |................|
c00000002d66ffa0 0000000000000000 0000000000000000 |................|
c00000002d66ffb0 0000000000000000 0000000000000000 |................|
c00000002d66ffc0 0000000000000000 0000000000000000 |................|
c00000002d66ffd0 0000000000000000 0000000000000000 |................|
c00000002d66ffe0 0000000073797374 656d5f753a6f626a |....system_u:obj|
c00000002d66fff0 6563745f723a7573 725f743a73300000 |ect_r:usr_t:s0..|
c00000002d670000 **************** **************** | |
1:mon> r
R00 = 000000000000e40f R16 = 000000000000005d
R01 = c00000004288b330 R17 = 0000000000000000
R02 = c0000000009f59b8 R18 = 00000000fffbfe9e
R03 = c000000044aa34a0 R19 = 0000000010042638
R04 = c00000002d66fff4 R20 = 0000000010041610
R05 = 0000000000000003 R21 = 00000000000000ff
R06 = 0000000000000000 R22 = 0000000000000006
R07 = 0000000000000001 R23 = c0000000007d27c1
R08 = 723a7573725f743a R24 = c00000002c0cd758
R09 = 3a6f626a6563745f R25 = c000000044aa3488
R10 = c00000000017b43c R26 = c00000002c0cd6f0
R11 = c00000002d66f020 R27 = c00000002c0cd860
R12 = d0000000023c14b0 R28 = c00000002c0b0840
R13 = c000000000a93680 R29 = 000000000000001b
R14 = 00000000000041ed R30 = c0000000009880b0
R15 = 0000000010040000 R31 = ffffffffffffffde
pc = c000000000039574 .memcpy+0x74/0x244
lr = c0000000001b497c .ext3_xattr_get+0x288/0x2f4
msr = 8000000000009032 cr = 4400044b
ctr = 0000000000000000 xer = 0000000020000001 trap = 300
dar = c00000002d670000 dsisr = 40000000
1:mon> zr
> BTW, I suppose you use 4KB blocksize on the filesystem, right?
>
Yes.
dumpe2fs /dev/sda3 | grep -i "block size"
dumpe2fs 1.39 (29-May-2006)
Block size: 4096
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
WARNING: multiple messages have this Message-ID (diff)
From: "Sachin P. Sant" <sachinp@in.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: Jan Kara <jack@ucw.cz>, Mel Gorman <mel@csn.ul.ie>,
linux-kernel <linux-kernel@vger.kernel.org>,
linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-ext4@vger.kernel.org
Subject: Re: Crash (ext3 ) during 2.6.29-rc6 boot
Date: Tue, 24 Feb 2009 12:08:37 +0530 [thread overview]
Message-ID: <49A395ED.5030607@in.ibm.com> (raw)
In-Reply-To: <20090223155116.GB5764@atrey.karlin.mff.cuni.cz>
Jan Kara wrote:
> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> somehow got beyond end of the page referenced by bh->b_data. So it means
> that le16_to_cpu(entry->e_value_offs) + size > page_size. But
> ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in
> particular checks whether e_value_offs + e_value_size isn't greater than
> bh->b_size. So I see no way how memcpy can get beyond end of the page.
> Sachin, is the problem reproducible? If yes, can you send us contents
>
Yes, i am able to recreate this problem easily. As i had mentioned if the
earlier kernel is booted with selinux enabled and then 2.6.29-rc6 is booted
i get this crash. But if i specify selinux=0 at command line, 2.6.29-rc6 boots
without any problem.
> of the page just before the faulting address (i.e., for current fault it
> would be 0xc00000003f370000-0xc00000003f37ffff). As far as I can
> remember powerpc monitor could dump it.
>
Here is the page dump. This time it crashed while accessing address
0xc00000002d670000.
Unable to handle kernel paging request for data at address 0xc0000
0002d670000
Faulting instruction address: 0xc000000000039574
cpu 0x1: Vector: 300 (Data Access) at [c00000004288b0b0]
pc: c000000000039574: .memcpy+0x74/0x244
lr: c0000000001b497c: .ext3_xattr_get+0x288/0x2f4
sp: c00000004288b330
msr: 8000000000009032
1:mon> d 0xc00000002d660000
............................... <SNIP> ...............................
c00000002d66efd0 0000000000000000 0000000000000000 |................|
c00000002d66efe0 0000000000000000 0000000000000000 |................|
c00000002d66eff0 0000000000000000 0000000000000000 |................|
c00000002d66f000 000002ea00040000 01000000e200d20a |................|
c00000002d66f010 0000000000000000 0000000000000000 |................|
c00000002d66f020 0706e40f00000000 1b000000e200d20a |................|
c00000002d66f030 73656c696e757800 0000000000000000 |selinux.........|
c00000002d66f040 0000000000000000 0000000000000000 |................|
c00000002d66f050 0000000000000000 0000000000000000 |................|
c00000002d66f060 0000000000000000 0000000000000000 |................|
............................... <SNIP> ...............................
c00000002d66ff60 0000000000000000 0000000000000000 |................|
c00000002d66ff70 0000000000000000 0000000000000000 |................|
c00000002d66ff80 0000000000000000 0000000000000000 |................|
c00000002d66ff90 0000000000000000 0000000000000000 |................|
c00000002d66ffa0 0000000000000000 0000000000000000 |................|
c00000002d66ffb0 0000000000000000 0000000000000000 |................|
c00000002d66ffc0 0000000000000000 0000000000000000 |................|
c00000002d66ffd0 0000000000000000 0000000000000000 |................|
c00000002d66ffe0 0000000073797374 656d5f753a6f626a |....system_u:obj|
c00000002d66fff0 6563745f723a7573 725f743a73300000 |ect_r:usr_t:s0..|
c00000002d670000 **************** **************** | |
1:mon> r
R00 = 000000000000e40f R16 = 000000000000005d
R01 = c00000004288b330 R17 = 0000000000000000
R02 = c0000000009f59b8 R18 = 00000000fffbfe9e
R03 = c000000044aa34a0 R19 = 0000000010042638
R04 = c00000002d66fff4 R20 = 0000000010041610
R05 = 0000000000000003 R21 = 00000000000000ff
R06 = 0000000000000000 R22 = 0000000000000006
R07 = 0000000000000001 R23 = c0000000007d27c1
R08 = 723a7573725f743a R24 = c00000002c0cd758
R09 = 3a6f626a6563745f R25 = c000000044aa3488
R10 = c00000000017b43c R26 = c00000002c0cd6f0
R11 = c00000002d66f020 R27 = c00000002c0cd860
R12 = d0000000023c14b0 R28 = c00000002c0b0840
R13 = c000000000a93680 R29 = 000000000000001b
R14 = 00000000000041ed R30 = c0000000009880b0
R15 = 0000000010040000 R31 = ffffffffffffffde
pc = c000000000039574 .memcpy+0x74/0x244
lr = c0000000001b497c .ext3_xattr_get+0x288/0x2f4
msr = 8000000000009032 cr = 4400044b
ctr = 0000000000000000 xer = 0000000020000001 trap = 300
dar = c00000002d670000 dsisr = 40000000
1:mon> zr
> BTW, I suppose you use 4KB blocksize on the filesystem, right?
>
Yes.
dumpe2fs /dev/sda3 | grep -i "block size"
dumpe2fs 1.39 (29-May-2006)
Block size: 4096
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
next prev parent reply other threads:[~2009-02-24 6:38 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-23 9:46 Crash (ext3 ) during 2.6.29-rc6 boot Sachin P. Sant
2009-02-23 10:13 ` Andrew Morton
2009-02-23 10:13 ` Andrew Morton
2009-02-23 10:32 ` Paul Mackerras
2009-02-23 10:32 ` Paul Mackerras
2009-02-23 10:57 ` Sachin P. Sant
2009-02-23 10:57 ` Sachin P. Sant
2009-02-23 15:51 ` Jan Kara
2009-02-23 15:51 ` Jan Kara
2009-02-24 6:38 ` Sachin P. Sant [this message]
2009-02-24 6:38 ` Sachin P. Sant
2009-02-24 15:51 ` Jan Kara
2009-02-24 15:51 ` Jan Kara
2009-02-25 1:20 ` Mark Nelson
2009-02-25 1:20 ` Mark Nelson
2009-02-25 6:52 ` Mark Nelson
2009-02-25 6:52 ` Mark Nelson
2009-02-25 9:50 ` Geert Uytterhoeven
2009-02-25 9:50 ` Geert Uytterhoeven
2009-02-25 9:50 ` Geert Uytterhoeven
2009-02-25 12:10 ` Mark Nelson
2009-02-25 12:10 ` Mark Nelson
2009-02-25 13:31 ` Geert Uytterhoeven
2009-02-25 13:31 ` Geert Uytterhoeven
2009-02-25 13:31 ` Geert Uytterhoeven
2009-02-25 22:45 ` Mark Nelson
2009-02-25 22:45 ` Mark Nelson
2009-02-25 23:20 ` Mark Nelson
2009-02-25 23:20 ` Mark Nelson
2009-02-26 17:40 ` Geert Uytterhoeven
2009-02-26 17:40 ` Geert Uytterhoeven
2009-02-26 17:40 ` Geert Uytterhoeven
2009-02-25 11:08 ` Sachin P. Sant
2009-02-25 11:08 ` Sachin P. Sant
2009-02-25 12:13 ` Mark Nelson
2009-02-25 12:13 ` Mark Nelson
2009-02-25 23:26 ` [PATCH] powerpc: Fix 64bit memcpy() regression Mark Nelson
2009-02-25 23:26 ` Mark Nelson
2009-02-25 23:46 ` [PATCH] powerpc: Fix 64bit __copy_tofrom_user() regression Mark Nelson
2009-02-25 23:46 ` Mark Nelson
2009-02-24 18:01 ` Crash (ext3 ) during 2.6.29-rc6 boot Geert Uytterhoeven
2009-02-24 18:01 ` Geert Uytterhoeven
2009-02-24 18:01 ` Geert Uytterhoeven
2009-02-25 1:27 ` Mark Nelson
2009-02-25 1:27 ` Mark Nelson
2009-02-25 10:50 ` Geert Uytterhoeven
2009-02-25 10:50 ` Geert Uytterhoeven
2009-02-25 10:50 ` Geert Uytterhoeven
2009-02-23 10:48 ` Sachin P. Sant
2009-02-23 10:48 ` Sachin P. Sant
2009-02-24 16:14 ` Jan Kara
2009-02-24 16:14 ` Jan Kara
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=49A395ED.5030607@in.ibm.com \
--to=sachinp@in.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=jack@ucw.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mel@csn.ul.ie \
--cc=paulus@samba.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.