On Thu, Jan 10, 2013 at 12:54:26PM +0100, David Sterba wrote: > On Thu, Jan 10, 2013 at 10:05:39AM +0800, Liu Bo wrote: > > On Tue, Jan 08, 2013 at 12:07:34PM -0800, Zach Brown wrote: > > > > This is for detecting extent map leak. > > > > > > Hmm, I guess it's cool to get the allocation-specific decoding which you > > > don't get from the generic kernel leak tracking? > > > > Thanks for the advice, but what allocation-specific decoding do you refer > > to? > > Could you please show me any examples? > > IMHO that there's a leak check that is targeted to one exact problem in > one subsystem (extent_map in btrfs), does not need to be poked to do a > scan-for-leaks so the leak can be reported immediatelly and not after > some time. It makes sense for such a core structure like extent_map. > Other structures are allocated from a slab so we can at least check for > leaks upon module unload.
Sorry, I don't get your point, but extent map is allocated from its slab section as well. The 'scan-for-leaks' is just for developers' debug purpose, which can tell us some information about the leaked ones, like refs, type, etc. I think I'm doing the same thing as leak debug for extent_state/extent_buffer. We can disable it as default. thanks, liubo -- 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
