On Thu, 28 Jul 2011, a...@linux-foundation.org wrote:
> From: Hugh Dickins <hu...@google.com>
>
> My load tests on PowerPC freeze within minutes in __slab_free(). I
> happened to try PPC first, didn't try without this fix on x86.
>
> It looks as if the author was interrupted while devising the new
> cmpxchg_double_slab() version of __slab_free(): its decision to
> spin_lock_irqsave() depends on several uninitialized fields, and fixing
> that (by copying page to new) mostly fixes it.
>
> But I didn't think about it very much, and this may well not be what the
> author intends; and I have seen a couple of much rarer freezes in
> __slab_free() on PPC (not yet on x86) even after applying this.
>
> Signed-off-by: Hugh Dickins <hu...@google.com>
> Cc: Pekka Enberg <penb...@cs.helsinki.fi>
> Cc: Christoph Lameter <c...@linux.com>
> Cc: <sta...@kernel.org>
> Signed-off-by: Andrew Morton <a...@linux-foundation.org>
Sorry, no, I don't think this patch should be going anywhere now.
Certainly not to sta...@kernel.org: it was a patch to linux-next
and mmotm a couple of weeks ago, not to anything upstream.
Christoph refined his linux-next struct page unions, and added
some irq disabling in slub slow path, to fix the problem without
this hack of mine.
But I believe this is all in a branch of Pekka's tree which he
intends to invite Linus to pull, but may or may not make it
into 3.1 (it enlarges x86_64 struct page from 56 to 64 bytes).
Hugh
> ---
>
> mm/slub.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff -puN mm/slub.c~slub-partly-fix-freeze-in-__slab_free mm/slub.c
> --- a/mm/slub.c~slub-partly-fix-freeze-in-__slab_free
> +++ a/mm/slub.c
> @@ -2326,6 +2326,7 @@ static void __slab_free(struct kmem_cach
> return;
>
> do {
> + new = *page;
> prior = page->freelist;
> counters = page->counters;
> set_freepointer(s, object, prior);
> _
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
