Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755749Ab1C3KIv (ORCPT ); Wed, 30 Mar 2011 06:08:51 -0400 Received: from mail-qy0-f181.google.com ([209.85.216.181]:57785 "EHLO mail-qy0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754431Ab1C3KIt (ORCPT ); Wed, 30 Mar 2011 06:08:49 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ME5/GtQR/XDnLfTKBmETJTLN6EcE2m4MeXCO5FWdlNRwMvycOFs6Ds/73jzi5N3c+v kUMLad1vTGLOkhdDi0DHMpwdt+kRM9b3yDUU8l8nh9u84ImUOLpnxyyPCP3ybnfD4XhX QjldMs4+GKZCmnwxWJBoq+6ufKWl6g6Y/Uy+o= MIME-Version: 1.0 In-Reply-To: <1301476505.29074.47.camel@e102109-lin.cambridge.arm.com> References: <9bde694e1003020554p7c8ff3c2o4ae7cb5d501d1ab9@mail.gmail.com> <1300960540.32158.13.camel@e102109-lin.cambridge.arm.com> <1301395206.583.53.camel@e102109-lin.cambridge.arm.com> <1301399454.583.66.camel@e102109-lin.cambridge.arm.com> <1301476505.29074.47.camel@e102109-lin.cambridge.arm.com> Date: Wed, 30 Mar 2011 11:08:48 +0100 Message-ID: Subject: Re: kmemleak for MIPS From: Maxin John To: Catalin Marinas Cc: Daniel Baluta , naveen yadav , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2688 Lines: 75 Hi, > If you for the kmemleak scan (via echo) a few times, do you get more > leaks? Yes. I am getting some leaks after the scan. > The udp_table_init() function looks like it could leak some > memory but I haven't seen it before. I'm not sure whether this is a > false positive or a real leak. As Daniel suggested, this could be a real leak . However, we need to confirm this. udp_table_init() -> alloc_large_system_hash() -> alloc_pages_exact() followed by kmemleak_alloc() > I think the last line should be more like: As per your suggestion, I have modified the patch. Signed-off-by: Maxin B. John Acked-by: Catalin Marinas --- diff --git a/arch/mips/include/asm/cache.h b/arch/mips/include/asm/cache.h index 650ac9b..b4db69f 100644 --- a/arch/mips/include/asm/cache.h +++ b/arch/mips/include/asm/cache.h @@ -17,6 +17,6 @@ #define SMP_CACHE_SHIFT L1_CACHE_SHIFT #define SMP_CACHE_BYTES L1_CACHE_BYTES -#define __read_mostly __attribute__((__section__(".data.read_mostly"))) +#define __read_mostly __attribute__((__section__(".data..read_mostly"))) #endif /* _ASM_CACHE_H */ diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S index 832afbb..4f10141 100644 --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -68,12 +68,14 @@ SECTIONS RODATA /* writeable */ + _sdata = .; /* Start of data section */ .data : { /* Data */ . = . + DATAOFFSET; /* for CONFIG_MAPPED_KERNEL */ INIT_TASK_DATA(PAGE_SIZE) NOSAVE_DATA CACHELINE_ALIGNED_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT) + READ_MOSTLY_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT) DATA_DATA CONSTRUCTORS } diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index df9234c..5042421 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -398,7 +398,7 @@ config SLUB_STATS config DEBUG_KMEMLEAK bool "Kernel memory leak detector" depends on DEBUG_KERNEL && EXPERIMENTAL && !MEMORY_HOTPLUG && \ - (X86 || ARM || PPC || S390 || SPARC64 || SUPERH || MICROBLAZE || TILE) + (X86 || ARM || PPC || MIPS || S390 || SPARC64 || SUPERH || MICROBLAZE || TILE) select DEBUG_FS if SYSFS select STACKTRACE if STACKTRACE_SUPPORT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/