From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:35536 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S935028AbcJSATf (ORCPT ); Tue, 18 Oct 2016 20:19:35 -0400 Date: Tue, 18 Oct 2016 20:19:01 -0400 From: Chris Mason To: Linus Torvalds CC: Jens Axboe , Dave Jones , Al Viro , Josef Bacik , David Sterba , linux-btrfs , Linux Kernel , Andrew Lutomirski Subject: Re: bio linked list corruption. Message-ID: <20161019001900.GA95500@clm-mbp.thefacebook.com> References: <20161011144507.okg6baqvodn2m2lh@codemonkey.org.uk> <20161018224205.bjgloslaxcej2td2@codemonkey.org.uk> <20161018233148.GA93792@clm-mbp.masoncoding.com> <20161018234248.GB93792@clm-mbp.masoncoding.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Tue, Oct 18, 2016 at 05:10:56PM -0700, Linus Torvalds wrote: >On Tue, Oct 18, 2016 at 4:42 PM, Chris Mason wrote: >> >> Seems to be the whole thing: > >Ahh. On lkml, so I do have it in my mailbox, but Dave changed the >subject line when he tested on ext4 rather than btrfs.. > >Anyway, the corrupted address is somewhat interesting. As Dave Jones >said, he saw > > list_add corruption. prev->next should be next (ffffe8ffff806648), >but was ffffc9000067fcd8. (prev=ffff880503878b80). > list_add corruption. prev->next should be next (ffffe8ffffc05648), >but was ffffc9000028bcd8. (prev=ffff880503a145c0). > >and Dave Chinner reports > > list_add corruption. prev->next should be next (ffffe8ffffc02808), >but was ffffc90005f6bda8. (prev=ffff88013363bb80). > >and it's worth noting that the "but was" is a remarkably consistent >vmalloc address (the ffffc9000.. pattern gives it away). In fact, it's >identical across two boots for DaveJ in the low 14 bits, and fairly >high up in those low 14 bots (0x3cd8). > >DaveC has a different address, but it's also in the vmalloc space, and >also looks like it is fairly high up in 14 bits (0x3da8). So in both >cases it's almost certainly a stack address with a fairly empty stack. >The differences are presumably due to different kernel configurations >and/or just different filesystems calling the same function that does >the same bad thing but now at different depths in the stack. > >Adding Andy to the cc, because this *might* be triggered by the >vmalloc stack code itself. Maybe the re-use of stacks showing some >problem? Maybe Chris (who can't see the problem) doesn't have >CONFIG_VMAP_STACK enabled? CONFIG_VMAP_STACK=y, but maybe I just need to hammer on process creation more. I'm testing in a hugely stripped down VM, so Dave might have more background stuff going on. -chris