Re: "scheduling while atomic" ?

From: Steven Rostedt
Date: Tue Jul 12 2005 - 09:13:10 EST


On Tue, 2005-07-12 at 16:08 +0200, Mateusz Berezecki wrote:

> Sorry for not being too precise. Yes, your assumptions were correct ;-)
> I grab a lock using
>
> spin_lock(&ieee->lock);
>
> and release it using
>
> spin_unlock(&ieee->lock);
>
> there is quite a lot of debugging printk's inbetween. Can this be a cause ?
>

No.

You previous showed the following output:

scheduling while atomic: insmod/0x00000001/12692
[<c03e7352>] schedule+0x632/0x640
[<c0119bb1>] __wake_up_common+0x41/0x70
[<c03e74df>] wait_for_completion+0x8f/0xf0
[<c0119b50>] default_wake_function+0x0/0x20
[<c0119b50>] default_wake_function+0x0/0x20
[<c012e2dd>] queue_work+0x8d/0xa0
[<c012e070>] __call_usermodehelper+0x0/0x70
[<c012e1a5>] call_usermodehelper_keys+0xc5/0xd0
[<c012e070>] __call_usermodehelper+0x0/0x70
[<c020c028>] sprintf+0x28/0x30
[<c020955d>] kobject_hotplug+0x29d/0x310
[<c019fc6e>] sysfs_create_link+0x3e/0x60
[<c028b601>] class_device_add+0x161/0x1e0
[<c036f38e>] netdev_register_sysfs+0x3e/0x100
[<c03650db>] netdev_run_todo+0x1eb/0x220
[<c0364dce>] register_netdev+0x5e/0x90

I assume that you call register_netdev in your module. Since this was
running insmod, this is probably called from the module_init. So what
reason do you have a lock from beginning to end? Looking at this, you
can't call register_netdev while holding a spin_lock since it looks like
it will schedule. So the fix is to release whatever spin lock that you
have before calling register_netdev.

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/