Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757575AbcJTXDw (ORCPT ); Thu, 20 Oct 2016 19:03:52 -0400 Received: from arcturus.aphlor.org ([188.246.204.175]:53490 "EHLO arcturus.aphlor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755525AbcJTXDv (ORCPT ); Thu, 20 Oct 2016 19:03:51 -0400 Date: Thu, 20 Oct 2016 19:03:41 -0400 From: Dave Jones To: Andy Lutomirski Cc: Andy Lutomirski , Linus Torvalds , Chris Mason , Jens Axboe , Al Viro , Josef Bacik , David Sterba , linux-btrfs , Linux Kernel Subject: Re: bio linked list corruption. Message-ID: <20161020230341.jsxpia2sy53xn5l5@codemonkey.org.uk> Mail-Followup-To: Dave Jones , Andy Lutomirski , Andy Lutomirski , Linus Torvalds , Chris Mason , Jens Axboe , Al Viro , Josef Bacik , David Sterba , linux-btrfs , Linux Kernel References: <20161011144507.okg6baqvodn2m2lh@codemonkey.org.uk> <20161018224205.bjgloslaxcej2td2@codemonkey.org.uk> <20161018233148.GA93792@clm-mbp.masoncoding.com> <20161018234248.GB93792@clm-mbp.masoncoding.com> <332c8e94-a969-093f-1fb4-30d89be8993e@kernel.org> <20161020225028.czodw54tjbiwwv3o@codemonkey.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) 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: 1025 Lines: 27 On Thu, Oct 20, 2016 at 04:01:12PM -0700, Andy Lutomirski wrote: > On Thu, Oct 20, 2016 at 3:50 PM, Dave Jones wrote: > > On Tue, Oct 18, 2016 at 06:05:57PM -0700, Andy Lutomirski wrote: > > > > > One possible debugging approach would be to change: > > > > > > #define NR_CACHED_STACKS 2 > > > > > > to > > > > > > #define NR_CACHED_STACKS 0 > > > > > > in kernel/fork.c and to set CONFIG_DEBUG_PAGEALLOC=y. The latter will > > > force an immediate TLB flush after vfree. > > > > I can give that idea some runtime, but it sounds like this a case where > > we're trying to prove a negative, and that'll just run and run ? In which case I > > might do this when I'm travelling on Sunday. > > The idea is that the stack will be free and unmapped immediately upon > process exit if configured like this so that bogus stack accesses (by > the CPU, not DMA) would OOPS immediately. oh, misparsed. ok, I can definitely get behind that idea then. I'll do that next. Dave