Messages in this thread | | | Date | Sun, 6 Nov 2005 15:13:26 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] mm: poison struct page for ptlock |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |