On 12/02/2015 06:36 PM, Catalin Marinas wrote:
> On 2 December 2015 at 13:59, Borislav Petkov wrote:
[snip]
>
> 1. The sl?b allocators themselves use page allocations, so kmemleak
> could end up detecting the same pointer twice, hiding a potential leak
>
> 2. Most page allocations do not conta
On Wed, Dec 02, 2015 at 05:36:32PM +, Catalin Marinas wrote:
> Defending kmemleak here ;).
Oh sure, by all means. I'm also assuming it comes across that I wasn't
attacking kmemleak. I had the same arguments with KASAN and other stuff
in the past.
> Tracking page allocations in kmemleak by int
On 2 December 2015 at 13:59, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 02:48:47PM +0100, Michael Wang wrote:
>> I'm not sure why amd-iommu use get_page not kmalloc to initialize the
>> pointer table, but if it's necessary then the conflict will be there,
>> it's not the fault of driver or k
On 12/02/2015 03:13 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 03:09:18PM +0100, Michael Wang wrote:
>> This tool will help improve the kernel, AFAIK it's already made it's
>> best, if you got any idea on how to make it even better that would be
>> great, but at this moment, it still ne
On Wed, Dec 02, 2015 at 03:09:18PM +0100, Michael Wang wrote:
> This tool will help improve the kernel, AFAIK it's already made it's
> best, if you got any idea on how to make it even better that would be
> great, but at this moment, it still need few of care :-P
I think you're replying to my emai
On 12/02/2015 02:59 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 02:48:47PM +0100, Michael Wang wrote:
>> I'm not sure why amd-iommu use get_page not kmalloc to initialize the
>> pointer table, but if it's necessary then the conflict will be there,
>> it's not the fault of driver or kmeml
On Wed, Dec 02, 2015 at 02:48:47PM +0100, Michael Wang wrote:
> I'm not sure why amd-iommu use get_page not kmalloc to initialize the
> pointer table, but if it's necessary then the conflict will be there,
> it's not the fault of driver or kmemleak, but the design require them
> to cooperate with e
On 12/02/2015 02:40 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 02:18:44PM +0100, Michael Wang wrote:
[snip]
>
>> Yeah, but it would be better to solve it, otherwise whoever saw this
>> report will need to go into the amd-iommu, make sure it's not a real
>> leak, then change their testi
On Wed, Dec 02, 2015 at 02:18:44PM +0100, Michael Wang wrote:
> Do you mean this could be a real kmemleak? Could you please provide
> more details?
Did you read Joerg's last mail?
> Yeah, but it would be better to solve it, otherwise whoever saw this
> report will need to go into the amd-iommu, m
Hi, Borislav
On 12/02/2015 02:13 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 02:01:55PM +0100, Michael Wang wrote:
>> Yeah.. it's a little complicated since we have our own kernel tree and this
>> won't be a problem for us, but we really prefer to help fix it in mainline
>> too, as long a
On Wed, Dec 02, 2015 at 02:01:55PM +0100, Michael Wang wrote:
> Yeah.. it's a little complicated since we have our own kernel tree and this
> won't be a problem for us, but we really prefer to help fix it in mainline
> too, as long as this is really a defect, so others could save time on research
>
On 12/02/2015 01:56 PM, Joerg Roedel wrote:
> On Wed, Dec 02, 2015 at 01:31:38PM +0100, Michael Wang wrote:
>> It's not my work or your work... it's a defect in the module and maintainer
>> should take responsibility on fixing it, correct?
>
> No, its a false positive from an in-kernel checking t
On 12/02/2015 01:53 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 01:31:38PM +0100, Michael Wang wrote:
>> It's not my work or your work... it's a defect in the module and maintainer
>> should take responsibility on fixing it, correct?
>
> Well, you said "actually we just want to get rid
On Wed, Dec 02, 2015 at 01:31:38PM +0100, Michael Wang wrote:
> It's not my work or your work... it's a defect in the module and maintainer
> should take responsibility on fixing it, correct?
No, its a false positive from an in-kernel checking tool, the iommu
driver is correct. You just sent a pat
On Wed, Dec 02, 2015 at 01:31:38PM +0100, Michael Wang wrote:
> It's not my work or your work... it's a defect in the module and maintainer
> should take responsibility on fixing it, correct?
Well, you said "actually we just want to get rid of this annoying report
on obj won't leak..."
It sounds
On 12/02/2015 12:51 PM, Joerg Roedel wrote:
> On Wed, Dec 02, 2015 at 12:38:03PM +0100, Michael Wang wrote:
>> Joerg, this is really a tiny fix, would you mind to merge it into some
>> of your cleanup patch and testing them together? we are not in hurry,
>> just want to make sure the issue will g
On Wed, Dec 02, 2015 at 12:38:03PM +0100, Michael Wang wrote:
> Joerg, this is really a tiny fix, would you mind to merge it into some
> of your cleanup patch and testing them together? we are not in hurry,
> just want to make sure the issue will get solved.
I am not doing your work. You sent a pa
On 12/02/2015 12:31 PM, Catalin Marinas wrote:
> On 2 December 2015 at 10:56, Michael Wang wrote:
[snip]
>
> I could copy your description but I don't currently have a way (nor
> time) to test the patch. If you plan to test it anyway, please feel
> free to include my diff (which I guess was badl
On 2 December 2015 at 10:56, Michael Wang wrote:
> On 12/02/2015 11:52 AM, Catalin Marinas wrote:
>>> 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
On Wed, Dec 02, 2015 at 10:52:02AM +, Catalin Marinas wrote:
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index 013bdfff2d4d..c41609f71cbe 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -27,6 +27,7 @@
> #include
>
On 12/02/2015 11:52 AM, Catalin Marinas wrote:
[snip]
>>
>> 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?
>
> My preference (fr
On 2 December 2015 at 10:37, Michael Wang wrote:
> 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
pointer
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_tabl
On 11/25/2015 04:08 PM, Joerg Roedel wrote:
> On Fri, Nov 20, 2015 at 12:33:50PM +0100, Michael Wang wrote:
>> The kmemleak testing on 3.18.24 show:
>>
>> unreferenced object 0x880233ff9010 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294937440 (age 2010.490s)
>> hex dump (first 16 bytes
On Fri, Nov 20, 2015 at 12:33:50PM +0100, Michael Wang wrote:
> The kmemleak testing on 3.18.24 show:
>
> unreferenced object 0x880233ff9010 (size 16):
> comm "swapper/0", pid 1, jiffies 4294937440 (age 2010.490s)
> hex dump (first 16 bytes):
> 0a 0a 00 00 20 00 00 00 00 44 fb 33 02 88
Hi, Joery
On 11/20/2015 12:33 PM, Michael Wang wrote:
> The kmemleak testing on 3.18.24 show:
>
> unreferenced object 0x880233ff9010 (size 16):
> comm "swapper/0", pid 1, jiffies 4294937440 (age 2010.490s)
> hex dump (first 16 bytes):
> 0a 0a 00 00 20 00 00 00 00 44 fb 33 02 88 ff ff
On 11/20/2015 12:33 PM, Michael Wang wrote:
> The kmemleak testing on 3.18.24 show:
>
> unreferenced object 0x880233ff9010 (size 16):
> comm "swapper/0", pid 1, jiffies 4294937440 (age 2010.490s)
> hex dump (first 16 bytes):
> 0a 0a 00 00 20 00 00 00 00 44 fb 33 02 88 ff ff ...
The kmemleak testing on 3.18.24 show:
unreferenced object 0x880233ff9010 (size 16):
comm "swapper/0", pid 1, jiffies 4294937440 (age 2010.490s)
hex dump (first 16 bytes):
0a 0a 00 00 20 00 00 00 00 44 fb 33 02 88 ff ff D.3
backtrace:
[] create_object+0x10d/0x2d0
28 matches
Mail list logo
