Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755898AbZGGPRR (ORCPT ); Tue, 7 Jul 2009 11:17:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754530AbZGGPRI (ORCPT ); Tue, 7 Jul 2009 11:17:08 -0400 Received: from cam-admin0.cambridge.arm.com ([193.131.176.58]:56242 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751605AbZGGPRH (ORCPT ); Tue, 7 Jul 2009 11:17:07 -0400 Subject: Possible memory leak in request_firmware() From: Catalin Marinas To: Greg Kroah-Hartman , Ming Lei Cc: linux-kernel Content-Type: text/plain Organization: ARM Ltd Date: Tue, 07 Jul 2009 16:17:00 +0100 Message-Id: <1246979820.9451.71.camel@pc1117.cambridge.arm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2009 15:17:01.0105 (UTC) FILETIME=[FA08DA10:01C9FF15] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2851 Lines: 84 Hi, I get a couple kmemleak reports like below which I think happen on the failure path (-ENOENT) of a request_firmware() call: unreferenced object 0xc355fdb0 (size 256): comm "NetworkManager", pid 2606, jiffies 4294902882 backtrace: [] create_object+0xfa/0x250 [] kmemleak_alloc+0x5d/0x70 [] kmem_cache_alloc+0x14b/0x190 [] _request_firmware+0x11c/0x530 [] request_firmware+0x12/0x20 [] iwl_mac_start+0xa1/0x850 [iwlagn] [] ieee80211_open+0x2e1/0x860 [mac80211] [] dev_open+0xba/0x100 [] dev_change_flags+0x139/0x1d0 [] do_setlink+0x282/0x410 [] rtnl_setlink+0xf1/0x130 [] rtnetlink_rcv_msg+0x165/0x200 [] netlink_rcv_skb+0x76/0xa0 [] rtnetlink_rcv+0x1e/0x30 [] netlink_unicast+0x23b/0x250 [] netlink_sendmsg+0x1db/0x2d0 The f_dev in _request_firmware() is allocated via the fw_setup_device() and fw_register_device() calls and its class set to firmware_class (the class release function is fw_dev_release). Commit 6acf70f078ca replaced the kfree(dev) in fw_dev_release() with a put_device() call but my understanding is that the release function is called via put_device -> kobject_put -> kref_put -> koject_release etc. and it should call kfree since it's the last to see this device structure alive. Because of that, the _request_firmware() function on its -ENOENT error path only calls device_unregister(f_dev) which would eventually call fw_dev_release() but there is no kfree (the subsequent put_device call would just make the kref negative). The patch below may fix the problem but it's only later tonight that I can test it and confirm: diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index ddeb819..12e6e64 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -357,7 +357,7 @@ static void fw_dev_release(struct device *dev) kfree(fw_priv->pages); kfree(fw_priv->fw_id); kfree(fw_priv); - put_device(dev); + kfree(dev); module_put(THIS_MODULE); } @@ -407,14 +407,13 @@ static int fw_register_device(struct device **dev_p, const char *fw_name, retval = device_register(f_dev); if (retval) { dev_err(device, "%s: device_register failed\n", __func__); + kfree(fw_priv->fw_id); put_device(f_dev); - goto error_kfree_fw_id; + return retval; } *dev_p = f_dev; return 0; -error_kfree_fw_id: - kfree(fw_priv->fw_id); error_kfree: kfree(f_dev); kfree(fw_priv); -- 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/