Re: [PATCH] Revert "leds: convert blink timer to workqueue"
On Tue, 2 Sep 2014, Bryan Wu wrote: > On Tue, Sep 2, 2014 at 2:03 AM, Jiri Kosina wrote: > > This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. > > > > It's broken as it changes led_blink_set() in a way that it can now sleep > > (while synchronously waiting for workqueue to be cancelled). That's a > > problem, because it's possible that this function gets called from atomic > > context (tpt_trig_timer() takes a readlock and thus disables preemption). > > > > This has been brought up 3 weeks ago already [1] but no proper fix has > > materialized, and I keep seeing the problem since 3.18-rc1. > > Is this 3.18-rc1? I think it should be 3.17-rc1, right? Indeed, brainfart on my side, thanks for noticing. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert "leds: convert blink timer to workqueue"
On Tue, Sep 2, 2014 at 1:02 PM, Bryan Wu wrote: > On Tue, Sep 2, 2014 at 2:03 AM, Jiri Kosina wrote: >> This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. >> >> It's broken as it changes led_blink_set() in a way that it can now sleep >> (while synchronously waiting for workqueue to be cancelled). That's a >> problem, because it's possible that this function gets called from atomic >> context (tpt_trig_timer() takes a readlock and thus disables preemption). >> >> This has been brought up 3 weeks ago already [1] but no proper fix has >> materialized, and I keep seeing the problem since 3.18-rc1. >> > > Is this 3.18-rc1? I think it should be 3.17-rc1, right? Yes . josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert "leds: convert blink timer to workqueue"
On Tue, Sep 2, 2014 at 2:03 AM, Jiri Kosina wrote:
> This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758.
>
> It's broken as it changes led_blink_set() in a way that it can now sleep
> (while synchronously waiting for workqueue to be cancelled). That's a
> problem, because it's possible that this function gets called from atomic
> context (tpt_trig_timer() takes a readlock and thus disables preemption).
>
> This has been brought up 3 weeks ago already [1] but no proper fix has
> materialized, and I keep seeing the problem since 3.18-rc1.
>
Is this 3.18-rc1? I think it should be 3.17-rc1, right?
-Bryan
> [1] https://lkml.org/lkml/2014/8/16/128
>
> BUG: sleeping function called from invalid context at kernel/workqueue.c:2650
> in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant
> 5 locks held by wpa_supplicant/2335:
> #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20
> #1: (>mtx){+.+.+.}, at: []
> cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211]
> #2: (>mtx){+.+.+.}, at: []
> ieee80211_prep_connection+0x17a/0x9a0 [mac80211]
> #3: (>chanctx_mtx){+.+.+.}, at: []
> ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211]
> #4: (>leddev_list_lock){.+.+..}, at: []
> tpt_trig_timer+0xec/0x170 [mac80211]
> CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1
> Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
> 8800360b5a50 8800751f76d8 8159e97f 8800360b5a30
> 8800751f76e8 810739a5 8800751f77b0 8106862f
> 810685d0 0aa22092 8804 8800361c59d0
> Call Trace:
> [] dump_stack+0x4d/0x66
> [] __might_sleep+0xe5/0x120
> [] flush_work+0x5f/0x270
> [] ? mod_delayed_work_on+0x80/0x80
> [] ? mark_held_locks+0x6a/0x90
> [] ? __cancel_work_timer+0x6f/0x100
> [] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [] __cancel_work_timer+0x7b/0x100
> [] cancel_delayed_work_sync+0xe/0x10
> [] led_blink_set+0x1b/0x40
> [] tpt_trig_timer+0x110/0x170 [mac80211]
> [] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
> [] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
> [] ieee80211_idle_off+0xe/0x10 [mac80211]
> [] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
> [] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
> [] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
> [] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
> [] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
> [] ieee80211_auth+0x13/0x20 [mac80211]
> [] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
> [] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211]
> [] cfg80211_connect+0x3f0/0x540 [cfg80211]
> [] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211]
> [] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211]
> [] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
> [] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211]
> [] ioctl_standard_iw_point+0x14c/0x3e0
> [] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [] ioctl_standard_call+0x8a/0xd0
> [] ? ioctl_standard_iw_point+0x3e0/0x3e0
> [] wireless_process_ioctl.constprop.10+0xb6/0x100
> [] wext_handle_ioctl+0x5d/0xb0
> [] dev_ioctl+0x329/0x620
> [] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [] sock_ioctl+0x142/0x2e0
> [] do_vfs_ioctl+0x300/0x520
> [] ? sysret_check+0x1b/0x56
> [] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [] SyS_ioctl+0x81/0xa0
> [] system_call_fastpath+0x1a/0x1f
> wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3)
> wlan0: authenticated
> wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3)
> wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2)
> wlan0: associated
> IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> cfg80211: Calling CRDA for country: NA
> wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by
> 00:0b:6b:3c:8c:e4
>
> =
> [ INFO: inconsistent lock state ]
> 3.17.0-rc3 #1 Not tainted
> -
> inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
> swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
> ((&(_cdev->blink_work)->work)){+.?...}, at: []
> flush_work+0x0/0x270
> {SOFTIRQ-ON-W} state was registered at:
>[] __lock_acquire+0x30e/0x1a30
>[] lock_acquire+0x91/0x110
>[] flush_work+0x38/0x270
>[] __cancel_work_timer+0x7b/0x100
>[] cancel_delayed_work_sync+0xe/0x10
>[] led_blink_set+0x1b/0x40
>[] tpt_trig_timer+0x110/0x170 [mac80211]
>[] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
>[] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
>[] ieee80211_idle_off+0xe/0x10 [mac80211]
>[] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
>[] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
>[] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
>[] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
>[] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
>[] ieee80211_auth+0x13/0x20 [mac80211]
>[] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
>[] cfg80211_conn_do_work+0x155/0x3b0
Re: [PATCH] Revert "leds: convert blink timer to workqueue"
On Tue, Sep 2, 2014 at 8:55 AM, Josh Boyer wrote: > On Tue, Sep 2, 2014 at 5:03 AM, Jiri Kosina wrote: >> This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. >> >> It's broken as it changes led_blink_set() in a way that it can now sleep >> (while synchronously waiting for workqueue to be cancelled). That's a >> problem, because it's possible that this function gets called from atomic >> context (tpt_trig_timer() takes a readlock and thus disables preemption). >> >> This has been brought up 3 weeks ago already [1] but no proper fix has >> materialized, and I keep seeing the problem since 3.18-rc1. >> >> [1] https://lkml.org/lkml/2014/8/16/128 > > FWIW we're seeing it reported in Fedora too. Perhaps a revert is the > right approach for now. > I'm going to apply this patch and will send it out for Linus soon. Thanks, -Bryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert "leds: convert blink timer to workqueue"
On Tue, Sep 2, 2014 at 5:03 AM, Jiri Kosina wrote: > This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. > > It's broken as it changes led_blink_set() in a way that it can now sleep > (while synchronously waiting for workqueue to be cancelled). That's a > problem, because it's possible that this function gets called from atomic > context (tpt_trig_timer() takes a readlock and thus disables preemption). > > This has been brought up 3 weeks ago already [1] but no proper fix has > materialized, and I keep seeing the problem since 3.18-rc1. > > [1] https://lkml.org/lkml/2014/8/16/128 FWIW we're seeing it reported in Fedora too. Perhaps a revert is the right approach for now. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert leds: convert blink timer to workqueue
On Tue, Sep 2, 2014 at 5:03 AM, Jiri Kosina jkos...@suse.cz wrote: This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. It's broken as it changes led_blink_set() in a way that it can now sleep (while synchronously waiting for workqueue to be cancelled). That's a problem, because it's possible that this function gets called from atomic context (tpt_trig_timer() takes a readlock and thus disables preemption). This has been brought up 3 weeks ago already [1] but no proper fix has materialized, and I keep seeing the problem since 3.18-rc1. [1] https://lkml.org/lkml/2014/8/16/128 FWIW we're seeing it reported in Fedora too. Perhaps a revert is the right approach for now. josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert leds: convert blink timer to workqueue
On Tue, Sep 2, 2014 at 8:55 AM, Josh Boyer jwbo...@fedoraproject.org wrote: On Tue, Sep 2, 2014 at 5:03 AM, Jiri Kosina jkos...@suse.cz wrote: This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. It's broken as it changes led_blink_set() in a way that it can now sleep (while synchronously waiting for workqueue to be cancelled). That's a problem, because it's possible that this function gets called from atomic context (tpt_trig_timer() takes a readlock and thus disables preemption). This has been brought up 3 weeks ago already [1] but no proper fix has materialized, and I keep seeing the problem since 3.18-rc1. [1] https://lkml.org/lkml/2014/8/16/128 FWIW we're seeing it reported in Fedora too. Perhaps a revert is the right approach for now. I'm going to apply this patch and will send it out for Linus soon. Thanks, -Bryan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert leds: convert blink timer to workqueue
On Tue, Sep 2, 2014 at 2:03 AM, Jiri Kosina jkos...@suse.cz wrote:
This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758.
It's broken as it changes led_blink_set() in a way that it can now sleep
(while synchronously waiting for workqueue to be cancelled). That's a
problem, because it's possible that this function gets called from atomic
context (tpt_trig_timer() takes a readlock and thus disables preemption).
This has been brought up 3 weeks ago already [1] but no proper fix has
materialized, and I keep seeing the problem since 3.18-rc1.
Is this 3.18-rc1? I think it should be 3.17-rc1, right?
-Bryan
[1] https://lkml.org/lkml/2014/8/16/128
BUG: sleeping function called from invalid context at kernel/workqueue.c:2650
in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant
5 locks held by wpa_supplicant/2335:
#0: (rtnl_mutex){+.+.+.}, at: [814c7c92] rtnl_lock+0x12/0x20
#1: (wdev-mtx){+.+.+.}, at: [c06e649c]
cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211]
#2: (local-mtx){+.+.+.}, at: [c0817dea]
ieee80211_prep_connection+0x17a/0x9a0 [mac80211]
#3: (local-chanctx_mtx){+.+.+.}, at: [c08081ed]
ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211]
#4: (trig-leddev_list_lock){.+.+..}, at: [c081e68c]
tpt_trig_timer+0xec/0x170 [mac80211]
CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1
Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
8800360b5a50 8800751f76d8 8159e97f 8800360b5a30
8800751f76e8 810739a5 8800751f77b0 8106862f
810685d0 0aa22092 8804 8800361c59d0
Call Trace:
[8159e97f] dump_stack+0x4d/0x66
[810739a5] __might_sleep+0xe5/0x120
[8106862f] flush_work+0x5f/0x270
[810685d0] ? mod_delayed_work_on+0x80/0x80
[810945ca] ? mark_held_locks+0x6a/0x90
[81068a5f] ? __cancel_work_timer+0x6f/0x100
[810946ed] ? trace_hardirqs_on_caller+0xfd/0x1c0
[81068a6b] __cancel_work_timer+0x7b/0x100
[81068b0e] cancel_delayed_work_sync+0xe/0x10
[8147cf3b] led_blink_set+0x1b/0x40
[c081e6b0] tpt_trig_timer+0x110/0x170 [mac80211]
[c081ecdd] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
[c07e4278] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
[c07e59ce] ieee80211_idle_off+0xe/0x10 [mac80211]
[c0804e5b] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
[c08062e4] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
[c080838a] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
[c0817df8] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
[c081c246] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
[c07eab33] ieee80211_auth+0x13/0x20 [mac80211]
[c06cb006] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
[c06ce085] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211]
[c06cf670] cfg80211_connect+0x3f0/0x540 [cfg80211]
[c06e6148] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211]
[c06e651e] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211]
[c06e36c0] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
[c06e36dd] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211]
[81584d0c] ioctl_standard_iw_point+0x14c/0x3e0
[810946ed] ? trace_hardirqs_on_caller+0xfd/0x1c0
[8158502a] ioctl_standard_call+0x8a/0xd0
[81584fa0] ? ioctl_standard_iw_point+0x3e0/0x3e0
[81584b76] wireless_process_ioctl.constprop.10+0xb6/0x100
[8158521d] wext_handle_ioctl+0x5d/0xb0
[814cfb29] dev_ioctl+0x329/0x620
[810946ed] ? trace_hardirqs_on_caller+0xfd/0x1c0
[8149c7f2] sock_ioctl+0x142/0x2e0
[811b0140] do_vfs_ioctl+0x300/0x520
[815a67fb] ? sysret_check+0x1b/0x56
[810946ed] ? trace_hardirqs_on_caller+0xfd/0x1c0
[811b03e1] SyS_ioctl+0x81/0xa0
[815a67d6] system_call_fastpath+0x1a/0x1f
wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3)
wlan0: authenticated
wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3)
wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2)
wlan0: associated
IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
cfg80211: Calling CRDA for country: NA
wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by
00:0b:6b:3c:8c:e4
=
[ INFO: inconsistent lock state ]
3.17.0-rc3 #1 Not tainted
-
inconsistent {SOFTIRQ-ON-W} - {IN-SOFTIRQ-W} usage.
swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(((led_cdev-blink_work)-work)){+.?...}, at: [810685d0]
flush_work+0x0/0x270
{SOFTIRQ-ON-W} state was registered at:
[81094dbe] __lock_acquire+0x30e/0x1a30
[81096c81] lock_acquire+0x91/0x110
[81068608]
Re: [PATCH] Revert leds: convert blink timer to workqueue
On Tue, Sep 2, 2014 at 1:02 PM, Bryan Wu coolo...@gmail.com wrote: On Tue, Sep 2, 2014 at 2:03 AM, Jiri Kosina jkos...@suse.cz wrote: This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. It's broken as it changes led_blink_set() in a way that it can now sleep (while synchronously waiting for workqueue to be cancelled). That's a problem, because it's possible that this function gets called from atomic context (tpt_trig_timer() takes a readlock and thus disables preemption). This has been brought up 3 weeks ago already [1] but no proper fix has materialized, and I keep seeing the problem since 3.18-rc1. Is this 3.18-rc1? I think it should be 3.17-rc1, right? Yes . josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert leds: convert blink timer to workqueue
On Tue, 2 Sep 2014, Bryan Wu wrote: On Tue, Sep 2, 2014 at 2:03 AM, Jiri Kosina jkos...@suse.cz wrote: This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. It's broken as it changes led_blink_set() in a way that it can now sleep (while synchronously waiting for workqueue to be cancelled). That's a problem, because it's possible that this function gets called from atomic context (tpt_trig_timer() takes a readlock and thus disables preemption). This has been brought up 3 weeks ago already [1] but no proper fix has materialized, and I keep seeing the problem since 3.18-rc1. Is this 3.18-rc1? I think it should be 3.17-rc1, right? Indeed, brainfart on my side, thanks for noticing. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
