Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753108AbZAFSZv (ORCPT ); Tue, 6 Jan 2009 13:25:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750845AbZAFSZn (ORCPT ); Tue, 6 Jan 2009 13:25:43 -0500 Received: from cam-admin0.cambridge.arm.com ([193.131.176.58]:37828 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751207AbZAFSZm (ORCPT ); Tue, 6 Jan 2009 13:25:42 -0500 Subject: Minor kmemleak report via bdev_cache_init From: Catalin Marinas To: Denis ChengRq Cc: Andrew Morton , linux-kernel Content-Type: text/plain Organization: ARM Ltd Date: Tue, 06 Jan 2009 18:25:34 +0000 Message-Id: <1231266334.21895.25.camel@pc1117.cambridge.arm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jan 2009 18:25:34.0980 (UTC) FILETIME=[2A72AC40:01C9702C] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2908 Lines: 60 Hi Denis, With the commit c2acf7b908217 (fs/block_dev.c: __read_mostly improvement and sb_is_blkdev_sb utilization), the bd_mnt is only local and kmemleak reports the corresponding vfsmnt structure as unreferenced (together with the duplicated name) since it can no longer track a valid pointer to it: unreferenced object 0xdf813848 (size 128): comm "swapper", pid 0, jiffies 4294937384 backtrace: [] kmemleak_alloc+0x144/0x27c [] kmem_cache_alloc+0x108/0x13c [] alloc_vfsmnt+0x20/0x144 [] vfs_kern_mount+0x30/0xac [] kern_mount_data+0x1c/0x20 [] bdev_cache_init+0x54/0x90 [] vfs_caches_init+0xfc/0x128 [] start_kernel+0x1f8/0x254 unreferenced object 0xdf8033d0 (size 32): comm "swapper", pid 0, jiffies 4294937384 backtrace: [] kmemleak_alloc+0x144/0x27c [] __kmalloc_track_caller+0x15c/0x194 [] kstrdup+0x3c/0x58 [] alloc_vfsmnt+0x7c/0x144 [] vfs_kern_mount+0x30/0xac [] kern_mount_data+0x1c/0x20 [] bdev_cache_init+0x54/0x90 [] vfs_caches_init+0xfc/0x128 [] start_kernel+0x1f8/0x254 Can this object be freed (as below) or should I just tell kmemleak to ignore it (or is it referenced and that's a kmemleak false positive)? diff --git a/fs/block_dev.c b/fs/block_dev.c index 349a26c..78e469c 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -344,6 +344,7 @@ void __init bdev_cache_init(void) if (IS_ERR(bd_mnt)) panic("Cannot create bdev pseudo-fs"); blockdev_superblock = bd_mnt->mnt_sb; /* For writeback */ + free_vfsmnt(bd_mnt); } /* Thanks. -- Catalin -- 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/