> -----Original Message----- > From: Wood Scott-B07421 > Sent: Tuesday, May 05, 2015 2:42 PM > To: Rivera Jose-B46482 > Cc: Dan Carpenter; devel@xxxxxxxxxxxxxxxxxxxx; agraf@xxxxxxx; > arnd@xxxxxxxx; Sharma Bhupesh-B45370; gregkh@xxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; 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 > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
