From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932072AbaGIV7F (ORCPT ); Wed, 9 Jul 2014 17:59:05 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:34219 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751424AbaGIV7D (ORCPT ); Wed, 9 Jul 2014 17:59:03 -0400 MIME-Version: 1.0 In-Reply-To: <8761j6nr53.fsf@tassilo.jf.intel.com> References: <1404905415-9046-1-git-send-email-a.ryabinin@samsung.com> <53BDB1D6.1090605@intel.com> <8761j6nr53.fsf@tassilo.jf.intel.com> Date: Wed, 9 Jul 2014 23:59:01 +0200 Message-ID: Subject: Re: [RFC/PATCH RESEND -next 00/21] Address sanitizer for kernel (kasan) - dynamic memory error detector. From: Vegard Nossum To: Andi Kleen Cc: Dave Hansen , Andrey Ryabinin , LKML , Dmitry Vyukov , Konstantin Serebryany , Alexey Preobrazhensky , Andrey Konovalov , Yuri Gribov , Konstantin Khlebnikov , Sasha Levin , Michal Marek , Russell King , Thomas Gleixner , Ingo Molnar , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , kbuild , linux-arm-kernel@lists.infradead.org, x86 maintainers , Linux Memory Management List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9 July 2014 23:44, Andi Kleen wrote: > Dave Hansen writes: >> >> You're also claiming that "KASAN is better than all of > > better as in finding more bugs, but surely not better as in > "do so with less overhead" > >> CONFIG_DEBUG_PAGEALLOC". So should we just disallow (or hide) >> DEBUG_PAGEALLOC on kernels where KASAN is available? > > I don't think DEBUG_PAGEALLOC/SLUB debug and kasan really conflict. > > DEBUG_PAGEALLOC/SLUB is "much lower overhead but less bugs found". > KASAN is "slow but thorough" There are niches for both. > > But I could see KASAN eventually deprecating kmemcheck, which > is just incredible slow. FWIW, I definitely agree with this -- if KASAN can do everything that kmemcheck can, it is no doubt the right way forward. Vegard From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by kanga.kvack.org (Postfix) with ESMTP id E157E900002 for ; Wed, 9 Jul 2014 17:59:02 -0400 (EDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so3547457wib.12 for ; Wed, 09 Jul 2014 14:59:02 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [2a00:1450:400c:c05::230]) by mx.google.com with ESMTPS id na8si9832569wic.48.2014.07.09.14.59.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 14:59:02 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so3535953wiv.3 for ; Wed, 09 Jul 2014 14:59:01 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <8761j6nr53.fsf@tassilo.jf.intel.com> References: <1404905415-9046-1-git-send-email-a.ryabinin@samsung.com> <53BDB1D6.1090605@intel.com> <8761j6nr53.fsf@tassilo.jf.intel.com> Date: Wed, 9 Jul 2014 23:59:01 +0200 Message-ID: Subject: Re: [RFC/PATCH RESEND -next 00/21] Address sanitizer for kernel (kasan) - dynamic memory error detector. From: Vegard Nossum Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Andi Kleen Cc: Dave Hansen , Andrey Ryabinin , LKML , Dmitry Vyukov , Konstantin Serebryany , Alexey Preobrazhensky , Andrey Konovalov , Yuri Gribov , Konstantin Khlebnikov , Sasha Levin , Michal Marek , Russell King , Thomas Gleixner , Ingo Molnar , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , kbuild , linux-arm-kernel@lists.infradead.org, x86 maintainers , Linux Memory Management List On 9 July 2014 23:44, Andi Kleen wrote: > Dave Hansen writes: >> >> You're also claiming that "KASAN is better than all of > > better as in finding more bugs, but surely not better as in > "do so with less overhead" > >> CONFIG_DEBUG_PAGEALLOC". So should we just disallow (or hide) >> DEBUG_PAGEALLOC on kernels where KASAN is available? > > I don't think DEBUG_PAGEALLOC/SLUB debug and kasan really conflict. > > DEBUG_PAGEALLOC/SLUB is "much lower overhead but less bugs found". > KASAN is "slow but thorough" There are niches for both. > > But I could see KASAN eventually deprecating kmemcheck, which > is just incredible slow. FWIW, I definitely agree with this -- if KASAN can do everything that kmemcheck can, it is no doubt the right way forward. Vegard -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: vegard.nossum@gmail.com (Vegard Nossum) Date: Wed, 9 Jul 2014 23:59:01 +0200 Subject: [RFC/PATCH RESEND -next 00/21] Address sanitizer for kernel (kasan) - dynamic memory error detector. In-Reply-To: <8761j6nr53.fsf@tassilo.jf.intel.com> References: <1404905415-9046-1-git-send-email-a.ryabinin@samsung.com> <53BDB1D6.1090605@intel.com> <8761j6nr53.fsf@tassilo.jf.intel.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 9 July 2014 23:44, Andi Kleen wrote: > Dave Hansen writes: >> >> You're also claiming that "KASAN is better than all of > > better as in finding more bugs, but surely not better as in > "do so with less overhead" > >> CONFIG_DEBUG_PAGEALLOC". So should we just disallow (or hide) >> DEBUG_PAGEALLOC on kernels where KASAN is available? > > I don't think DEBUG_PAGEALLOC/SLUB debug and kasan really conflict. > > DEBUG_PAGEALLOC/SLUB is "much lower overhead but less bugs found". > KASAN is "slow but thorough" There are niches for both. > > But I could see KASAN eventually deprecating kmemcheck, which > is just incredible slow. FWIW, I definitely agree with this -- if KASAN can do everything that kmemcheck can, it is no doubt the right way forward. Vegard