From: Dave Young on
On Thu, Jun 10, 2010 at 9:16 AM, Rik van Riel <riel(a)redhat.com> wrote:
> On Wed, 9 Jun 2010 17:19:02 +0800
> Dave Young <hidave.darkstar(a)gmail.com> wrote:
>
>> > Manually bisected mm patches, the memleak caused by following patch:
>> >
>> > mm-extend-ksm-refcounts-to-the-anon_vma-root.patch
>>
>>
>> So I guess the refcount break, either drop-without-get or over-drop
>
> I'm guessing I did not run the kernel with enough debug options enabled
> when I tested my patches...
>
> Dave & Catalin, thank you for tracking this down.
>
> Dave, does the below patch fix your issue?

Yes, it fixed the issue. Thanks.

Tested-by: Dave Young <hidave.darkstar(a)gmail.com>

>
> Andrew, if the patch below works, you'll probably want to merge it as
> mm-extend-ksm-refcounts-to-the-anon_vma-root-fix.patch :)
>
> ----------------
>
> With the new anon_vma code we take a refcount on the root anon_vma.
> However, the root anon_vma does not have a refcount on itself, so
> we should not try to do a drop on itself when it is being unlinked.
>
> Signed-off-by: Rik van Riel <riel(a)redhat.com>
>
> --- linux-2.6-rtavma/mm/rmap.c.orig     2010-06-09 21:10:07.349376896 -0400
> +++ linux-2.6-rtavma/mm/rmap.c  2010-06-09 21:10:24.180406299 -0400
> @@ -275,7 +275,8 @@ static void anon_vma_unlink(struct anon_
>
>        if (empty) {
>                /* We no longer need the root anon_vma */
> -               drop_anon_vma(anon_vma->root);
> +               if (anon_vma->root != anon_vma)
> +                       drop_anon_vma(anon_vma->root);
>                anon_vma_free(anon_vma);
>        }
>  }
>



--
Regards
dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Catalin Marinas on
Dave,

On Thu, 2010-06-10 at 02:30 +0100, Dave Young wrote:
> On Thu, Jun 10, 2010 at 9:16 AM, Rik van Riel <riel(a)redhat.com> wrote:
> > On Wed, 9 Jun 2010 17:19:02 +0800
> > Dave Young <hidave.darkstar(a)gmail.com> wrote:
> >
> >> > Manually bisected mm patches, the memleak caused by following patch:
> >> >
> >> > mm-extend-ksm-refcounts-to-the-anon_vma-root.patch
> >>
> >>
> >> So I guess the refcount break, either drop-without-get or over-drop
> >
> > I'm guessing I did not run the kernel with enough debug options enabled
> > when I tested my patches...
> >
> > Dave & Catalin, thank you for tracking this down.
> >
> > Dave, does the below patch fix your issue?
>
> Yes, it fixed the issue. Thanks.

Thanks for investigating this issue.

BTW, without my kmemleak nobootmem patch (and CONFIG_NOBOOTMEM enabled),
do you get other leaks (false positives). If my patch fixes the
nobootmem problem, can I add a Tested-by: Dave Young?

Thanks.

--
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Young on
On Thu, Jun 10, 2010 at 7:21 PM, Catalin Marinas
<catalin.marinas(a)arm.com> wrote:
> Dave,
>
> On Thu, 2010-06-10 at 02:30 +0100, Dave Young wrote:
>> On Thu, Jun 10, 2010 at 9:16 AM, Rik van Riel <riel(a)redhat.com> wrote:
>> > On Wed, 9 Jun 2010 17:19:02 +0800
>> > Dave Young <hidave.darkstar(a)gmail.com> wrote:
>> >
>> >> > Manually bisected mm patches, the memleak caused by following patch:
>> >> >
>> >> > mm-extend-ksm-refcounts-to-the-anon_vma-root.patch
>> >>
>> >>
>> >> So I guess the refcount break, either drop-without-get or over-drop
>> >
>> > I'm guessing I did not run the kernel with enough debug options enabled
>> > when I tested my patches...
>> >
>> > Dave & Catalin, thank you for tracking this down.
>> >
>> > Dave, does the below patch fix your issue?
>>
>> Yes, it fixed the issue. Thanks.
>
> Thanks for investigating this issue.
>
> BTW, without my kmemleak nobootmem patch (and CONFIG_NOBOOTMEM enabled),
> do you get other leaks (false positives).

