From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753282AbcG2Rbe (ORCPT ); Fri, 29 Jul 2016 13:31:34 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35886 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752681AbcG2Rbc (ORCPT ); Fri, 29 Jul 2016 13:31:32 -0400 Subject: Re: [4.7+] various memory corruption reports. To: Dave Jones , Linux Kernel , Linus Torvalds , "linux-mm@kvack.org" References: <20160729150513.GB29545@codemonkey.org.uk> <20160729151907.GC29545@codemonkey.org.uk> <20160729154929.GA30611@codemonkey.org.uk> From: Andrey Ryabinin Message-ID: <579B9339.7030707@gmail.com> Date: Fri, 29 Jul 2016 20:32:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160729154929.GA30611@codemonkey.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/29/2016 06:49 PM, Dave Jones wrote: > On Fri, Jul 29, 2016 at 06:21:12PM +0300, Andrey Ryabinin wrote: > > 2016-07-29 18:19 GMT+03:00 Dave Jones : > > > On Fri, Jul 29, 2016 at 11:05:14AM -0400, Dave Jones wrote: > > > > I've just gotten back into running trinity on daily pulls of master, and it seems pretty horrific > > > > right now. I can reproduce some kind of memory corruption within a couple minutes runtime. > > > > > > > > ,,, > > > > > > > > I'll work on narrowing down the exact syscalls needed to trigger this. > > > > > > Even limiting it to do just a simple syscall like execve (which fails most the time in trinity) > > > triggers it, suggesting it's not syscall related, but the fact that trinity is forking/killing > > > tons of processes at high rate is stressing something more fundamental. > > > > > > Given how easy this reproduces, I'll see if bisecting gives up something useful. > > > > I suspect this is false positives due to changes in KASAN. > > Bisection probably will point to > > 80a9201a5965f4715d5c09790862e0df84ce0614 ("mm, kasan: switch SLUB to > > stackdepot, enable memory quarantine for SLUB)" > > good call. reverting that changeset seems to have solved it. > Unfortunately, I wasn't able to reproduce it. Could you please try with this? --- mm/kasan/kasan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c index b6f99e8..bf25340 100644 --- a/mm/kasan/kasan.c +++ b/mm/kasan/kasan.c @@ -543,8 +543,8 @@ bool kasan_slab_free(struct kmem_cache *cache, void *object) switch (alloc_info->state) { case KASAN_STATE_ALLOC: alloc_info->state = KASAN_STATE_QUARANTINE; - quarantine_put(free_info, cache); set_track(&free_info->track, GFP_NOWAIT); + quarantine_put(free_info, cache); kasan_poison_slab_free(cache, object); return true; case KASAN_STATE_QUARANTINE: -- 2.7.3