Messages in this thread | | | Date | Wed, 26 Sep 2012 10:58:26 +0800 | Subject | Re: [PATCH v2 2/2] btrfs-progs: Fix up memory leakage | From | Zhi Yong Wu <> |
| |
On Wed, Sep 26, 2012 at 1:14 AM, Goffredo Baroncelli <kreijack@libero.it> wrote: > On 09/25/2012 12:14 PM, David Sterba wrote: >> >> On Tue, Sep 25, 2012 at 10:02:16AM +0800, zwu.kernel@gmail.com wrote: >>> >>> From: Zhi Yong Wu<wuzhy@linux.vnet.ibm.com> >>> >>> Some code pathes forget to free memory on exit. >> >> >> Same as with the fd's, kernel will free all memory for us at exit(). > > > I strongly disagree with this approach. The callee often don't know what > happen after and before the call. The same is true for the programmer, > because the code is quite often updated by several people. A clean exit() is > the right thing to do as general rule. I don't see any valid reason (in the > btrfs context) to do otherwise. > > Relying on the exit() for a proper clean-up increase the likelihood of bug > when the code evolves (see my patch [RESPOST][BTRFS-PROGS][PATCH] > btrfs_read_dev_super(): uninitialized variable for an example of what means > an incorrect deallocation of resource). > > >> If there's lots of memory allocated, it may be even faster to leave the >> unallocation process to kernel as it will do it in one go, while the >> application would unnecessarily free it chunk by chunk. > > > May be I am wrong, but I don't think that the increase of speed of the btrfs > "command" is even measurable relying on exit instead of free()-ing each > chunk of memory one at time.... The same should be true for the > open()/close()
I fully agree with you. In one same function, i find that some code path free system sources, while other code path doesn't. This is one nice way.
> > My 2¢ > > BR > G.Baroncelli > >> >> david >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> . >> >
-- Regards,
Zhi Yong Wu -- 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/
| |