In the drivers/net/wireless/ath5k/base.c, there's recursive locking of sc->lock
This casue the kernel stuck
Bug report please see:
http://lkml.org/lkml/2008/7/29/32
Fixed it by remove the lock in sub routine "ath5k_beacon_update",
The ath5k_config_interface is the only caller to it.
[ 171.430207] =============================================
[ 171.432140] [ INFO: possible recursive locking detected ]
[ 171.433113] 2.6.27-rc1-smp #4
[ 171.434079] ---------------------------------------------
[ 171.435039] ath5k_pci/2447 is trying to acquire lock:
[ 171.435990] (&sc->lock){--..}, at: [<f89ee9b5>] ath5k_config_interface+0xd5/0x340 [ath5k]
[ 171.437046]
[ 171.437048] but task is already holding lock:
[ 171.438903] (&sc->lock){--..}, at: [<f89ee91d>] ath5k_config_interface+0x3d/0x340 [ath5k]
[ 171.439953]
[ 171.439954] other info that might help us debug this:
[ 171.441795] 3 locks held by ath5k_pci/2447:
[ 171.442729] #0: ((name)){--..}, at: [<c013a122>] run_workqueue+0x102/0x1d0
[ 171.443800] #1: (&(&local->scan_work)->work){--..}, at: [<c013a122>] run_workqueue+0x102/0x1d0
[ 171.444859] #2: (&sc->lock){--..}, at: [<f89ee91d>] ath5k_config_interface+0x3d/0x340 [ath5k]
[ 171.445941]
[ 171.445942] stack backtrace:
[ 171.447791] Pid: 2447, comm: ath5k_pci Not tainted 2.6.27-rc1-smp #4
[ 171.448732] [<c014d69f>] __lock_acquire+0xa8f/0x11b0
[ 171.449698] [<c014de41>] lock_acquire+0x81/0xa0
[ 171.450655] [<f89ee9b5>] ? ath5k_config_interface+0xd5/0x340 [ath5k]
[ 171.451651] [<c046073b>] mutex_lock_nested+0x9b/0x280
[ 171.452609] [<f89ee9b5>] ? ath5k_config_interface+0xd5/0x340 [ath5k]
[ 171.453588] [<f89ee9b5>] ? ath5k_config_interface+0xd5/0x340 [ath5k]
[ 171.454555] [<f89ee9b5>] ath5k_config_interface+0xd5/0x340 [ath5k]
[ 171.455485] [<c0184082>] ? check_object+0xe2/0x1e0
[ 171.456428] [<c014c7cb>] ? trace_hardirqs_on+0xb/0x10
[ 171.457377] [<c014c73d>] ? trace_hardirqs_on_caller+0xbd/0x140
[ 171.458334] [<c014c7cb>] ? trace_hardirqs_on+0xb/0x10
[ 171.459304] [<c03eb31c>] ? dev_alloc_skb+0x1c/0x30
[ 171.460276] [<f89a3747>] ieee80211_if_config+0x97/0x160 [mac80211]
[ 171.461237] [<f89a95bc>] ieee80211_sta_join_ibss+0x25c/0x3e0 [mac80211]
[ 171.462196] [<c012f070>] ? local_bh_enable_ip+0x80/0xc0
[ 171.463171] [<f89ab325>] ieee80211_sta_find_ibss+0x365/0x4b0 [mac80211]
[ 171.464134] [<f89ab8ab>] ieee80211_scan_completed+0x2cb/0x320 [mac80211]
[ 171.465097] [<f89ab7de>] ? ieee80211_scan_completed+0x1fe/0x320 [mac80211]
[ 171.466084] [<f89af3b3>] ieee80211_sta_scan_work+0xa3/0x1f0 [mac80211]
[ 171.467054] [<c013a122>] ? run_workqueue+0x102/0x1d0
[ 171.468026] [<c013a175>] run_workqueue+0x155/0x1d0
[ 171.468978] [<c013a122>] ? run_workqueue+0x102/0x1d0
[ 171.469947] [<c014c7cb>] ? trace_hardirqs_on+0xb/0x10
[ 171.470925] [<f89af310>] ? ieee80211_sta_scan_work+0x0/0x1f0 [mac80211]
[ 171.471924] [<c013ac68>] worker_thread+0x88/0xe0
[ 171.472880] [<c013da70>] ? autoremove_wake_function+0x0/0x40
[ 171.473862] [<c013abe0>] ? worker_thread+0x0/0xe0
[ 171.474835] [<c013d782>] kthread+0x42/0x70
[ 171.475789] [<c013d740>] ? kthread+0x0/0x70
[ 171.476765] [<c01048e7>] kernel_thread_helper+0x7/0x10
Signed-off-by: Dave Young <[email protected]>
drivers/net/wireless/ath5k/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.26/drivers/net/wireless/ath5k/base.c
===================================================================
--- linux-2.6.26.orig/drivers/net/wireless/ath5k/base.c 2008-08-01 12:55:16.000000000 +0800
+++ linux-2.6.26/drivers/net/wireless/ath5k/base.c 2008-08-01 14:01:15.000000000 +0800
@@ -3024,6 +3024,9 @@
ath5k_hw_reset_tsf(sc->ah);
}
+/*
+ * caller need lock the hw->sc->lock for us.
+ */
static int
ath5k_beacon_update(struct ieee80211_hw *hw, struct sk_buff *skb)
{
@@ -3032,8 +3035,6 @@
ath5k_debug_dump_skb(sc, skb, "BC ", 1);
- mutex_lock(&sc->lock);
-
if (sc->opmode != IEEE80211_IF_TYPE_IBSS) {
ret = -EIO;
goto end;
@@ -3048,7 +3049,6 @@
ath5k_beacon_config(sc);
end:
- mutex_unlock(&sc->lock);
return ret;
}
Dave Young napsal(a):
> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of sc->lock
> This casue the kernel stuck
>
> Bug report please see:
> http://lkml.org/lkml/2008/7/29/32
>
> Fixed it by remove the lock in sub routine "ath5k_beacon_update",
> The ath5k_config_interface is the only caller to it.
>
> [ 171.430207] =============================================
> [ 171.432140] [ INFO: possible recursive locking detected ]
> [ 171.433113] 2.6.27-rc1-smp #4
> [ 171.434079] ---------------------------------------------
> [ 171.435039] ath5k_pci/2447 is trying to acquire lock:
> [ 171.435990] (&sc->lock){--..}, at: [<f89ee9b5>] ath5k_config_interface+0xd5/0x340 [ath5k]
> [ 171.437046]
> [ 171.437048] but task is already holding lock:
> [ 171.438903] (&sc->lock){--..}, at: [<f89ee91d>] ath5k_config_interface+0x3d/0x340 [ath5k]
> [ 171.439953]
> [ 171.439954] other info that might help us debug this:
> [ 171.441795] 3 locks held by ath5k_pci/2447:
> [ 171.442729] #0: ((name)){--..}, at: [<c013a122>] run_workqueue+0x102/0x1d0
> [ 171.443800] #1: (&(&local->scan_work)->work){--..}, at: [<c013a122>] run_workqueue+0x102/0x1d0
> [ 171.444859] #2: (&sc->lock){--..}, at: [<f89ee91d>] ath5k_config_interface+0x3d/0x340 [ath5k]
Should be fixed already:
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
Jiri Slaby wrote:
> Dave Young napsal(a):
>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>> sc->lock
>> This casue the kernel stuck
>>
>> Bug report please see:
>> http://lkml.org/lkml/2008/7/29/32
>>
>> Fixed it by remove the lock in sub routine "ath5k_beacon_update",
>> The ath5k_config_interface is the only caller to it.
>>
>> [ 171.430207] =============================================
>> [ 171.432140] [ INFO: possible recursive locking detected ]
>> [ 171.433113] 2.6.27-rc1-smp #4
>> [ 171.434079] ---------------------------------------------
>> [ 171.435039] ath5k_pci/2447 is trying to acquire lock:
>> [ 171.435990] (&sc->lock){--..}, at: [<f89ee9b5>]
>> ath5k_config_interface+0xd5/0x340 [ath5k]
>> [ 171.437046] [ 171.437048] but task is already holding lock:
>> [ 171.438903] (&sc->lock){--..}, at: [<f89ee91d>]
>> ath5k_config_interface+0x3d/0x340 [ath5k]
>> [ 171.439953] [ 171.439954] other info that might help us debug this:
>> [ 171.441795] 3 locks held by ath5k_pci/2447:
>> [ 171.442729] #0: ((name)){--..}, at: [<c013a122>]
>> run_workqueue+0x102/0x1d0
>> [ 171.443800] #1: (&(&local->scan_work)->work){--..}, at:
>> [<c013a122>] run_workqueue+0x102/0x1d0
>> [ 171.444859] #2: (&sc->lock){--..}, at: [<f89ee91d>]
>> ath5k_config_interface+0x3d/0x340 [ath5k]
>
> Should be fixed already:
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
I guess that didn't make it to -stable?
On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <[email protected]> wrote:
> Jiri Slaby wrote:
> > Dave Young napsal(a):
> >> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
> >> sc->lock
> >> This casue the kernel stuck
> >>
> >> Bug report please see:
> >> http://lkml.org/lkml/2008/7/29/32
> >>
> >> Fixed it by remove the lock in sub routine "ath5k_beacon_update",
> >> The ath5k_config_interface is the only caller to it.
> >>
> >> [ 171.430207] =============================================
> >> [ 171.432140] [ INFO: possible recursive locking detected ]
> >> [ 171.433113] 2.6.27-rc1-smp #4
> >> [ 171.434079] ---------------------------------------------
> >> [ 171.435039] ath5k_pci/2447 is trying to acquire lock:
> >> [ 171.435990] (&sc->lock){--..}, at: [<f89ee9b5>]
> >> ath5k_config_interface+0xd5/0x340 [ath5k]
> >> [ 171.437046] [ 171.437048] but task is already holding lock:
> >> [ 171.438903] (&sc->lock){--..}, at: [<f89ee91d>]
> >> ath5k_config_interface+0x3d/0x340 [ath5k]
> >> [ 171.439953] [ 171.439954] other info that might help us debug this:
> >> [ 171.441795] 3 locks held by ath5k_pci/2447:
> >> [ 171.442729] #0: ((name)){--..}, at: [<c013a122>]
> >> run_workqueue+0x102/0x1d0
> >> [ 171.443800] #1: (&(&local->scan_work)->work){--..}, at:
> >> [<c013a122>] run_workqueue+0x102/0x1d0
> >> [ 171.444859] #2: (&sc->lock){--..}, at: [<f89ee91d>]
> >> ath5k_config_interface+0x3d/0x340 [ath5k]
> >
> > Should be fixed already:
> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>
> I guess that didn't make it to -stable?
(cc stable!)
On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <[email protected]> wrote:
> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <[email protected]> wrote:
>
>> Jiri Slaby wrote:
>> > Dave Young napsal(a):
>> >> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>> >> sc->lock
>> >
>> > Should be fixed already:
>> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>
>> I guess that didn't make it to -stable?
>
> (cc stable!)
Not to worry, the commit that introduced it was
9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
came in after 2.6.26.
--
Bob Copeland %% http://www.bobcopeland.com
Bob Copeland napsal(a):
> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <[email protected]> wrote:
>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <[email protected]> wrote:
>>
>>> Jiri Slaby wrote:
>>>> Dave Young napsal(a):
>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>>>>> sc->lock
>>>> Should be fixed already:
>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>> I guess that didn't make it to -stable?
>> (cc stable!)
>
> Not to worry, the commit that introduced it was
> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
> came in after 2.6.26.
git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
v2.6.26-rc8-1219-g9d139c8
Jiri Slaby wrote:
> Bob Copeland napsal(a):
>
>> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <[email protected]> wrote:
>>
>>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <[email protected]> wrote:
>>>
>>>
>>>> Jiri Slaby wrote:
>>>>
>>>>> Dave Young napsal(a):
>>>>>
>>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>>>>>> sc->lock
>>>>>>
>>>>> Should be fixed already:
>>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>>>
>>>> I guess that didn't make it to -stable?
>>>>
>>> (cc stable!)
>>>
>> Not to worry, the commit that introduced it was
>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>> came in after 2.6.26.
>>
>
> git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
> v2.6.26-rc8-1219-g9d139c8
>
>
Jiri Slaby wrote:
> Bob Copeland napsal(a):
>
>> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <[email protected]> wrote:
>>
>>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <[email protected]> wrote:
>>>
>>>
>>>> Jiri Slaby wrote:
>>>>
>>>>> Dave Young napsal(a):
>>>>>
>>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>>>>>> sc->lock
>>>>>>
>>>>> Should be fixed already:
>>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>>>
>>>> I guess that didn't make it to -stable?
>>>>
>>> (cc stable!)
>>>
>> Not to worry, the commit that introduced it was
>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>> came in after 2.6.26.
>>
>
> git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
> v2.6.26-rc8-1219-g9d139c8
>
Unfortunately git-describe can be misleading.
All this tells you is that the commit in question was based on (a
descendant of) v2.6.26-rc8. It doesn't tell you whether the patch is
present in v2.6.26.
There must be a better way (for efficient merges, right?). But all I
can think of is comparing the files in question against the diff. I
checked myself and the changes don't appear to have been included in
v2.6.26.
Alan
Jiri Slaby napsal(a):
> Bob Copeland napsal(a):
>> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton
>> <[email protected]> wrote:
>>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg
>>> <[email protected]> wrote:
>>>
>>>> Jiri Slaby wrote:
>>>>> Dave Young napsal(a):
>>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive
>>>>>> locking of
>>>>>> sc->lock
>>>>> Should be fixed already:
>>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>>>
>>>> I guess that didn't make it to -stable?
>>> (cc stable!)
>>
>> Not to worry, the commit that introduced it was
>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>> came in after 2.6.26.
>
> git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
> v2.6.26-rc8-1219-g9d139c8
Fingers faster than brain. Why such a change went into -rc8? How long has
this been in linux-next? It appeared in mmotm between 2008-07-15-15-39 and
2008-07-23-02-07 which I think correspond to -next appearance -- isn't it
way too fast?
On Fri, Aug 1, 2008 at 11:02 AM, Jiri Slaby <[email protected]> wrote:
>>
>> Not to worry, the commit that introduced it was
>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>> came in after 2.6.26.
>
> git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
> v2.6.26-rc8-1219-g9d139c8
I'm not that expert in git, what does that mean? Some other commits
for 2.6.27 also show a 2.6.26-rc from git-describe (e.g. my
3a078876caee).
For my own investigation, I did a 'git-checkout v2.6.26' and looked at
the code to see the patch had not been applied yet. Is there an
easier way to definitively say commit X is/is not in tagged release Y?
--
Bob Copeland %% http://www.bobcopeland.com
Alan Jenkins napsal(a):
> There must be a better way (for efficient merges, right?). But all I
> can think of is comparing the files in question against the diff. I
> checked myself and the changes don't appear to have been included in
> v2.6.26.
Ah, I see. Is this a git-describe bug or my misunderstanding of the tool?
Sorry for the noise, it's not in 2.6.26.
Jiri Slaby wrote:
> Alan Jenkins napsal(a):
>> There must be a better way (for efficient merges, right?). But all I
>> can think of is comparing the files in question against the diff. I
>> checked myself and the changes don't appear to have been included in
>> v2.6.26.
>
> Ah, I see. Is this a git-describe bug or my misunderstanding of the tool?
It's not an implementation bug. It's just very easy to misunderstand.
git-describe only looks _back_ in time to what the current commit is
based on. In this case the commit was based on v2.6.26-rc8 - but it
_wasn't_ merged into 2.6.26. It was presumably merged in for
v2.6.27-rc1. This is a perfectly legal history in GIT.
It's probably most often encountered during git-bisect. If you bisect
e.g. between v2.6.26 and v.2.6.27-rc1, you're likely to see commits
which were based on v2.6.26-rc8.
If that doesn't help, try finding an introduction to GIT with some good
pictures. I think it's easier to understand it visually.
Alan
Bob Copeland wrote:
> On Fri, Aug 1, 2008 at 11:02 AM, Jiri Slaby <[email protected]> wrote:
>
>>> Not to worry, the commit that introduced it was
>>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>>> came in after 2.6.26.
>>>
>> git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
>> v2.6.26-rc8-1219-g9d139c8
>>
>
> I'm not that expert in git, what does that mean? Some other commits
> for 2.6.27 also show a 2.6.26-rc from git-describe (e.g. my
> 3a078876caee).
>
> For my own investigation, I did a 'git-checkout v2.6.26' and looked at
> the code to see the patch had not been applied yet. Is there an
> easier way to definitively say commit X is/is not in tagged release Y?
>
>
Aha! I think we want git-describe --contains.
$ git-describe --contains 2b142900784c6e38c8d39fa57d5f95ef08e735d8
v2.6.27-rc1~55^2~1
Alan
On Fri, Aug 1, 2008 at 9:43 PM, Bob Copeland <[email protected]> wrote:
> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <[email protected]> wrote:
>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <[email protected]> wrote:
>>
>>> Jiri Slaby wrote:
>>> > Dave Young napsal(a):
>>> >> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>>> >> sc->lock
>>> >
>>> > Should be fixed already:
>>> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>
>>> I guess that didn't make it to -stable?
>>
>> (cc stable!)
>
> Not to worry, the commit that introduced it was
> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
> came in after 2.6.26.
Strange, I get system stuck in 2.6.26 as well, so there might be other bugs.
>
> --
> Bob Copeland %% http://www.bobcopeland.com
>
--
Regards
dave
Dave Young napsal(a):
> On Fri, Aug 1, 2008 at 9:43 PM, Bob Copeland <[email protected]> wrote:
>> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <[email protected]> wrote:
>>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <[email protected]> wrote:
>>>
>>>> Jiri Slaby wrote:
>>>>> Dave Young napsal(a):
>>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>>>>>> sc->lock
>>>>> Should be fixed already:
>>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>> I guess that didn't make it to -stable?
>>> (cc stable!)
>> Not to worry, the commit that introduced it was
>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>> came in after 2.6.26.
>
> Strange, I get system stuck in 2.6.26 as well, so there might be other bugs.
Could you provide any logs regarding this, please?
On Mon, Aug 4, 2008 at 4:06 PM, Jiri Slaby <[email protected]> wrote:
> Dave Young napsal(a):
>>
>> On Fri, Aug 1, 2008 at 9:43 PM, Bob Copeland <[email protected]> wrote:
>>>
>>> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <[email protected]>
>>> wrote:
>>>>
>>>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <[email protected]>
>>>> wrote:
>>>>
>>>>> Jiri Slaby wrote:
>>>>>>
>>>>>> Dave Young napsal(a):
>>>>>>>
>>>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking
>>>>>>> of
>>>>>>> sc->lock
>>>>>>
>>>>>> Should be fixed already:
>>>>>>
>>>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>>>
>>>>> I guess that didn't make it to -stable?
>>>>
>>>> (cc stable!)
>>>
>>> Not to worry, the commit that introduced it was
>>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>>> came in after 2.6.26.
>>
>> Strange, I get system stuck in 2.6.26 as well, so there might be other
>> bugs.
>
> Could you provide any logs regarding this, please?
>
I will generate some new logs tomorrow.
There's some info in:
http://lkml.org/lkml/2008/7/29/32
--
Regards
dave