Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1281608 > unrolled thread
| Started by | Michael Wang <yun.wang@profitbricks.com> |
|---|---|
| First post | 2015-12-02 11:40 +0100 |
| Last post | 2015-12-02 12:20 +0100 |
| Articles | 3 on this page of 23 — 4 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-02 11:40 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-02 12:00 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-02 12:40 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Joerg Roedel <joro@8bytes.org> - 2015-12-02 13:00 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-02 13:40 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Joerg Roedel <joro@8bytes.org> - 2015-12-02 14:00 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-02 14:10 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Borislav Petkov <bp@alien8.de> - 2015-12-02 14:00 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-02 14:10 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-02 14:20 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-02 14:50 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Borislav Petkov <bp@alien8.de> - 2015-12-02 15:00 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-02 15:10 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Borislav Petkov <bp@alien8.de> - 2015-12-02 15:20 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-02 15:30 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Catalin Marinas <catalin.marinas@gmail.com> - 2015-12-02 18:40 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Borislav Petkov <bp@alien8.de> - 2015-12-02 19:50 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Michael Wang <yun.wang@profitbricks.com> - 2015-12-03 09:50 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Borislav Petkov <bp@alien8.de> - 2015-12-02 14:50 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Borislav Petkov <bp@alien8.de> - 2015-12-02 14:20 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Catalin Marinas <catalin.marinas@gmail.com> - 2015-12-02 12:40 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Catalin Marinas <catalin.marinas@gmail.com> - 2015-12-02 12:00 +0100
Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak Joerg Roedel <joro@8bytes.org> - 2015-12-02 12:20 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | Catalin Marinas <catalin.marinas@gmail.com> |
|---|---|
| Date | 2015-12-02 12:40 +0100 |
| Subject | Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak |
| Message-ID | <qBdVo-6zq-15@gated-at.bofh.it> |
| In reply to | #1281622 |
On 2 December 2015 at 10:56, Michael Wang <yun.wang@profitbricks.com> 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 you pick this patch? >> >> My preference (from a kmemleak perspective) is to tell kmemleak about >> the irq_lookup_table. Untested: > > I'm fine with both solution, will leave the decision to maintainer :-) > > BTW, could you please send a formal patch with descriptions? 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 badly re-formatted by gmail), I don't really mind which author it is (I found it easier to show a diff than explain in plain English ;)). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Catalin Marinas <catalin.marinas@gmail.com> |
|---|---|
| Date | 2015-12-02 12:00 +0100 |
| Subject | Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak |
| Message-ID | <qBdiF-64Q-3@gated-at.bofh.it> |
| In reply to | #1281608 |
On 2 December 2015 at 10:37, Michael Wang <yun.wang@profitbricks.com> 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
>>>> 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?
My preference (from a kmemleak perspective) is to tell kmemleak about
the irq_lookup_table. Untested:
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 <linux/amd-iommu.h>
#include <linux/export.h>
#include <linux/iommu.h>
+#include <linux/kmemleak.h>
#include <asm/pci-direct.h>
#include <asm/iommu.h>
#include <asm/gart.h>
@@ -1692,6 +1693,7 @@ static struct syscore_ops amd_iommu_syscore_ops = {
static void __init free_on_init_error(void)
{
+ kmemleak_free(irq_lookup_table);
free_pages((unsigned long)irq_lookup_table,
get_order(rlookup_table_size));
@@ -1906,6 +1908,7 @@ static int __init early_amd_iommu_init(void)
irq_lookup_table = (void *)__get_free_pages(
GFP_KERNEL | __GFP_ZERO,
get_order(rlookup_table_size));
+ kmemleak_alloc(irq_lookup_table, rlookup_table_size, 1, GFP_KERNEL);
if (!irq_lookup_table)
goto out;
}
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Joerg Roedel <joro@8bytes.org> |
|---|---|
| Date | 2015-12-02 12:20 +0100 |
| Message-ID | <qBdC1-6rp-13@gated-at.bofh.it> |
| In reply to | #1281626 |
On Wed, Dec 02, 2015 at 10:52:02AM +0000, 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 <linux/amd-iommu.h>
> #include <linux/export.h>
> #include <linux/iommu.h>
> +#include <linux/kmemleak.h>
> #include <asm/pci-direct.h>
> #include <asm/iommu.h>
> #include <asm/gart.h>
> @@ -1692,6 +1693,7 @@ static struct syscore_ops amd_iommu_syscore_ops = {
>
> static void __init free_on_init_error(void)
> {
> + kmemleak_free(irq_lookup_table);
> free_pages((unsigned long)irq_lookup_table,
> get_order(rlookup_table_size));
>
> @@ -1906,6 +1908,7 @@ static int __init early_amd_iommu_init(void)
> irq_lookup_table = (void *)__get_free_pages(
> GFP_KERNEL | __GFP_ZERO,
> get_order(rlookup_table_size));
> + kmemleak_alloc(irq_lookup_table, rlookup_table_size, 1, GFP_KERNEL);
> if (!irq_lookup_table)
> goto out;
> }
Yes, this looks way better.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web