Re: module_init in interrupt context ?

[Kai Germaschewski]

On Thu, 24 Oct 2002, Armin Schindler wrote:

> Yes, you are right, it is something else.
> The problem is, that in_interrupt() is true if local_bh_count()
> is != 0, which basically sounds correct, but if we are in
> spin_lock_bh(), local_bh_count() is also != 0.
> 
> This means, in_interrupt() is always true when called inside
> spin_[un]lock_bh() region.
> 
> So, it is not allowed to call create_proc_entry after
> spin_lock_bh(), because sub-function proc_create()
> calles kmalloc() with GFP_KERNEL and then in_interrupt()
> is tested again, which gives the wrong status and
> causes BUG() in kmem_cache_grow().
> 
> Was this done on purpose ?

You are never allowed to sleep with a spinlock held, no matter if it's 
_bh, _irq or just a plain spin_lock(). Doing so creates the possibility of 
deadlock (assuming your lock actually is necessary and you're not 
serialized already), current 2.5 btw has debugging code which checks for 
this bug.

So this code was buggy in earlier 2.4 as well, you'll have to create your 
proc entry outside the protected region or use a semaphore instead of a 
spinlock.

--Kai