Prev: x86, mem: Optimize memcpy by avoiding memory false dependece
Next: x86, mem: Optimize memcpy by avoiding memory false dependece
From: David Rientjes on 16 Jul 2010 05:10 On Fri, 16 Jul 2010, Pekka Enberg wrote: > > I'd also consider patch 7 for 2.6.35-rc6 (and -stable). > > It's an obvious bug fix but is it triggered in practice? Is there a bugzilla > report for that? > Let's ask Benjamin who initially reported the problem with arch_initcall whether or not this is rc (and stable) material. For reference, we're talking about the sysfs_slab_remove() check on slab_state to prevent the WARN in the kobject code you hit with its fix below: From: Christoph Lameter <cl(a)linux-foundation.org> slub: Allow removal of slab caches during boot If a slab cache is removed before we have setup sysfs then simply skip over the sysfs handling. Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: Roland Dreier <rdreier(a)cisco.com> Signed-off-by: Christoph Lameter <cl(a)linux-foundation.org> --- mm/slub.c | 7 +++++++ 1 file changed, 7 insertions(+) Index: linux-2.6/mm/slub.c =================================================================== --- linux-2.6.orig/mm/slub.c 2010-07-06 15:13:48.000000000 -0500 +++ linux-2.6/mm/slub.c 2010-07-06 15:15:27.000000000 -0500 @@ -4507,6 +4507,13 @@ static int sysfs_slab_add(struct kmem_ca static void sysfs_slab_remove(struct kmem_cache *s) { + if (slab_state < SYSFS) + /* + * Sysfs has not been setup yet so no need to remove the + * cache from sysfs. + */ + return; + kobject_uevent(&s->kobj, KOBJ_REMOVE); kobject_del(&s->kobj); kobject_put(&s->kobj); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 18 Jul 2010 20:20
On Fri, 2010-07-16 at 02:02 -0700, David Rientjes wrote: > On Fri, 16 Jul 2010, Pekka Enberg wrote: > > > > I'd also consider patch 7 for 2.6.35-rc6 (and -stable). > > > > It's an obvious bug fix but is it triggered in practice? Is there a bugzilla > > report for that? > > > > Let's ask Benjamin who initially reported the problem with arch_initcall > whether or not this is rc (and stable) material. > > For reference, we're talking about the sysfs_slab_remove() check on > slab_state to prevent the WARN in the kobject code you hit with its fix > below: The only case where I reproduce that is an in-house kernel port that we haven't published yet so it doesn't have to be -stable material as far as I'm concerned. Cheers, Ben. > > From: Christoph Lameter <cl(a)linux-foundation.org> > > slub: Allow removal of slab caches during boot > > If a slab cache is removed before we have setup sysfs then simply skip over > the sysfs handling. > > Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> > Cc: Roland Dreier <rdreier(a)cisco.com> > Signed-off-by: Christoph Lameter <cl(a)linux-foundation.org> > > --- > mm/slub.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > Index: linux-2.6/mm/slub.c > =================================================================== > --- linux-2.6.orig/mm/slub.c 2010-07-06 15:13:48.000000000 -0500 > +++ linux-2.6/mm/slub.c 2010-07-06 15:15:27.000000000 -0500 > @@ -4507,6 +4507,13 @@ static int sysfs_slab_add(struct kmem_ca > > static void sysfs_slab_remove(struct kmem_cache *s) > { > + if (slab_state < SYSFS) > + /* > + * Sysfs has not been setup yet so no need to remove the > + * cache from sysfs. > + */ > + return; > + > kobject_uevent(&s->kobj, KOBJ_REMOVE); > kobject_del(&s->kobj); > kobject_put(&s->kobj); > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo(a)kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont(a)kvack.org"> email(a)kvack.org </a> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |