Re: [BUG REPORT] Kernel panic on 3.9.0-rc7-4-gbb33db7

From: Tejun Heo
Date: Fri Apr 19 2013 - 01:58:05 EST


(cc'ing btrfs people)

On Fri, Apr 19, 2013 at 11:33:20AM +0800, Wanlong Gao wrote:
> RIP: 0010:[<ffffffff812484d3>] [<ffffffff812484d3>] ftrace_raw_event_block_bio_complete+0x73/0xf0
...
> [<ffffffff811b6c10>] bio_endio+0x80/0x90
> [<ffffffffa0790d26>] btrfs_end_bio+0xf6/0x190 [btrfs]
> [<ffffffff811b6bcd>] bio_endio+0x3d/0x90
> [<ffffffff81249873>] req_bio_endio+0xa3/0xe0

Ugh....

In fs/btrfs/volumes.c

static void bbio_error(struct btrfs_bio *bbio, struct bio *bio, u64 logical)
{
...
bio->bi_bdev = (struct block_device *)
(unsigned long)bbio->mirror_num;
...
}

static void btrfs_end_bio(struct bio *bio, int err)
{
...
bio->bi_bdev = (struct block_device *)
(unsigned long)bbio->mirror_num;

...
}

In fs/btrfs/extent_io.c

static void end_bio_extent_readpage(struct bio *bio, int err)
{
int mirror;
...
mirror = (int)(unsigned long)bio->bi_bdev;
...
}

Ewweeeeeeeeeeeeeeeeeehh........

No wonder this thing crashes. Chris, can't the original bio carry
bbio in bi_private and let end_bio_extent_readpage() free the bbio
instead of abusing bi_bdev like this?

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/