From: Matt Mackall <mpm@selenic.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Nick Piggin <npiggin@suse.de>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: pgd_none_or_clear_bad strangeness?
Date: Wed, 3 Oct 2007 16:31:12 -0500 [thread overview]
Message-ID: <20071003213112.GV19691@waste.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0710031910080.9414@blonde.wat.veritas.com>
On Wed, Oct 03, 2007 at 07:18:23PM +0100, Hugh Dickins wrote:
> On Wed, 3 Oct 2007, Nick Piggin wrote:
> > On Tue, Oct 02, 2007 at 05:20:03PM -0500, Matt Mackall wrote:
> > > In lib/pagewalk.c, I've been using the various forms of
> > > {pgd,pud,pmd}_none_or_clear_bad while walking page tables as that
> > > seemed the canonical way to do things. Lately (eg with -rc7-mm1),
> > > these have been triggering messages like "bad pgd 0x01e3" and causing
> > > nasty double faults. It appears this is actually triggered at the pmd
> > > level (mm/memory.c:116), though it appears to produce the wrong
> > > message.
>
> I guess the "wrong message" is an artifact of pud/pmd folding;
> but I get too confused by the different levels myself to want to
> think more about it - I'll just assume it's "right" somehow ;)
>
> > >
> > > Has something changed here? I'm pretty sure this used to work! Is this
>
> I don't know of anything changing here, sorry.
>
> > > not a kosher thing to do? Does it make any sense I'd repeatedly run
> > > into a bad pmd in the middle of bash's page table right after boot?
> > > The simple _none variant seems to work, but I worry that it's papering
> > > over a real problem.
> >
> > No, I think that should be the right thing to do for userspace pages.
> > You're not walking into a hugetlb area or a kernel mapping are you?
> > (the bad pgd: line could be important... 0x01e3 would be a linear kernel
> > mapping I think?).
>
> I should have spent more time reading Nick's reply and less time trying
> to work it out for myself! Yes, that's the conclusion I came to, for
> some reason you're now going beyond the user vmas and walking into the
> linear kernel mapping, which has _PAGE_GLOBAL and _PAGE_PSE bits set.
Indeed, that's precisely what's happening. I'm walking one page past
the end of userspace.
And the reason is I changed my walker from using for loops to do/while
loops at Nick's insistance, so start==end no longer gets noticed
immediately. This also explains why the bug doesn't manifest in
lguest: no PSE mappings.
Thanks, guys!
--
Mathematics is the supreme nostalgia of our time.
prev parent reply other threads:[~2007-10-03 21:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-02 22:20 pgd_none_or_clear_bad strangeness? Matt Mackall
2007-10-03 11:25 ` Nick Piggin
2007-10-03 18:18 ` Hugh Dickins
2007-10-03 21:31 ` Matt Mackall [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071003213112.GV19691@waste.org \
--to=mpm@selenic.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.