Messages in this thread | | | Date | Thu, 24 Oct 2002 18:52:29 +0200 (MEST) | From | Armin Schindler <> | Subject | Re: module_init in interrupt context ? |
| |
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/
| |