Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755501AbZICOLe (ORCPT ); Thu, 3 Sep 2009 10:11:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755319AbZICOLe (ORCPT ); Thu, 3 Sep 2009 10:11:34 -0400 Received: from gw1.cosmosbay.com ([212.99.114.194]:35976 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755156AbZICOLd (ORCPT ); Thu, 3 Sep 2009 10:11:33 -0400 Message-ID: <4A9FCDC6.3060003@gmail.com> Date: Thu, 03 Sep 2009 16:08:06 +0200 From: Eric Dumazet User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christoph Lameter CC: Pekka Enberg , Zdenek Kabelac , Patrick McHardy , Robin Holt , Linux Kernel Mailing List , Jesper Dangaard Brouer , Linux Netdev List , Netfilter Developers , paulmck@linux.vnet.ibm.com Subject: [PATCH] slub: fix slab_pad_check() References: <4A87CE60.4020506@gmail.com> <4A896324.3040104@trash.net> <4A9EEF07.5070800@gmail.com> <4A9F1620.2080105@gmail.com> <84144f020909022331x2b275aa5n428f88670e0ae8bc@mail.gmail.com> <4A9F7283.1090306@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [0.0.0.0]); Thu, 03 Sep 2009 16:08:06 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1722 Lines: 56 Christoph Lameter a ?crit : > On Thu, 3 Sep 2009, Eric Dumazet wrote: > >> on a SLAB_DESTROY_BY_RCU cache, there is no need to try to optimize this >> rcu_barrier() call, unless we want superfast reboot/halt sequences... > > I stilll think that the action to quiesce rcu is something that the caller > of kmem_cache_destroy must take care of. Do you mean : if (kmem_cache_shrink(s) == 0) { rcu_barrier(); kmem_cache_destroy_no_rcu_barrier(s); } else { kmem_cache_destroy_with_rcu_barrier_because_SLAB_DESTROY_BY_RCU_cache(s); } What would be the point ? > > Could you split this into two patches: One that addresses the poison and > another that deals with rcu? > Sure, here is the poison thing [PATCH] slub: fix slab_pad_check() 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. Reported-by: Zdenek Kabelac Signed-off-by: Eric Dumazet --- 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); return 0; } -- 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/