On Wed, Sep 26, 2012 at 1:14 AM, Goffredo Baroncelli <kreij...@libero.it> wrote: > On 09/25/2012 12:14 PM, David Sterba wrote: >> >> On Tue, Sep 25, 2012 at 10:02:16AM +0800, zwu.ker...@gmail.com wrote: >>> >>> From: Zhi Yong Wu<wu...@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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/