only drop root anon_vma if not self
in [Kernel]
|
Prev: [PATCH 4/4] staging: rtl8192u: fix checkpatch.pl issues to line 3500 Fix most problems pointed out by checkpatch.pl in file r8192U_core.c up to line 3500
Next: MAINTAINERS: Update ARM/NUVOTON W90X900 ARM ARCHITECTURE file patterns
From: Dave Young on 9 Jun 2010 21:40 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 10 Jun 2010 07:30 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 11 Jun 2010 04:10 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 11 Jun 2010 05:20 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 11 Jun 2010 05:40
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/ |