Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754167AbcJKPut (ORCPT ); Tue, 11 Oct 2016 11:50:49 -0400 Received: from arcturus.aphlor.org ([188.246.204.175]:48794 "EHLO arcturus.aphlor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753481AbcJKPtn (ORCPT ); Tue, 11 Oct 2016 11:49:43 -0400 Date: Tue, 11 Oct 2016 11:49:18 -0400 From: Dave Jones To: Chris Mason Cc: Al Viro , Josef Bacik , David Sterba , linux-btrfs@vger.kernel.org, Linux Kernel Subject: Re: btrfs bio linked list corruption. Message-ID: <20161011154918.tqe44epwkpgg7azl@codemonkey.org.uk> Mail-Followup-To: Dave Jones , Chris Mason , Al Viro , Josef Bacik , David Sterba , linux-btrfs@vger.kernel.org, Linux Kernel References: <20161011144507.okg6baqvodn2m2lh@codemonkey.org.uk> <20161011151139.GD19539@ZenIV.linux.org.uk> <20161011151904.qimdy3rra63fri7n@codemonkey.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20160916 (1.7.0) X-Spam-Flag: skipped (authorised relay user) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1087 Lines: 27 On Tue, Oct 11, 2016 at 11:20:41AM -0400, Chris Mason wrote: > > > On 10/11/2016 11:19 AM, Dave Jones wrote: > > On Tue, Oct 11, 2016 at 04:11:39PM +0100, Al Viro wrote: > > > On Tue, Oct 11, 2016 at 10:45:08AM -0400, Dave Jones wrote: > > > > This is from Linus' current tree, with Al's iovec fixups on top. > > > > > > Those iovec fixups are in the current tree... > > > > ah yeah, git quietly dropped my local copy when I rebased so I didn't notice. > > > > > TBH, I don't see anything > > > in splice-related stuff that could come anywhere near that (short of > > > some general memory corruption having random effects of that sort). > > > > > > Could you try to bisect that sucker, or is it too hard to reproduce? > > > > Only hit it the once overnight so far. Will see if I can find a better way to > > reproduce today. > > This call trace is reading metadata so we can finish the truncate. I'd > say adding more memory pressure would make it happen more often. That story checks out. There were a bunch of oom's in the log before this. Dave