Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4419892ybi; Mon, 3 Jun 2019 10:32:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZNjvmceE0aixQaFqZbWO2IcgSHybVquXAE0eA0RXQnnFCVnewE+dkRMILVcjb1b3mgRLa X-Received: by 2002:aa7:9190:: with SMTP id x16mr20249041pfa.86.1559583138903; Mon, 03 Jun 2019 10:32:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559583138; cv=none; d=google.com; s=arc-20160816; b=HkfAafNEo+FXTH9jzBFeqGHjr1/wGEcu2fC9fdzBNaNXTqDfjgywhUij9mKzqfXqH4 CJQUvn4CZoMIhUSAB4GrQMAjyK3Pps4LwYZpMGXqoqlsX7Mpxbb2Hz2B9RLQZZIZZvqG fAaTSYXrZXaV9OAQqlwZ5CR5zpJXFfvBMDTeKanh9qP8ipy0nd7uAxvTI3BJxIGhhvGc CkV0+g29deIEFWgnXh7gD0aQbqxsh9KlsR/8I0CyZoVXYn0Ikxge1qOFWtXIC9iGf6uT mNjfv7hEYR6fBU0dNkko8CEQfWAd3FaJxtYY9tz0uNHjMUOC1G8N1rZqbfrGrpdkr19a NsQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=kWjmGx3Eptcjn+moi/8KQpcgOwg0syI/U3qgDJP3ppk=; b=TSRN/oXkDFY+wg0d/Xx5AESwK+n8R0M+zSITchL04xiQHHYno9IILcpBAGkOT1saa2 HhChyfYiO0cXctmHO5/TjtVqrxnhAtWVxGY2CMuzrHjM4wEicwKU9hurmRS2qn40MHQK iMEiyE/d3cghokohAW62QPAmj0Z7rP4Ess/ZTJbdUNBU9pTjIHKxUwS59L00e74L7Gr2 CjIsb63SlqS4KEBXnXkR6XJ8wdkgQ94adbxDM69gyhOnynY8Qv5rHNJzxEvpIQyjYXad Jw74EeFCeD6pmRobpGWqoaOoBAKTAn1eDGXxwGkfq6n1Y6AE/7KFD1jtk2a6H8yOvHg6 Hfpw== ARC-Authentication-Results: i=1; mx.google.com; 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 d4si21170833pfr.82.2019.06.03.10.32.02; Mon, 03 Jun 2019 10:32:18 -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; 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 S1727210AbfFCMLS (ORCPT + 99 others); Mon, 3 Jun 2019 08:11:18 -0400 Received: from mx2.suse.de ([195.135.220.15]:54598 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727154AbfFCMLS (ORCPT ); Mon, 3 Jun 2019 08:11:18 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 2D093AF0F; Mon, 3 Jun 2019 12:11:17 +0000 (UTC) Date: Mon, 3 Jun 2019 14:11:16 +0200 (CEST) From: Miroslav Benes To: YueHaibing cc: jeyu@kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, paulmck@linux.ibm.com Subject: Re: [PATCH v2] kernel/module: Fix mem leak in module_add_modinfo_attrs In-Reply-To: <20190530134304.4976-1-yuehaibing@huawei.com> Message-ID: References: <20190515161212.28040-1-yuehaibing@huawei.com> <20190530134304.4976-1-yuehaibing@huawei.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 May 2019, YueHaibing wrote: > In module_add_modinfo_attrs if sysfs_create_file > fails, we forget to free allocated modinfo_attrs > and roll back the sysfs files. > > Fixes: 03e88ae1b13d ("[PATCH] fix module sysfs files reference counting") > Signed-off-by: YueHaibing > --- > v2: free from '--i' instead of 'i--' > --- > kernel/module.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/kernel/module.c b/kernel/module.c > index 6e6712b..78e21a7 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -1723,15 +1723,29 @@ static int module_add_modinfo_attrs(struct module *mod) > return -ENOMEM; > > temp_attr = mod->modinfo_attrs; > - for (i = 0; (attr = modinfo_attrs[i]) && !error; i++) { > + for (i = 0; (attr = modinfo_attrs[i]); i++) { > if (!attr->test || attr->test(mod)) { > memcpy(temp_attr, attr, sizeof(*temp_attr)); > sysfs_attr_init(&temp_attr->attr); > error = sysfs_create_file(&mod->mkobj.kobj, > &temp_attr->attr); > + if (error) > + goto error_out; > ++temp_attr; > } > } > + > + return 0; > + > +error_out: > + for (; (attr = &mod->modinfo_attrs[i]) && i >= 0; --i) { > + if (!attr->attr.name) > + break; > + sysfs_remove_file(&mod->mkobj.kobj, &attr->attr); > + if (attr->free) > + attr->free(mod); > + } > + kfree(mod->modinfo_attrs); > return error; > } Hi, would not be better to reuse the existing code in module_remove_modinfo_attrs() instead of duplication? You could add a new parameter "limit" or something and call the function here. I suppose the order does not matter and if it does you could rename it "start" and go backwards like in your patch. Btw, looking more into it, it would also be possible to let mod_sysfs_setup() go to out_unreg_modinfo_attrs in case of an error from module_add_modinfo_attrs() (and then clean the error handling in mod_sysfs_setup() a bit). module_remove_modinfo_attrs() almost does the right thing, because it checks attr->attr.name. The only problem is the last failing attribute, because it would have attr.name set, but its sysfs_create_file() failed. So calling sysfs_remove_file() and the rest would not be correct in that case. Miroslav