Re: btrfs GPF in read_extent_buffer() while scrubbing with kernel 3.4.2

[Sami Liedes <sami.liedes@iki.fi>]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

On Tue, Jul 03, 2012 at 03:11:04PM +0200, Jan Schmidt wrote:
> > The oops is transcribed from photos, so it may contain some errors. I
> 
> You did *what*? :-) Uploading a photo would be fine, just in case that's easier
> for you the next time.

Nah, it's sometimes refreshing to do something that doesn't take too
much thinking for a while. Besides I fault myself for not having had
netconsole logging on that machine and needed to punish myself for
that omission ;)

> That's looking strange.
> 
> I checked the readahead code again: It deliberately skips locking and uses
> btrfs_node_key with a counter variable. This means, we might end up reading a
> key that's no longer actually there. However, it only operates on nodes of
> trees, not leaves. Node entries have a fixed size, so no matter what changes in
> the node, you won't reach behind the end of that node with an index that was
> valid the moment before.
> 
> As far as I see it, that algorithm is safe. It could miss some keys or do some
> extra work that's not strictly required, but it should never reach a GPF from
> btrfs_node_key.
> 
> If no other ideas come up, I'd try memtesting that machine.

Ran a full pass of memtest86+ v4.20, with no errors found. Also the
machine works very well in all other respects under heavy load.

I think I might try setting up that netconsole to see if there are any
interesting console messages before the oops... As I said, I also was
able to reproduce this on 3.4.4, so ATM I assume I'm able to reproduce
this at will.

	Sami

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]