Hi, catalin

I didn't see difference before/after apply your patch, how to test
specific to bootmem?

> If my patch fixes the
> nobootmem problem, can I add a Tested-by: Dave Young?
>
> Thanks.
>
> --
> Catalin
>
>



--
Regards
dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Catalin Marinas on
Dave Young <hidave.darkstar(a)gmail.com> wrote:
> On Thu, Jun 10, 2010 at 7:21 PM, Catalin Marinas
> <catalin.marinas(a)arm.com> wrote:
>> On Thu, 2010-06-10 at 02:30 +0100, Dave Young wrote:
>>> On Thu, Jun 10, 2010 at 9:16 AM, Rik van Riel <riel(a)redhat.com> wrote:
>>> > On Wed, 9 Jun 2010 17:19:02 +0800
>>> > Dave Young <hidave.darkstar(a)gmail.com> wrote:
>>> >
>>> >> > Manually bisected mm patches, the memleak caused by following patch:
>>> >> >
>>> >> > mm-extend-ksm-refcounts-to-the-anon_vma-root.patch
>>> >>
>>> >>
>>> >> So I guess the refcount break, either drop-without-get or over-drop
>>> >
>>> > I'm guessing I did not run the kernel with enough debug options enabled
>>> > when I tested my patches...
>>> >
>>> > Dave & Catalin, thank you for tracking this down.
>>> >
>>> > Dave, does the below patch fix your issue?
>>>
>>> Yes, it fixed the issue. Thanks.
>>
>> Thanks for investigating this issue.
>>
>> BTW, without my kmemleak nobootmem patch (and CONFIG_NOBOOTMEM enabled),
>> do you get other leaks (false positives).
>
> I didn't see difference before/after apply your patch, how to test
> specific to bootmem?

With Rik's patch applied and CONFIG_NOBOOTMEM enabled, do you get any
false postives if my kmemleak patch isn't applied?

Thanks.

--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Young on
On Fri, Jun 11, 2010 at 5:17 PM, Catalin Marinas
<catalin.marinas(a)arm.com> wrote:
> Dave Young <hidave.darkstar(a)gmail.com> wrote:
>> On Thu, Jun 10, 2010 at 7:21 PM, Catalin Marinas
>> <catalin.marinas(a)arm.com> wrote:
>>> On Thu, 2010-06-10 at 02:30 +0100, Dave Young wrote:
>>>> On Thu, Jun 10, 2010 at 9:16 AM, Rik van Riel <riel(a)redhat.com> wrote:
>>>> > On Wed, 9 Jun 2010 17:19:02 +0800
>>>> > Dave Young <hidave.darkstar(a)gmail.com> wrote:
>>>> >
>>>> >> > Manually bisected mm patches, the memleak caused by following patch:
>>>> >> >
>>>> >> > mm-extend-ksm-refcounts-to-the-anon_vma-root.patch
>>>> >>
>>>> >>
>>>> >> So I guess the refcount break, either drop-without-get or over-drop
>>>> >
>>>> > I'm guessing I did not run the kernel with enough debug options enabled
>>>> > when I tested my patches...
>>>> >
>>>> > Dave & Catalin, thank you for tracking this down.
>>>> >
>>>> > Dave, does the below patch fix your issue?
>>>>
>>>> Yes, it fixed the issue. Thanks.
>>>
>>> Thanks for investigating this issue.
>>>
>>> BTW, without my kmemleak nobootmem patch (and CONFIG_NOBOOTMEM enabled),
>>> do you get other leaks (false positives).
>>
>> I didn't see difference before/after apply your patch, how to test
>> specific to bootmem?
>
> With Rik's patch applied and CONFIG_NOBOOTMEM enabled, do you get any
> false postives if my kmemleak patch isn't applied?

No more, except a few acpi issue which always there

>
> Thanks.
>
> --
> Catalin
>



--
Regards
dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/