Re: btrfs on bcache

[Kent Overstreet <kmo@daterainc.com>]

On Fri, Dec 20, 2013 at 03:46:30PM +0000, Chris Mason wrote:
> On Fri, 2013-12-20 at 10:42 -0200, Fábio Pfeifer wrote:
> > Hello,
> > 
> > I put the "WARN_ON(1);" after the printk lines (incomplete page read
> > and incomplete page write) in extent_io.c.
> > 
> > here some call traces:
> > 
> > [   19.509497] incomplete page read in btrfs with offset 2560 and length 1536
> > [   19.509500] ------------[ cut here ]------------
> > [   19.509528] WARNING: CPU: 2 PID: 220 at fs/btrfs/extent_io.c:2441
> > end_bio_extent_readpage+0x788/0xc20 [btrfs]()
> > [   19.509530] Modules linked in: cdc_acm fuse iTCO_wdt
> > iTCO_vendor_support snd_hda_codec_analog coretemp kvm_intel kvm raid1
> > ext4 crc16 md_mod mbcache jbd2 microcode nvidia(PO) psmouse pcspkr
> > evdev serio_raw i2c_i801 lpc_ich i2c_core snd_hda_intel sky2 skge
> > i82975x_edac button asus_atk0110 snd_hda_codec snd_hwdep shpchp
> > snd_pcm snd_page_alloc snd_timer acpi_cpufreq snd edac_core soundcore
> > processor vboxdrv(O) sr_mod cdrom ata_generic pata_acpi hid_generic
> > usbhid hid usb_storage sd_mod pata_marvell firewire_ohci uhci_hcd ahci
> > ehci_pci firewire_core ata_piix libahci crc_itu_t ehci_hcd libata
> > scsi_mod usbcore usb_common btrfs crc32c libcrc32c xor raid6_pq bcache
> > [   19.509578] CPU: 2 PID: 220 Comm: btrfs-endio-met Tainted: P
> > W  O 3.12.5-1-ARCH #1
> > [   19.509580] Hardware name: System manufacturer System Product
> > Name/P5WDG2 WS Pro, BIOS 0905    03/06/2008
> > [   19.509581]  0000000000000009 ffff880231a63cb0 ffffffff814ee37b
> > 0000000000000000
> > [   19.509585]  ffff880231a63ce8 ffffffff81062bcd ffffea00085eaec0
> > 0000000000000000
> > [   19.509587]  ffff8802320cc9c0 0000000000000000 ffff880233b0e000
> > ffff880231a63cf8
> > [   19.509590] Call Trace:
> > [   19.509596]  [<ffffffff814ee37b>] dump_stack+0x54/0x8d
> > [   19.509601]  [<ffffffff81062bcd>] warn_slowpath_common+0x7d/0xa0
> > [   19.509603]  [<ffffffff81062caa>] warn_slowpath_null+0x1a/0x20
> > [   19.509614]  [<ffffffffa00b7ba8>] end_bio_extent_readpage+0x788/0xc20 [btrfs]
> 
> This should mean that bcache is either failing to read some blocks
> properly or is fiddling with the bv_len/bv_offset fields.
> 
> Could someone from bcache comment?

Oh man, I found this and then threw up my hands in despair.

Bcache isn't doing anything with the bv_len/bv_offset fields; it may clone the
biovec so it can retry a bio on error, if the biovecs weren't all whole pages,
otherwise it just passes the biovec down with the next bio to the underlying
cache/backing device.

What btrfs appears to be doing though - I couldn't believe that code actually
_worked_, Jens please jump in here but AFAIK bv_len/bv_offset are in practice
undefined after a bio's completed, they might have been updated if the driver
was using blk_update_request but for many drivers that just process the entire
bio all at once they just won't touch those fields - and that includes anything
that clones the bio (md/dm).

This is probably relevant to immutable biovecs here...

-------------

Ok, I looked again at the relevant btrfs code, I guess I can see how this printk
isn't normally triggered. But Chris, _what on earth_ is btrfs trying to check
for here? And why is it using bv_offset and bv_len further down in
end_bio_extent_readpage()?