From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751796AbdIEOj5 (ORCPT ); Tue, 5 Sep 2017 10:39:57 -0400 Received: from foss.arm.com ([217.140.101.70]:41470 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751646AbdIEOj4 (ORCPT ); Tue, 5 Sep 2017 10:39:56 -0400 Date: Tue, 5 Sep 2017 15:39:51 +0100 From: Catalin Marinas To: Dmitry Vyukov Cc: Steven Rostedt , LKML , Andrey Ryabinin , kasan-dev Subject: Re: kmemleak not always catching stuff Message-ID: <20170905143950.phynpbmulndh6k7x@armageddon.cambridge.arm.com> References: <20170901183311.3bf3348a@gandalf.local.home> <20170904100904.v5soe2afqebogefv@armageddon.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 05, 2017 at 04:23:47PM +0200, Dmitry Vyukov wrote: > On Mon, Sep 4, 2017 at 12:09 PM, Catalin Marinas > wrote: > > I also need to find > > some time to implement a "stopscan" command which uses stop_machine() > > and skips the heuristics for reducing false positives. > > "stopscan" would be great. We would like to deploy continuous testing > with kmemleak, but while it has systematic false positives, it is not > possible. Performance kinda matters, but only when a tool does not > have false positives. We probably will just not enable it on all > machines (it introduces significant slowdown even today). The downside is that scanning may take minutes. I would expect some RCU warnings once scanning is done. -- Catalin