Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752426Ab3JARDi (ORCPT ); Tue, 1 Oct 2013 13:03:38 -0400 Received: from mail-oa0-f41.google.com ([209.85.219.41]:34745 "EHLO mail-oa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994Ab3JARDg (ORCPT ); Tue, 1 Oct 2013 13:03:36 -0400 Message-ID: <524B0065.60200@lwfinger.net> Date: Tue, 01 Oct 2013 12:03:33 -0500 From: Larry Finger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Catalin Marinas CC: Alex Dubov , LKML Subject: Re: 3.12-rc3 memory leak in module memstick References: <5249BA20.1040402@lwfinger.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1857 Lines: 39 On 10/01/2013 09:04 AM, Catalin Marinas wrote: > On 30 September 2013 18:51, Larry Finger wrote: >> On 3.12-rc3, I detected a memory leak in module memstick. The kmemleak >> results are listed below. The second output is after memstick was unloaded, >> which shows that it is not a false positive from kmemleak. >> >> larrylap:~ # echo scan > /sys/kernel/debug/kmemleak >> larrylap:~ # cat /sys/kernel/debug/kmemleak >> unreferenced object 0xffff8800ae85c190 (size 16): >> comm "kworker/u4:3", pid 685, jiffies 4294916336 (age 2831.760s) >> hex dump (first 16 bytes): >> 6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0....... >> backtrace: >> [] kmemleak_alloc+0x21/0x50 >> [] __kmalloc_track_caller+0x160/0x2f0 >> [] kvasprintf+0x5b/0x90 >> [] kobject_set_name_vargs+0x21/0x60 >> [] dev_set_name+0x3c/0x40 >> [] memstick_check+0xb8/0x340 [memstick] >> [] process_one_work+0x1d2/0x670 >> [] worker_thread+0x11a/0x370 >> [] kthread+0xd6/0xe0 >> [] ret_from_fork+0x7c/0xb0 > > The leak is most likely coming from memstick_alloc_card() on the error > path. Commit 0252c3b4f0 (memstick: struct device - replace bus_id with > dev_name(), dev_set_name()) sets allocates the device name but 'card' > is freed on the error path without freeing the name. Thanks for the analysis. From that I am quite sure I can devise a patch. Larry -- 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/