Messages in this thread | | | Date | Tue, 18 Mar 2008 00:30:35 +0100 (CET) | From | Jan Engelhardt <> | Subject | vfree with spin_lock_bh |
| |
Hi,
while transforming some code with big allocations (like 120 KB) from kmalloc to vmalloc — virtual contiguity is sufficient — I hit a BUG_ON in mm/vmalloc.c a number of times:
void vfree(const void *addr) { BUG_ON(in_interrupt()); __vunmap(addr, 1); }
First I was thinking “how could iptables -F run in interrupt context?”, but apparently, it does seem to make a difference:
... spin_lock_bh(&a_local_spinlock); list_del_rcu(&node->list); printk(KERN_INFO "Interrupt? %lu\n", in_interrupt()); /* vfree not worky here */ spin_unlock_bh(&a_local_spinlock); printk(KERN_INFO "Interrupt? %lu\n", in_interrupt()); /* now possible */ vfree(node); ...
and this gives (x86_32)
Interrupt? 256 Interrupt? 0
So this may be a "property" of spinlocks, but it is a bit strange to me. Why should not I be able to call vfree() when I am, in fact, in user context (but with a bh spinlock held...).
Do I perhaps need a non-bh spinlock? There's RCU going on on that linked list so I am not sure whether I could just call the normal spin_lock() function.
Looking at the code of _spin_lock_bh in kernel/spinlock.c reveals that it is actually disabling preempt instead of being in an interrupt. Making an uneducated guess, would
BUG_ON(in_interrupt() != 0 && in_interrupt() != 256)
in vfree() be safe?
thanks, Jan -- 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/
| |