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
---------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
