Messages in this thread | | | From | Denis Vlasenko <> | Subject | kmalloc without GFP_xxx? | Date | Wed, 29 Jun 2005 14:02:18 +0300 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |