| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <565EC9F4.2050401@profitbricks.com> Date: Wed, 2 Dec 2015 11:37:40 +0100 From: Michael Wang <yun.wang@...fitbricks.com> To: Joerg Roedel <joro@...tes.org> Cc: iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org Subject: Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists