------- Comment From [email protected] 2016-03-01 14:03 EDT-------
So as some folks have previously pointed out we end up with issues with the
struct hd_struct *part in blk_account_io_start()
2342 part = disk_map_sector_rcu(rq->rq_disk, blk_rq_pos(rq));
2343 if (!hd_struct_try_get(part)) {
r28 has the address of the struct request *rq from which we get
rq->rq_disk located at offset 0xc0 from the what r28 points to. Offset
0x60 of the request has the sector on the disk we care to find out which
partition it is in.
d:mon> d c0000007490f0450
c0000007490f0450 d0ba6cda060000c0 d0ba6cda060000c0 |..l.......l.....|
c0000007490f0460 0000000000000000 0000000000000000 |................|
c0000007490f0470 0000000000000000 0000000000000000 |................|
c0000007490f0480 e0083a4d070000c0 0000000000000000 |..:M............|
c0000007490f0490 0000402400000000 0100000000000000 |..@$............|
c0000007490f04a0 0000000000000000 0d00000000000100 |................|
c0000007490f04b0 8008000000000000 00860749070000c0 |...........I....|
c0000007490f04c0 00860749070000c0 0000000000000000 |...I............|
c0000007490f04d0 0000000000000000 d8040f49070000c0 |...........I....|
c0000007490f04e0 0000000000000000 0000000000000000 |................|
c0000007490f04f0 0000000000000000 0000000000000000 |................|
c0000007490f0500 0000000000000000 0000000000000000 |................|
c0000007490f0510 00d86668070000c0 0000000000000000 |..fh............|
c0000007490f0520 3781ffff00000000 4098b162070000c0 |[email protected]....|
c0000007490f0530 84b745a127000000 0000000000000000 |..E.'...........|
c0000007490f0540 0100000000000000 0000000000000000 |................|
This should be the struct gendisk *rq_disk that is passed to
disk_map_sector_rcu() and at offset 0x40 we have the struct
disk_part_tbl __rcu *part_tbl and after that at offset 0x48 is the
struct hd_struct part0
d:mon> d c00000076866d800
c00000076866d800 0800000020000000 1000000073646300 |.... .......sdc.|
c00000076866d810 0000000000000000 0000000000000000 |................|
c00000076866d820 0000000000000000 0000630000000000 |..........c.....|
c00000076866d830 0000000000000000 0000000000000000 |................|
c00000076866d840 4038257e070000c0 0000000000000000 |@8%~............|
c00000076866d850 00c0092100000000 0000000000000000 |...!............|
c00000076866d860 0000000000000000 0000000000000000 |................|
c00000076866d870 6881067e070000c0 c000a54e070000c0 |h..~.......N....|
c00000076866d880 2800d44e070000c0 409c2068070000c0 |(..N....@. h....|
c00000076866d890 18fccc50070000c0 6000f448070000c0 |...P....`..H....|
c00000076866d8a0 00004a68070000c0 602f4e01000000c0 |..Jh....`/N.....|
c00000076866d8b0 500af148070000c0 0e00000007000000 |P..H............|
c00000076866d8c0 0000000000000000 08274d01000000c0 |.........'M.....|
c00000076866d8d0 0100000000000000 d8d86668070000c0 |..........fh....|
c00000076866d8e0 d8d86668070000c0 0000000000000000 |..fh............|
c00000076866d8f0 0000000000000000 0000000000000000 |................|
struct disk_part_tbl __rcu *part_tbl. Offset 0x18 is
part_tbl->last_lookup
d:mon> d 0xC00000077E253840
c00000077e253840 0000000000000000 0000000000000000 |................|
c00000077e253850 0600000000000000 0024934f070000c0 |.........$.O....|
c00000077e253860 48d86668070000c0 0024934f070000c0 |H.fh.....$.O....|
c00000077e253870 0000000000000000 0000000000000000 |................|
c00000077e253880 0000000000000000 0000000000000000 |................|
c00000077e253890 0000000000000000 0000000000000000 |................|
c00000077e2538a0 e037257e070000c0 0000000000000000 |.7%~............|
c00000077e2538b0 0000000000000000 0000000000000000 |................|
What I find odd here is that len = 6 yet it only looks like we have two
entries and think the first is the address for part0. I can see that the
script tries to create 8 partitions. I see from the script output it
created three primary partitions, one extended and one logical partition
when it dropped to xmon.
disk_map_sector_rcu() should never return NULL.
Address of part_tbl->last_lookup
d:mon> d 0xC00000074F932400
c00000074f932400 0008000000000000 00e8f60300000000 |................|
c00000074f932410 0000000000000000 0000000000000000 |................|
c00000074f932420 0000000000000000 70d86668070000c0 |........p.fh....|
c00000074f932430 4083974f070000c0 8008e11a070000c0 |@..O............|
and I think this is &part->ref if that means anything to anyone
d:mon> d 0xC00000074F932758
c00000074f932758 b89ef800000000c0 60655400000000c0 |........`eT.....|
c00000074f932768 0000000000000000 0000000000000000 |................|
c00000074f932778 0000000000000000 0000000000000000 |................|
c00000074f932788 0000000000000000 0000000000000000 |................|
I unfortunately have to leave for the day. If possible someone else will
need to finish the debug as I am out tomorrow.
The nice thing here is that this is very easily recreatable.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1546439
Title:
ISST:LTE: Regression: roselp2 Oops in kernel during setup io
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1546439/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
