lkml.org 
[lkml]   [2002]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: module_init in interrupt context ?
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


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

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.062 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site