Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1530723yba; Sat, 27 Apr 2019 01:15:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZUx2UMS2NzMn8cosSvxTsgHpLT0/I7Qecz0QA4svUPh9R0H7Vh73tQC+nZffPAzhw7ZnK X-Received: by 2002:a63:7d0a:: with SMTP id y10mr47674333pgc.292.1556352912925; Sat, 27 Apr 2019 01:15:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556352912; cv=none; d=google.com; s=arc-20160816; b=O4G+6+TqFjrS0TkbEK5KW+GDzTXtInR9dJJomSDGwNt1ZdaVbA5CBkeUbKp10XWPX0 OePxk9gVfOTOADzNmdSwl44PWAmFiCKO7Qeubt3gDX0OVq2aHCcToS078q4Sa1KL/jM3 xzQ/TzWVE9HtkS8i0N23EAbenxrsai53idrOQ99EKmm0uRxQrsJm08JLcY/MCE6OPnne myDvPpcd40el/ye3IXO1z7wqRSV1SAaNhCU8jltiEVe0yWLCq9X5U+jHtyN6kyW7HsMD XODPIqMGcdNkN7CI2POjoaoxT+4OFqWlsDY2CSGc3Pf544o/ST3bkFM6YbGSP8oUpNWC 1/3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=LxMt71c++2xcmnnhpZGwaZOxC7Qlo62UTcL06iM95BE=; b=CcLhFtMwo7qIBIYTy/JOHirpLempeRjFsESMs8/jI9k075fscoAPhhrg77TCAMsZBK s0raI12jKlIhPQOX9Zo7yHhPJ/8r9NMY34FWLlhqseWU5fDpQAROiQzNUwaWZcFjjmyw LxJlleCaKR6vty4MzDv+1r1YkGptBLs+pjnBcz139BAV4SpXjtlQcQFy8wenaiyl0qju /K6Dtpw8jXph8ZvFCA+0q3PB+guERhz7f6ok8OcE9ZQY8L8bF4hzvW0Bze4wvSBkj1MU f1a/d7MfnEhHuJ8PrFgGt1uVpYOvO1xS8AHB7AEODMwRkvCBe2s++T27xlwleetYo8Ze 9dTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tobin.cc header.s=fm3 header.b="iiMt8+/g"; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=jqpND4b1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d1si20557559plo.9.2019.04.27.01.14.57; Sat, 27 Apr 2019 01:15:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@tobin.cc header.s=fm3 header.b="iiMt8+/g"; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=jqpND4b1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726004AbfD0IOI (ORCPT + 99 others); Sat, 27 Apr 2019 04:14:08 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:50599 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725857AbfD0IOI (ORCPT ); Sat, 27 Apr 2019 04:14:08 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 61CB821BBE; Sat, 27 Apr 2019 04:14:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 27 Apr 2019 04:14:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tobin.cc; h=date :from:to:cc:subject:message-id:mime-version:content-type; s=fm3; bh=LxMt71c++2xcmnnhpZGwaZOxC7Qlo62UTcL06iM95BE=; b=iiMt8+/ggvZA +zvWLwlvdg70urd64ndoobn2Ih0Q4nS6qKRXvoy8X8fpCjA/NSd8Ey1T1Q+p/+i3 z0096p7xO+yVOAjANCs1+ZHlpWelHwtb8fJbFjrVK0xvAg3uqQTU9iGpPxSdhuHc yzcEiT19vjGCw0tG/xdHMT+PieS+XmYZojwpqxddYnlPhKninLNpTNGZEk7+JWlT UGkfgao3hvlDOOuh6wrnU/tH7jge41BUzW4hcUtYykSy4+yY7i6bwYNadr2Y+Vw9 kjOTTOZPjtL98aVK813Ug47fPHW18yN1TU+AGm2NATzBo5wEIn9ZOnNJuocRE/PJ SuHmxnKwPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=LxMt71c++2xcmnnhpZGwaZOxC7Qlo 62UTcL06iM95BE=; b=jqpND4b1YKYANPOCrz99th6zU31otpLqju0lSyHrVifQG VwD1MrK9L632eFiU517sZ7ZFhpFH1hBt7h02M41P2hUuoTclzSFbjgp8f46xz5lS gwwHjppBXvszrZrauGYMp/FMcIhgb+ELgmGJxsVGPN91A3YcoDh5wKHb8uyxChpV +zfjNliewe3+mEXDp04otD5ILRTTi2s2QdHuNCSnHaN4JlVcmKOqNEzcoSVmNhbh pND4EcnZCBm7ApnWLTNg7Np/s/qIWWqM6fARZp5Baco0c5z3yKOStGH1BHzmHvtv MKVNVPprNDRETucQXlOJ8PzJl7qDTqtYJeRFiCTSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrheekgddtvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfg hrlhcuvffnffculdeftddmnecujfgurhepfffhvffukfggtgguofgfsehttdertdforedv necuhfhrohhmpedfvfhosghinhcuvedrucfjrghrughinhhgfdcuoehmvgesthhosghinh drtggtqeenucfkphepuddvgedrudeiledrudehledrvddutdenucfrrghrrghmpehmrghi lhhfrhhomhepmhgvsehtohgsihhnrdgttgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost (124-169-159-210.dyn.iinet.net.au [124.169.159.210]) by mail.messagingengine.com (Postfix) with ESMTPA id BC609E432B; Sat, 27 Apr 2019 04:14:05 -0400 (EDT) Date: Sat, 27 Apr 2019 18:13:30 +1000 From: "Tobin C. Harding" To: Greg Kroah-Hartman , "Rafael J. Wysocki" Cc: cl@linux.com, tycho@tycho.ws, willy@infradead.org, linux-kernel@vger.kernel.org Subject: memleak around kobject_init_and_add() Message-ID: <20190427081330.GA26788@eros.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailer: Mutt 1.11.4 (2019-03-13) User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (Note at bottom on reasons for 'To' list 'Cc' list) Hi, kobject_init_and_add() seems to be routinely misused. A failed call to this function requires a call to kobject_put() otherwise we leak memory. Examples memleaks can be seen in: mm/slub.c fs/btrfs/sysfs.c fs/xfs/xfs_sysfs.h: xfs_sysfs_init() Question: Do we fix the misuse or fix the API? $ git grep kobject_init_and_add | wc -l 117 Either way, we will have to go through all 117 call sites and check them. I don't mind fixing them all but I don't want to do it twice because I chose the wrong option. Reaching out to those more experienced for a suggestion please. Fix the API ----------- Typically init functions do not require cleanup if they fail, this argument leads to this patch diff --git a/lib/kobject.c b/lib/kobject.c index aa89edcd2b63..62328054bbd0 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -453,6 +453,9 @@ int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype, retval = kobject_add_varg(kobj, parent, fmt, args); va_end(args); + if (retval) + kobject_put(kobj); + return retval; } EXPORT_SYMBOL_GPL(kobject_init_and_add); Fix all the call sites ---------------------- Go through all 117 call sites and add kobj_put() in the error path. This example from mm/slub.c diff --git a/mm/slub.c b/mm/slub.c index d30ede89f4a6..84a9d6c06c27 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -5756,8 +5756,10 @@ static int sysfs_slab_add(struct kmem_cache *s) s->kobj.kset = kset; err = kobject_init_and_add(&s->kobj, &slab_ktype, NULL, "%s", name); - if (err) + if (err) { + kobject_put(&s->kobj); goto out; + } err = sysfs_create_group(&s->kobj, &slab_attr_group); if (err) thanks, Tobin. This is a Saturday afternoon 'drinking some wine, hacking on the kernel' email. Sending it to the lib/kobject.c maintainers for obvious reasons. CC'd a few extra people who I thought might be interested to take the weight of Greg and Rafael :)