From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753592AbcD0Jkf (ORCPT ); Wed, 27 Apr 2016 05:40:35 -0400 Received: from s3.sipsolutions.net ([5.9.151.49]:50225 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751704AbcD0Jkd (ORCPT ); Wed, 27 Apr 2016 05:40:33 -0400 Message-ID: <1461750029.3723.5.camel@sipsolutions.net> Subject: Re: kmemleak - percpu reliability? From: Johannes Berg To: Catalin Marinas Cc: linux-kernel Date: Wed, 27 Apr 2016 11:40:29 +0200 In-Reply-To: (sfid-20160427_113901_899678_20B2C838) References: <1461747634.3723.4.camel@sipsolutions.net> (sfid-20160427_113901_899678_20B2C838) Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.1-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2016-04-27 at 10:38 +0100, Catalin Marinas wrote: >  > Kmemleak tries to reduce the false positives to the detriment of more > false negatives. :) > One way it does this is by having to scan the memory > twice and no changes to the leaked object (crc32) should have > happened. It also scans the task stacks which is another source of > false/stale pointers. The leak may eventually be reported but you > can't really be precise on when this would be. > Ok, fair enough. I don't remember if I asked it to scan twice, but anyway, I did convince myself separately (with prints) that it was leaked :) Thanks for the explanation! johannes