Hi, Joerg On 11/25/2015 04:14 PM, Michael Wang wrote: > On 11/25/2015 04:08 PM, Joerg Roedel wrote: [snip] >>> This is caused by the 'irq_lookup_table' was allocated with >>> __get_free_pages() which won't create kmemleak object, thus it's >>> pointers won't be count as referencing 'irq_remap_table' in >>> kmemleak scan. >> >> Isn't it better to allocate the kmemleak object manually instead of >> ignoring all irq-table pointers? With this patch we might not notice any >> real leak of irq-tables. > > We've considered that too, but found that the irq-tables is not > dynamically alloc/free, they won't be freed once initialized, so there > is no leaking for such object :-)
Is there any more concern? actually we just want to get rid of this annoying report on obj won't leak, if you're going to create obj for 'irq_lookup_table' that's also fine for us, or will you pick this patch? Regards, Michael Wang > > Regards, > Michael Wang > >> >> >> >> Joerg >> -- 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/