Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Christoph Lameter]

On Tue, 30 Jun 2009, David Rientjes wrote:

> I don't see how that's different from enabling debugging on all caches
> like CONFIG_SLAB_DEBUG_ON currently does and then warning at the time of
> slab allocation failure that it may be the result of the debugging
> metadata so the user can subsequently prevent it.  In other words, if we
> use MAX_DEBUG_SIZE as Pekka originally implemented as
> (3 * sizeof(void *) + 2 * sizeof(struct track)), do this:

I like it.

> diff --git a/mm/slub.c b/mm/slub.c
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -142,6 +142,11 @@
>  				SLAB_POISON | SLAB_STORE_USER)
>
>  /*
> + * The maximum amount of metadata added to a slab when debugging is enabled.
> + */
> +#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
> +
> +/*
>   * Set of flags that will prevent slab merging
>   */
>  #define SLUB_NEVER_MERGE (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER | \
> @@ -1561,6 +1566,21 @@ slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid)
>  		"default order: %d, min order: %d\n", s->name, s->objsize,
>  		s->size, oo_order(s->oo), oo_order(s->min));
>
> +	if (s->flags & (SLAB_POISON | SLAB_RED_ZONE | SLAB_STORE_USER)) {
> +		int min_order;
> +
> +		/*
> +		 * Debugging is enabled, which may increase oo_order(s->min), so
> +		 * warn the user that allocation failures may be avoided if
> +		 * debugging is enabled for this cache.
> +		 */
> +		min_order = get_order(s->size - MAX_DEBUG_SIZE);
> +		if (min_order < oo_order(s->min))
> +			printk(KERN_WARNING "  %s debugging increased min order "
> +			       "from %d to %d, use slab_debug=-,%s to disable.",
> +			       s->name, min_order, oo_order(s->min), s->name);

It may be easier to check the order of the initial size vs. the order of
the size with all metadata

if (get_order(s->size) > get_order(s->objsize)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/