From patchwork Mon Sep 26 16:50:24 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Catalin Marinas X-Patchwork-Id: 116451 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 64C7BB6F75 for ; Tue, 27 Sep 2011 02:54:47 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752045Ab1IZQy2 (ORCPT ); Mon, 26 Sep 2011 12:54:28 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:37266 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751947Ab1IZQy1 (ORCPT ); Mon, 26 Sep 2011 12:54:27 -0400 Received: from e102109-lin.cambridge.arm.com (e102109-lin.cambridge.arm.com [10.1.77.70]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id p8QGn311029471; Mon, 26 Sep 2011 17:49:03 +0100 (BST) Date: Mon, 26 Sep 2011 17:50:24 +0100 From: Catalin Marinas To: Eric Dumazet Cc: Huajun Li , "linux-mm@kvack.org" , netdev , linux-kernel , Tejun Heo , Christoph Lameter Subject: Re: Question about memory leak detector giving false positive report for net/core/flow.c Message-ID: <20110926165024.GA21617@e102109-lin.cambridge.arm.com> References: <1317054774.6363.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1317054774.6363.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> user-agent: Mutt/1.5.20 (2009-06-14) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Sep 26, 2011 at 05:32:54PM +0100, Eric Dumazet wrote: > Le lundi 26 septembre 2011 à 23:17 +0800, Huajun Li a écrit : > > Memory leak detector gives following memory leak report, it seems the > > report is triggered by net/core/flow.c, but actually, it should be a > > false positive report. > > So, is there any idea from kmemleak side to fix/disable this false > > positive report like this? > > Yes, kmemleak_not_leak(...) could disable it, but is it suitable for this case ? ... > CC lkml and percpu maintainers (Tejun Heo & Christoph Lameter ) as well > > AFAIK this false positive only occurs if percpu data is allocated > outside of embedded pcu space. > > (grep pcpu_get_vm_areas /proc/vmallocinfo) > > I suspect this is a percpu/kmemleak cooperation problem (a missing > kmemleak_alloc() ?) > > I am pretty sure kmemleak_not_leak() is not the right answer to this > problem. kmemleak_not_leak() definitely not the write answer. The alloc_percpu() call does not have any kmemleak_alloc() callback, so it doesn't scan them. Huajun, could you please try the patch below: 8<-------------------------------- kmemleak: Handle percpu memory allocation From: Catalin Marinas This patch adds kmemleak callbacks from the percpu allocator, reducing a number of false positives caused by kmemleak not scanning such memory blocks. Reported-by: Huajun Li Signed-off-by: Catalin Marinas --- mm/percpu.c | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/mm/percpu.c b/mm/percpu.c index bf80e55..c47a90b 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -67,6 +67,7 @@ #include #include #include +#include #include #include @@ -833,7 +834,9 @@ fail_unlock_mutex: */ void __percpu *__alloc_percpu(size_t size, size_t align) { - return pcpu_alloc(size, align, false); + void __percpu *ptr = pcpu_alloc(size, align, false); + kmemleak_alloc(ptr, size, 1, GFP_KERNEL); + return ptr; } EXPORT_SYMBOL_GPL(__alloc_percpu); @@ -855,7 +858,9 @@ EXPORT_SYMBOL_GPL(__alloc_percpu); */ void __percpu *__alloc_reserved_percpu(size_t size, size_t align) { - return pcpu_alloc(size, align, true); + void __percpu *ptr = pcpu_alloc(size, align, true); + kmemleak_alloc(ptr, size, 1, GFP_KERNEL); + return ptr; } /** @@ -915,6 +920,8 @@ void free_percpu(void __percpu *ptr) if (!ptr) return; + kmemleak_free(ptr); + addr = __pcpu_ptr_to_addr(ptr); spin_lock_irqsave(&pcpu_lock, flags);