On Tue, Jun 23, 2015 at 11:10:37AM +0800, Liu Bo wrote:
> On Sat, Jun 20, 2015 at 04:53:24PM +0200, Christoph Biedl wrote:
> > Hi there,
> >
> > I'm having trouble with btrfs where removing a snapshot causes a
> > kernel Oops at blk_get_backing_dev_info+0x10/0x1c (plus or minus a
> > byte bytes). Is this a known issue? Else I'll dig further. Stack
> > traces below.
>
> Can you use gdb to locate the line of blk_get_backing_dev_info+0x10/0x1c?
The helper is trivial:
89 struct backing_dev_info *blk_get_backing_dev_info(struct block_device *bdev)
90 {
91 struct request_queue *q = bdev_get_queue(bdev);
92
93 return &q->backing_dev_info;
94 }
There are 2 dereferences:
Dump of assembler code for function blk_get_backing_dev_info:
0xc12aa3c0 <+0>: push %ebp
0xc12aa3c1 <+1>: mov %esp,%ebp
0xc12aa3c3 <+3>: call 0xc15cbd90 <mcount>
first deref is ok
0xc12aa3c8 <+8>: mov 0x5c(%eax),%eax
0xc12aa3cb <+11>: pop %ebp
0xc12aa3cc <+12>: mov 0x210(%eax),%eax
this one crashes
0xc12aa3d2 <+18>: add $0xe8,%eax
0xc12aa3d7 <+23>: ret
863 static inline struct request_queue *bdev_get_queue(struct block_device *bdev)
864 {
865 return bdev->bd_disk->queue; /* this is never NULL */
866 }
so bdev or bdev->bd_disk might be NULL, but according to the offsets it seems to
be 'bdev->bd_disk'. Strangely, pahole (the structure dumper) does not work here
on the 32bit vmlinux so I can't check excactly, but in the 64bit build the offset
of bd_disk is 152, if we subtract padding and 4B per pointer, this looks plausible.
Anyawy, this is below btrfs layer.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
