d80211: ieee80211_hw handlers in atomic context
Subsystems (2)
Hello Jiri,
Ivo suggested to bring this issue to a broader audience, specifically to the stack maintainer.
Trying to run my Asus WL167G with rt2500usb I faced the following:
BUG: scheduling while atomic: swapper/0x00000102/0 <c0103055> show_trace+0x12/0x14 <c01035e0> dump_stack+0x1c/0x1e <c025fad1> schedule+0x5f/0x652 <c0260324> wait_for_completion+0xb8/0x134 <d0988fa1> usb_start_wait_urb+0x89/0xcb [usbcore] <d0989192> usb_control_msg+0xb2/0xcc [usbcore] <d089d127> rt2x00_vendor_request+0x85/0xbb [rt2500usb] <d08a1350> rt2500usb_config+0x5e/0x3d7 [rt2500usb] <d0823496> ieee80211_hw_config+0x2c/0x93 [80211] <d0829950> ieee80211_ioctl_siwfreq+0x132/0x141 [80211] <d082ee8b> ieee80211_sta_join_ibss+0xcc/0x5af [80211] <d082f698> ieee80211_sta_find_ibss+0x32a/0x374 [80211] <d08317f8> ieee80211_sta_timer+0x81/0x1b4 [80211] <c011ac50> run_timer_softirq+0x171/0x205 <c0117536> __do_softirq+0x41/0x90 <c01175bc> do_softirq+0x37/0x4a <c01176b7> irq_exit+0x2d/0x45 <c0104316> do_IRQ+0x53/0x5f
The reason is the invocation of rt2500usb's config handler in atomic context (timer handler). But this service requires schedulable context to submit and wait for some URBs.
That raises the question how to resolve the conflict best, at stack level by pushing such work into thread context (workqueues?) or at driver level by deferring these requests (if feasible at all without breaking the stack's timing)? What other callback handlers in ieee80211_hw can currently be called in atomic context? Given that all USB WLAN adapters will have to cope with this issue in some way, it may be wise to find a common solution.
Ivo told me about a patch for d80211 that moved certain timers to thread context, effectively avoiding to call config from timer handlers, but I didn't find any trace yet. Is there some modification in this direction already scheduled? I'm not necessarily looking for work, at best I would just enjoy to use it. ;)
Jan
Hi,
Quoted 5 lines
Ivo told me about a patch for d80211 that moved certain timers to thread context, effectively avoiding to call config from timer handlers, but I didn't find any trace yet. Is there some modification in this direction already scheduled? I'm not necessarily looking for work, at best I would just enjoy to use it. ;)
I have found the actual patch:
[PATCH 1/5] d80211: make sleeping in hw->config possible And was send on august 1st by Jiri to the netdev list. It was based on a patch by Michael Buesch.
Ivo
Quoted 8 lines · Ivo van Doorn
Hi,
Quoted 5 lines
Ivo told me about a patch for d80211 that moved certain timers to thread context, effectively avoiding to call config from timer handlers, but I didn't find any trace yet. Is there some modification in this direction already scheduled? I'm not necessarily looking for work, at best I would just enjoy to use it. ;)
Quoted 4 lines
I have found the actual patch:
[PATCH 1/5] d80211: make sleeping inhw->configpossible And was send on august 1st by Jiri to the netdev list. It was based on a patch by Michael Buesch.
Ah, looks like I didn't dug thoroughly enough.
Anyway, this means my BUG proved the patch's claim wrong :o), at least one atomic gremlin is left:
ieee80211_sta_timer ->ieee80211_sta_find_ibss ->ieee80211_sta_join_ibss ->ieee80211_ioctl_siwfreq ->ieee80211_hw_config
Anyone already an idea how to fix it?
Jan
Quoted 19 lines · Jan Kiszka
Quoted 8 lines · Ivo van Doorn
Hi,
Quoted 5 lines
Ivo told me about a patch for d80211 that moved certain timers to thread context, effectively avoiding to call config from timer handlers, but I didn't find any trace yet. Is there some modification in this direction already scheduled? I'm not necessarily looking for work, at best I would just enjoy to use it. ;)
Quoted 4 lines
I have found the actual patch:
[PATCH 1/5] d80211: make sleeping inhw->configpossible And was send on august 1st by Jiri to the netdev list. It was based on a patch by Michael Buesch.Ah, looks like I didn't dug thoroughly enough.
Anyway, this means my BUG proved the patch's claim wrong :o), at least one atomic gremlin is left:
Quoted 7 lines
ieee80211_sta_timer->ieee80211_sta_find_ibss->ieee80211_sta_join_ibss->ieee80211_ioctl_siwfreq->ieee80211_hw_configAnyone already an idea how to fix it?
You could replace the timer with a workqueue, the original patch also did that, so I think it would be good enough this time as well. :)
Ivo
Quoted 2 lines · Ivo van Doorn
You could replace the timer with a workqueue, the original patch also did that, so I think it would be good enough this time as well. :)
Yes, the timing isn't required to be precise here.
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Quoted 5 lines · Jiri Benc
Quoted 2 lines · Ivo van Doorn
You could replace the timer with a workqueue, the original patch also did that, so I think it would be good enough this time as well. :)
Yes, the timing isn't required to be precise here.
Ok, I'm not promising success and I'm going to duck immediately if someone else feels like working on it, but I could try to patch in this direction.
Now there just remains my precautious question if there are other services in the ieee_80211_hw interface that may conflict with sleeping USB drivers. What about specifying the possible contexts in include/net/d80211.h?
Jan
Hi,
Quoted 9 lines
Quoted 5 lines · Ivo van Doorn
Quoted 2 lines
You could replace the timer with a workqueue, the original patch also did that, so I think it would be good enough this time as well. :)
Yes, the timing isn't required to be precise here.
Ok, I'm not promising success and I'm going to duck immediately if someone else feels like working on it, but I could try to patch in this direction.
If you need testing of the patch for a slightly larger audience,
you can send it to me and I'll place it in the rt2x00 CVS tree which contains a copy of the current dscape stack for backwards compatibility with older kernels.
Quoted 4 lines
Now there just remains my precautious question if there are other services in the
ieee_80211_hwinterface that may conflict with sleeping USB drivers. What about specifying the possible contexts ininclude/net/d80211.h?
Well another point of concern for me is the TSF handling, those handlers are called from interrupt context as well, and also deliver problems for the USB drivers in case of adhoc mode.
Ivo
Quoted 3 lines · Ivo van Doorn
Well another point of concern for me is the TSF handling, those handlers are called from interrupt context as well, and also deliver problems for the USB drivers in case of adhoc mode.
Where is a problem with tsf handlers? get_tsf is not called at all (unless CONFIG_D80211_IBSS_DEBUG is set; well, that raises a question why the function exists in the first place), reset_tsf returns void.
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Quoted 8 lines · Jiri Benc
Quoted 3 lines · Ivo van Doorn
Well another point of concern for me is the TSF handling, those handlers are called from interrupt context as well, and also deliver problems for the USB drivers in case of adhoc mode.
Where is a problem with tsf handlers?
get_tsfis not called at all (unlessCONFIG_D80211_IBSS_DEBUGis set; well, that raises a question why the function exists in the first place),reset_tsfreturns void.
Basically it comes down to this:
Sep 13 12:27:34 wz4a kernel: wlan0: Creating new IBSS network, BSSID 7a:b9:60:8a:84:39 Sep 13 12:27:34 wz4a kernel: BUG: scheduling while atomic: swapper/0x00000100/0 Sep 13 12:27:34 wz4a kernel: <b02701e7> schedule+0x43/0xa84 <b01ef8b8> extract_buf+0x97/0xc8 Sep 13 12:27:34 wz4a kernel: <b0270ca8> wait_for_completion+0x6a/0x9f <b0116f2d> default_wake_function+0x0/0xc Sep 13 12:27:34 wz4a kernel: <c08ac59f> usb_start_wait_urb+0x98/0xdc [usbcore] <c08ac418> timeout_kill+0x0/0x5 [usbcore] Sep 13 12:27:34 wz4a kernel: <c08ac7d5> usb_control_msg+0xc3/0xde [usbcore] <c0b6c0f1> rt2x00_vendor_request+0x7c/0xa6 [rt73usb] Sep 13 12:27:34 wz4a kernel: <c0b6fa68> rt73usb_reset_tsf+0x30/0x59 [rt73usb] <c0bdb3e8> ieee80211_sta_join_ibss+0x3a/0x572 [80211] Sep 13 12:27:34 wz4a kernel: <b011cea9> printk+0x14/0x18 <c0bdaa4a> ieee80211_rx_bss_add+0x88/0x90 [80211] Sep 13 12:27:34 wz4a kernel: <c0bdbc2e> ieee80211_sta_find_ibss+0x30e/0x366 [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211] Sep 13 12:27:34 wz4a kernel: <c0bdda91> ieee80211_sta_timer+0x7a/0x18f [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211] Sep 13 12:27:34 wz4a kernel: <b01241b1> run_timer_softirq+0x10b/0x153 <b0120a52> __do_softirq+0x58/0xc2 Sep 13 12:27:34 wz4a kernel: <b0120aea> do_softirq+0x2e/0x32 <b0104fe6> do_IRQ+0x1e/0x24 Sep 13 12:27:34 wz4a kernel: <b0103592> common_interrupt+0x1a/0x20 <c0827484> acpi_processor_idle+0x18a/0x39e [processor] Sep 13 12:27:34 wz4a kernel: <b0101e77> cpu_idle+0x8f/0xa8 <b03026d2> start_kernel+0x355/0x35c
With the compilation of d80211 the CONFIG_D80211_DEBUG is set by default, so no CONFIG_D80211_IBSS_DEBUG.
This does not happen in rt2500usb driver, since no TSF handling is possible due to a lack of TSF registers in the device.
Ivo
Quoted 26 lines · Ivo van Doorn
Quoted 7 lines · Jiri Benc
Quoted 3 lines · Ivo van Doorn
Well another point of concern for me is the TSF handling, those handlers are called from interrupt context as well, and also deliver problems for the USB drivers in case of adhoc mode.
Where is a problem with tsf handlers?
get_tsfis not called at all (unlessCONFIG_D80211_IBSS_DEBUGis set; well, that raises a question why the function exists in the first place),reset_tsfreturns void.Basically it comes down to this:
Sep 13 12:27:34 wz4a kernel: wlan0: Creating new IBSS network, BSSID 7a:b9:60:8a:84:39 Sep 13 12:27:34 wz4a kernel: BUG: scheduling while atomic: swapper/0x00000100/0 Sep 13 12:27:34 wz4a kernel: <b02701e7> schedule+0x43/0xa84 <b01ef8b8> extract_buf+0x97/0xc8 Sep 13 12:27:34 wz4a kernel: <b0270ca8> wait_for_completion+0x6a/0x9f <b0116f2d> default_wake_function+0x0/0xc Sep 13 12:27:34 wz4a kernel: <c08ac59f> usb_start_wait_urb+0x98/0xdc [usbcore] <c08ac418> timeout_kill+0x0/0x5 [usbcore] Sep 13 12:27:34 wz4a kernel: <c08ac7d5> usb_control_msg+0xc3/0xde [usbcore] <c0b6c0f1> rt2x00_vendor_request+0x7c/0xa6 [rt73usb] Sep 13 12:27:34 wz4a kernel: <c0b6fa68> rt73usb_reset_tsf+0x30/0x59 [rt73usb] <c0bdb3e8> ieee80211_sta_join_ibss+0x3a/0x572 [80211] Sep 13 12:27:34 wz4a kernel: <b011cea9> printk+0x14/0x18 <c0bdaa4a> ieee80211_rx_bss_add+0x88/0x90 [80211] Sep 13 12:27:34 wz4a kernel: <c0bdbc2e> ieee80211_sta_find_ibss+0x30e/0x366 [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211] Sep 13 12:27:34 wz4a kernel: <c0bdda91> ieee80211_sta_timer+0x7a/0x18f [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211] Sep 13 12:27:34 wz4a kernel: <b01241b1> run_timer_softirq+0x10b/0x153 <b0120a52> __do_softirq+0x58/0xc2 Sep 13 12:27:34 wz4a kernel: <b0120aea> do_softirq+0x2e/0x32 <b0104fe6> do_IRQ+0x1e/0x24 Sep 13 12:27:34 wz4a kernel: <b0103592> common_interrupt+0x1a/0x20 <c0827484> acpi_processor_idle+0x18a/0x39e [processor] Sep 13 12:27:34 wz4a kernel: <b0101e77> cpu_idle+0x8f/0xa8 <b03026d2> start_kernel+0x355/0x35c
Quoted 5 lines
With the compilation of d80211 the
CONFIG_D80211_DEBUGis set by default, so noCONFIG_D80211_IBSS_DEBUG.This does not happen in rt2500usb driver, since no TSF handling is possible due to a lack of TSF registers in the device.
This path would be fixed by my conversion patch of sta.timer into sta.work that I sent you yesterday privately. Unfortunately, I don't have a copy at hand ATM.
What about the other timers? Can they trigger any sleeping service of rt2x00 drivers? Ok, waiting for a BUG is always possible... ;)
Jan
Hi,
Quoted 6 lines
Quoted 2 lines
This does not happen in rt2500usb driver, since no TSF handling is possible due to a lack of TSF registers in the device.
This path would be fixed by my conversion patch of sta.timer into sta.work that I sent you yesterday privately. Unfortunately, I don't have a copy at hand ATM.
That is what I expect as well, I'll ask confirmation from the person who submitted this bug.
Quoted 2 lines
What about the other timers? Can they trigger any sleeping service of rt2x00 drivers? Ok, waiting for a BUG is always possible... ;)
Well I currently have no time to check it, but canconfig_interface handler still be called from interrupt context or has this also been fixed?
Ivo
Quoted 2 lines · Ivo van Doorn
Well I currently have no time to check it, but can
config_interfacehandler still be called from interrupt context or has this also been fixed?
Will be fixed by the sta_timer conversion as well.
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Quoted 5 lines · Jiri Benc
Quoted 2 lines · Ivo van Doorn
Well I currently have no time to check it, but can
config_interfacehandler still be called from interrupt context or has this also been fixed?Will be fixed by the
sta_timerconversion as well.
Excellent news. :D
Thanks.
Ivo
Quoted 16 lines · Ivo van Doorn
Basically it comes down to this:
Sep 13 12:27:34 wz4a kernel: wlan0: Creating new IBSS network, BSSID 7a:b9:60:8a:84:39 Sep 13 12:27:34 wz4a kernel: BUG: scheduling while atomic: swapper/0x00000100/0 Sep 13 12:27:34 wz4a kernel: <b02701e7> schedule+0x43/0xa84 <b01ef8b8> extract_buf+0x97/0xc8 Sep 13 12:27:34 wz4a kernel: <b0270ca8> wait_for_completion+0x6a/0x9f <b0116f2d> default_wake_function+0x0/0xc Sep 13 12:27:34 wz4a kernel: <c08ac59f> usb_start_wait_urb+0x98/0xdc [usbcore] <c08ac418> timeout_kill+0x0/0x5 [usbcore] Sep 13 12:27:34 wz4a kernel: <c08ac7d5> usb_control_msg+0xc3/0xde [usbcore] <c0b6c0f1> rt2x00_vendor_request+0x7c/0xa6 [rt73usb] Sep 13 12:27:34 wz4a kernel: <c0b6fa68> rt73usb_reset_tsf+0x30/0x59 [rt73usb] <c0bdb3e8> ieee80211_sta_join_ibss+0x3a/0x572 [80211] Sep 13 12:27:34 wz4a kernel: <b011cea9> printk+0x14/0x18 <c0bdaa4a> ieee80211_rx_bss_add+0x88/0x90 [80211] Sep 13 12:27:34 wz4a kernel: <c0bdbc2e> ieee80211_sta_find_ibss+0x30e/0x366 [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211] Sep 13 12:27:34 wz4a kernel: <c0bdda91> ieee80211_sta_timer+0x7a/0x18f [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211] Sep 13 12:27:34 wz4a kernel: <b01241b1> run_timer_softirq+0x10b/0x153 <b0120a52> __do_softirq+0x58/0xc2 Sep 13 12:27:34 wz4a kernel: <b0120aea> do_softirq+0x2e/0x32 <b0104fe6> do_IRQ+0x1e/0x24 Sep 13 12:27:34 wz4a kernel: <b0103592> common_interrupt+0x1a/0x20 <c0827484> acpi_processor_idle+0x18a/0x39e [processor] Sep 13 12:27:34 wz4a kernel: <b0101e77> cpu_idle+0x8f/0xa8 <b03026d2> start_kernel+0x355/0x35c
So this will be solved for free when sta_timer is converted to a workqueue.
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Quoted 18 lines · Jiri Benc
Quoted 16 lines · Ivo van Doorn
Basically it comes down to this:
Sep 13 12:27:34 wz4a kernel: wlan0: Creating new IBSS network, BSSID 7a:b9:60:8a:84:39 Sep 13 12:27:34 wz4a kernel: BUG: scheduling while atomic: swapper/0x00000100/0 Sep 13 12:27:34 wz4a kernel: <b02701e7> schedule+0x43/0xa84 <b01ef8b8> extract_buf+0x97/0xc8 Sep 13 12:27:34 wz4a kernel: <b0270ca8> wait_for_completion+0x6a/0x9f <b0116f2d> default_wake_function+0x0/0xc Sep 13 12:27:34 wz4a kernel: <c08ac59f> usb_start_wait_urb+0x98/0xdc [usbcore] <c08ac418> timeout_kill+0x0/0x5 [usbcore] Sep 13 12:27:34 wz4a kernel: <c08ac7d5> usb_control_msg+0xc3/0xde [usbcore] <c0b6c0f1> rt2x00_vendor_request+0x7c/0xa6 [rt73usb] Sep 13 12:27:34 wz4a kernel: <c0b6fa68> rt73usb_reset_tsf+0x30/0x59 [rt73usb] <c0bdb3e8> ieee80211_sta_join_ibss+0x3a/0x572 [80211] Sep 13 12:27:34 wz4a kernel: <b011cea9> printk+0x14/0x18 <c0bdaa4a> ieee80211_rx_bss_add+0x88/0x90 [80211] Sep 13 12:27:34 wz4a kernel: <c0bdbc2e> ieee80211_sta_find_ibss+0x30e/0x366 [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211] Sep 13 12:27:34 wz4a kernel: <c0bdda91> ieee80211_sta_timer+0x7a/0x18f [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211] Sep 13 12:27:34 wz4a kernel: <b01241b1> run_timer_softirq+0x10b/0x153 <b0120a52> __do_softirq+0x58/0xc2 Sep 13 12:27:34 wz4a kernel: <b0120aea> do_softirq+0x2e/0x32 <b0104fe6> do_IRQ+0x1e/0x24 Sep 13 12:27:34 wz4a kernel: <b0103592> common_interrupt+0x1a/0x20 <c0827484> acpi_processor_idle+0x18a/0x39e [processor] Sep 13 12:27:34 wz4a kernel: <b0101e77> cpu_idle+0x8f/0xa8 <b03026d2> start_kernel+0x355/0x35c
Quoted 2 lines
So this will be solved for free when
sta_timeris converted to a workqueue.
Hi,
True, this is what I realized later as well. :) I have asked for confirmation by the bug submitter.
Ivo
Quoted 3 lines · Jan Kiszka
Ok, I'm not promising success and I'm going to duck immediately if someone else feels like working on it, but I could try to patch in this direction.
Your patches are welcomed!
Quoted 4 lines
Now there just remains my precautious question if there are other services in the
ieee_80211_hwinterface that may conflict with sleeping USB drivers. What about specifying the possible contexts ininclude/net/d80211.h?
Yes, that makes sense. Feel free to send a patch :-)
Thanks,
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Quoted 5 lines · Jiri Benc
Quoted 3 lines · Jan Kiszka
Ok, I'm not promising success and I'm going to duck immediately if someone else feels like working on it, but I could try to patch in this direction.
Quoted 8 lines
Your patches are welcomed!
Quoted 4 lines
Now there just remains my precautious question if there are other services in the
ieee_80211_hwinterface that may conflict with sleeping USB drivers. What about specifying the possible contexts ininclude/net/d80211.h?Yes, that makes sense. Feel free to send a patch :-)
The patch is currently in testing in the rt2x00 tree. So it will be shortly send to the netdev list. :)
Ivo
Quoted 3 lines · Jan Kiszka
The reason is the invocation of rt2500usb's config handler in atomic context (timer handler). But this service requires schedulable context to submit and wait for some URBs.
Hm, I thought it had been fixed
(http://kernel.org/git/?p=linux/kernel/git/linville/wireless-dev.git;a=commit;h=d0d2b7a8ddc378ddea499f1537f6aea83d96d003).
We'll need to make something similar with sta_timer.
Quoted 7 lines
That raises the question how to resolve the conflict best, at stack level by pushing such work into thread context (workqueues?) or at driver level by deferring these requests (if feasible at all without breaking the stack's timing)? What other callback handlers in
ieee80211_hwcan currently be called in atomic context? Given that all USB WLAN adapters will have to cope with this issue in some way, it may be wise to find a common solution.
It needs to be solved in the stack. ieee80211_hw->config callback should return proper error code in a case of problems and this is not possible when the work is deferred in the driver.
Thanks,
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs