> > Hmm, I guess it's cool to get the allocation-specific decoding which you > > don't get from the generic kernel leak tracking?
I mean that by doing this in btrfs, instead of doing it generically in the allocator, you get specific knowledge that btrfs knows about the allocated objects: > > > + printk(KERN_ERR "btrfs ext map leak: start %llu len %llu block > > > %llu flags %llu refs %d in tree %d compress %d\n", > > > + em->start, em->len, em->block_start, em->flags, > > > atomic_read(&em->refs), em->in_tree, em->compress_type); That's valuable. I understand that it's quick and easy to implement this in btrfs. It's hard to argue with working code. But the right way to do this would be to add a callback that kmem_cache_destroy() can use to generate debugging output for the allocated objects. Maybe you have a registration function that sets the callback on the slab? Slab already has tracking of allocated objects so you could always have this leak output on without runtime overhead. And, of course, other callers can easy also get this functionality instead of having to mess around with all the stuff btrfs did: ifdefs, locks, and lists. - z -- 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
