kmalloc without GFP_xxx?

[Denis Vlasenko]

Hi,

As anybody knows here, one needs to be careful with GFP_xxx
flags. I've no doubts it's important to get it right in fs
and elsewhere in critical places or else nasty things will happen.

However, for driver code it seems like questionaire
"do you remember which network callback is atomic?".

It struck me that kernel actually can figure out whether it's okay
to sleep or not by looking at combination of (flags & __GFP_WAIT)
and ((in_atomic() || irqs_disabled()) as it already does this for
might_sleep() barfing:

kmalloc => __cache_alloc =>

static inline void
cache_alloc_debugcheck_before(kmem_cache_t *cachep, unsigned int __nocast flags)
{
        might_sleep_if(flags & __GFP_WAIT);
#if DEBUG
        kmem_flagcheck(cachep, flags);
#endif
}

	and

void __might_sleep(char *file, int line)
{
#if defined(in_atomic)
        static unsigned long prev_jiffy;        /* ratelimiting */

        if ((in_atomic() || irqs_disabled()) &&
            system_state == SYSTEM_RUNNING && !oops_in_progress) {
                if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)
                        return;
                prev_jiffy = jiffies;
                printk(KERN_ERR "Debug: sleeping function called from invalid"
                                " context at %s:%d\n", file, line);
                printk("in_atomic():%d, irqs_disabled():%d\n",
                        in_atomic(), irqs_disabled());
                dump_stack();
        }
#endif
}

So why can't we have kmalloc_auto(size) which does GFP_KERNEL alloc
if called from non-atomic context and GFP_ATOMIC one otherwise?
--
vda

-
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/