[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84144f020909022331x2b275aa5n428f88670e0ae8bc@mail.gmail.com>
Date: Thu, 3 Sep 2009 09:31:01 +0300
From: Pekka Enberg <penberg@...helsinki.fi>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Zdenek Kabelac <zdenek.kabelac@...il.com>,
Patrick McHardy <kaber@...sh.net>,
Christoph Lameter <cl@...ux-foundation.org>,
Robin Holt <holt@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jesper Dangaard Brouer <hawk@...x.dk>,
Linux Netdev List <netdev@...r.kernel.org>,
Netfilter Developers <netfilter-devel@...r.kernel.org>,
paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
On Thu, Sep 3, 2009 at 4:04 AM, Eric Dumazet<eric.dumazet@...il.com> wrote:
> Zdenek Kabelac a écrit :
>>
>> Well I'm not noticing any ill behavior - also note - rcu_barrier() is
>> there before the cache is destroyed.
>> But as I said - it's just my shot into the dark - which seems to work for me...
>>
>
> Reading again your traces, I do believe there are two bugs in slub
>
> Maybe not explaining your problem, but worth to fix !
>
> Thank you
>
> [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
>
> When SLAB_POISON is used and slab_pad_check() finds an overwrite of the
> slab padding, we call restore_bytes() on the whole slab, not only
> on the padding.
>
> kmem_cache_destroy() should call rcu_barrier() *after* kmem_cache_close()
> and *before* sysfs_slab_remove() or risk rcu_free_slab()
> being called after kmem_cache is deleted (kfreed).
>
> rmmod nf_conntrack can crash the machine because it has to
> kmem_cache_destroy() a SLAB_DESTROY_BY_RCU enabled cache.
>
> Reported-by: Zdenek Kabelac <zdenek.kabelac@...il.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
> ---
> diff --git a/mm/slub.c b/mm/slub.c
> index b9f1491..0ac839f 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -646,7 +646,7 @@ static int slab_pad_check(struct kmem_cache *s, struct page *page)
> slab_err(s, page, "Padding overwritten. 0x%p-0x%p", fault, end - 1);
> print_section("Padding", end - remainder, remainder);
>
> - restore_bytes(s, "slab padding", POISON_INUSE, start, end);
> + restore_bytes(s, "slab padding", POISON_INUSE, end - remainder, end);
OK, makes sense.
> return 0;
> }
>
> @@ -2594,8 +2594,6 @@ static inline int kmem_cache_close(struct kmem_cache *s)
> */
> void kmem_cache_destroy(struct kmem_cache *s)
> {
> - if (s->flags & SLAB_DESTROY_BY_RCU)
> - rcu_barrier();
> down_write(&slub_lock);
> s->refcount--;
> if (!s->refcount) {
> @@ -2606,6 +2604,8 @@ void kmem_cache_destroy(struct kmem_cache *s)
> "still has objects.\n", s->name, __func__);
> dump_stack();
> }
> + if (s->flags & SLAB_DESTROY_BY_RCU)
> + rcu_barrier();
> sysfs_slab_remove(s);
> } else
> up_write(&slub_lock);
The rcu_barrier() call was added by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7ed9f7e5db58c6e8c2b4b738a75d5dcd8e17aad5
I guess we should CC Paul as well.
--
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