Re: module_init in interrupt context ?

[Armin Schindler]

On Thu, 24 Oct 2002, Kai Germaschewski wrote:
> 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.

Okay, I wasn't aware of create_proc_entry() must to be called
from user-context and outside any locks.

But anyway, isn't the statement "in_interrupt() != 0" somehow wrong
when just the bh's are disabled ?

Armin