From: Andrew Morton <akpm@osdl.org>
To: Hugh Dickins <hugh@veritas.com>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: poison struct page for ptlock
Date: Sun, 6 Nov 2005 15:13:26 -0800 [thread overview]
Message-ID: <20051106151326.63cf16bd.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.61.0511062245240.29625@goblin.wat.veritas.com>
Hugh Dickins <hugh@veritas.com> wrote:
>
> On Sun, 6 Nov 2005, Andrew Morton wrote:
> >
> > This patch makes the ppc64 crash. See
> > http://www.zip.com.au/~akpm/linux/patches/stuff/dsc02976.jpg
> >
> > I don't know what the access address was (ia32 nicely tells you), but if
> > it's `DAR' then we have LIST_POISON1. Which would indicate that the slab
> > page which backs the mm_struct itself is getting freed-up-pte-page
> > treatment, which is deeply screwed up.
> >
> > I'll try it on x86_64 and ia64, see if it's specific to ppc64.
>
> I think it'll turn out to be (my patch, yes, but) the way mm/slab.c does
>
> #define SET_PAGE_CACHE(pg,x) ((pg)->lru.next = (struct list_head *)(x))
> #define GET_PAGE_CACHE(pg) ((kmem_cache_t *)(pg)->lru.next)
> #define SET_PAGE_SLAB(pg,x) ((pg)->lru.prev = (struct list_head *)(x))
> #define GET_PAGE_SLAB(pg) ((struct slab *)(pg)->lru.prev)
>
> and needs those fields preserved while that page is in the slab.
> Though I've not tried to work out why it crashes on an mm_struct.
>
> I'd checked that none of the architectures were using those page fields
> of a page table page, but never considered that slab was using them: my
> patch probably breaks all those which use slab for their page tables.
Ah, of course, yes. pagetable pages which come from slab have a live
page.lru even while the memory is in use by the caller.
> Drat. I'm trying to think of the best way to retrieve the situation.
I suspect a slab-based fix/workaround would be unpleasant. Simpler to not
use slab for pagetable pages.
I doubt if there's much benefit to pagetable-pages-in-slab, really. It
_used_ to make sense because slab has the per-cpu LIFO magazines. But now
the page allocator has them too, it's probably better to rely upon that
magazine to provide cache-warm pages.
> The priority must be for you to get 2.6.14-mm1 out: is the easiest for
> now simply to revert my patch (and the _private one(s) you added on top)?
yup, when I can get the steaming pile to compile.
next prev parent reply other threads:[~2005-11-06 23:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-03 19:26 Hugh Dickins
2005-11-05 5:32 ` Andrew Morton
2005-11-05 6:40 ` Hugh Dickins
2005-11-05 7:17 ` Andrew Morton
2005-11-06 19:28 ` Andrew Morton
2005-11-06 17:59 ` Anton Blanchard
2005-11-06 19:34 ` Olof Johansson
2005-11-06 22:39 ` Paul Mackerras
2005-11-06 22:57 ` Andrew Morton
2005-11-06 22:58 ` Hugh Dickins
2005-11-06 23:13 ` Andrew Morton [this message]
2005-11-06 23:36 ` David S. Miller
2005-11-06 23:48 ` Hugh Dickins
2005-11-07 0:00 ` Andrew Morton
2005-11-07 0:15 ` Hugh Dickins
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=20051106151326.63cf16bd.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®