[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1250156396.13180.24.camel@pc1117.cambridge.arm.com>
Date: Thu, 13 Aug 2009 10:39:56 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: kmemleak: Protect the seq start/next/stop sequence
byrcu_read_lock()
On Thu, 2009-08-13 at 08:52 +0200, Ingo Molnar wrote:
> * Catalin Marinas <catalin.marinas@....com> wrote:
>
> > On Wed, 2009-08-12 at 21:52 +0100, Ingo Molnar wrote:
> > > * Catalin Marinas <catalin.marinas@....com> wrote:
> > >
> > > > kmemleak: Allow rescheduling during an object scanning
> > >
> > > i tried this in -tip testing, and it crashes quickly:
> > >
> > > [ 81.900051] BUG: unable to handle kernel paging request at ffff880020000000
> > > [ 81.901382] IP: [<ffffffff8112ae7e>] scan_block+0xee/0x190
> >
> > It looks like my check for object->flags & OBJECT_ALLOCATED in
> > scan_object() may not be enough.
> >
> > I'm a bit confused as the config you sent says x86_32 but the
> > fault address above looks like a 64 bit one (and my knowledge of
> > x86 isn't great). Is this x86_64?
>
> ahm indeed. It crashed not straight during bootup but while my tests
> built the next kernel iteration already (with a new random config),
Looking through the code and documentation, the fault address above
seems to be the directly mapped RAM. Do you have 512MB of RAM or less on
your machine? Or is there a hole in the virtual space at that point?
--
Catalin
--
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