> Yes, but the patch that I quoted makes it allowable to sleep
> there, so it must be something else. Is it maybe using the
> RTNL there? Or using schedule_work() and then waiting for it
> or something that the work triggers, which will deadlock on
> the RTNL if there's something in front of it on the queue that
> needs the RTNL, because get_wireless_stats is executed under
> RTNL? (lockdep couldn't find that particular case because it
> knows nothing about completions)
Again this is all from my memory, around the 2.6.25
time. "iwconfig" or "cat /proc/net/wireless" ended up in
drivers/net/wireless/libertas/wext.c, AFAIK in
lbs_get_wireless_stats(). This calls
lbs_cmd_with_response(priv, CMD_802_11_GET_LOG, &log);
this is a macro calling lbs_cmd(). This thingy then does
__lbs_cmd_async(), which creates a "command node", queues this,
and calls
wake_up_interruptible(&priv->waitq);
(cmd.c, around line 2050) to get the queue handled (e.g. sending
the command to the firmware). And I think that this wake_up-call
calls __schedule() now.
Later, lbs_cmd() does this:
might_sleep();
wait_event_interruptible(cmdnode->cmdwait_q,
cmdnode->cmdwaitqwoken);
But AFAIK this isn't problematic.
--
http://www.holgerschurig.de
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
