On Wed, 23 Oct 2002, Kai Germaschewski wrote:
> On Wed, 23 Oct 2002, Armin Schindler wrote:
>
> > With kernel 2.4.19 I noticed that calls from module_init()
> > may be done in interrupt context. I didn't have a problem here
> > before 2.4.17.
>
> Well, I am positive that this is not so.
>
> > E.g. in module_init() I use pci_module_init() for my driver
> > (I don't have HOTPLUG enabled), the when the .probe function is called
> > and the card is detected I create a proc entry for this new
> > found device, but most of the time create_proc_entry causes
> > BUG(), because it is called from interrupt context.
>
> I think you should provide the backtrace and the code in questions.
> Obviously, something is wrong, but it's virtually impossible that
> module_init() runs from irq context, so it has to be something else.
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 ?
Armin
-
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/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:23 EST