Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757520AbbEEU00 (ORCPT ); Tue, 5 May 2015 16:26:26 -0400 Received: from mail-by2on0138.outbound.protection.outlook.com ([207.46.100.138]:51445 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753456AbbEEU0X (ORCPT ); Tue, 5 May 2015 16:26:23 -0400 From: Jose Rivera To: Scott Wood CC: Dan Carpenter , "devel@driverdev.osuosl.org" , "agraf@suse.de" , "arnd@arndb.de" , "bhupesh.sharma@freescale.com" , "gregkh@linuxfoundation.org" , "linux-kernel@vger.kernel.org" , Stuart Yoder , "nir.erez@freescale.com" , "itai.katz@freescale.com" , "bhamciu1@freescale.com" , "R89243@freescale.com" , Richard Schmitt Subject: RE: [PATCH 1/7] staging: fsl-mc: MC bus IRQ support Thread-Topic: [PATCH 1/7] staging: fsl-mc: MC bus IRQ support Thread-Index: AQHQgdtcWmwch7II+U+VbnIIkniD+51lc9iAgAbl/LCAAML6AIAAYJLAgABWJoCAAAwiAA== Date: Tue, 5 May 2015 20:26:22 +0000 Message-ID: References: <1430242750-17745-1-git-send-email-German.Rivera@freescale.com> <1430242750-17745-2-git-send-email-German.Rivera@freescale.com> <20150430114957.GW14154@mwanda> <20150505084830.GL16501@mwanda> <1430854949.16357.240.camel@freescale.com> In-Reply-To: <1430854949.16357.240.camel@freescale.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freescale.com; dkim=none (message not signed) header.d=none; x-originating-ip: [192.88.168.49] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1247; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:DM2PR0301MB1247;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1247; x-forefront-prvs: 0567A15835 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(164054003)(24454002)(51704005)(377454003)(377424004)(13464003)(2656002)(87936001)(77156002)(62966003)(92566002)(40100003)(2950100001)(99286002)(19580395003)(19580405001)(86362001)(122556002)(46102003)(2900100001)(76176999)(54356999)(50986999)(74316001)(5890100001)(106116001)(33656002)(76576001)(66066001)(110136002)(93886004)(102836002)(5001960100002)(107886002)(4001430100001)(4001450100001);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0301MB1247;H:DM2PR0301MB1309.namprd03.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2015 20:26:22.1439 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB1247 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t45KQVb5006704 Content-Length: 2161 Lines: 54 > -----Original Message----- > From: Wood Scott-B07421 > Sent: Tuesday, May 05, 2015 2:42 PM > To: Rivera Jose-B46482 > Cc: Dan Carpenter; devel@driverdev.osuosl.org; agraf@suse.de; > arnd@arndb.de; Sharma Bhupesh-B45370; gregkh@linuxfoundation.org; linux- > kernel@vger.kernel.org; Yoder Stuart-B08248; Erez Nir-RM30794; katz Itai- > RM05202; Hamciuc Bogdan-BHAMCIU1; Marginean Alexandru-R89243; Schmitt > Richard-B43082 > Subject: Re: [PATCH 1/7] staging: fsl-mc: MC bus IRQ support > > On Tue, 2015-05-05 at 11:08 -0500, Rivera Jose-B46482 wrote: > > > > > to read what "goto error;" does. The error handling here calls > > > > > devm_kfree() which is not needed... devm_ functions > > > > > automatically clean up after themselves. This seems a pattern > > > > > throughout. Do a search for > > > > > devm_free() and see which ones are really needed or not. > > > > > > > > > I know that memory allocated with devm_kzalloc() is freed at the > > > > end of the lifetime of the device it is attached to. However, in > > > > error paths, why wait until the device is destroyed? Why not free > > > > the memory earlier so that it can be used for other purposes? > > > > > Why then do the devm_kfree() function exist? > > > > I will not remove the devm_free() calls unless the upstream maintainer > > requires me to do so. > > The whole point of devm is to simplify (often poorly tested) error paths. > You're trying to optimize the error path instead of simplify it, which > doesn't make sense. > > devm_kfree() is for the uncommon case when you want to free the memory in > a situation where the device isn't being unbound any time soon, but you > still want the memory to be handled by devm for some reason. > > Most users of devm_kzalloc() do not use devm_kfree(): > scott@snotra:~/fsl/git/linux/upstream$ git grep devm_kzalloc|wc -l > 2750 > scott@snotra:~/fsl/git/linux/upstream$ git grep devm_kfree|wc -l > 118 > Ok, I'll remove the devm_kfree() calls. Thanks, German > -Scott > ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?