All of lore.kernel.org
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger@lwfinger.net>
To: "Michael Büsch" <m@bues.ch>, "Kalle Valo" <kvalo@codeaurora.org>
Cc: Jia-Ju Bai <baijiaju1990@163.com>,
	netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	b43-dev@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed
Date: Wed, 31 May 2017 19:07:15 -0500	[thread overview]
Message-ID: <284d6d5d-d548-9e05-eafd-a6b521af5a04@lwfinger.net> (raw)
In-Reply-To: <20170531173107.25eeda48@wiggum>

On 05/31/2017 10:32 AM, Michael Büsch wrote:
> On Wed, 31 May 2017 13:26:43 +0300
> Kalle Valo <kvalo@codeaurora.org> wrote:
> 
>> Jia-Ju Bai <baijiaju1990@163.com> writes:
>>
>>> The driver may sleep under a spin lock, and the function call path is:
>>> b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
>>>    b43legacy_synchronize_irq
>>>      synchronize_irq --> may sleep
>>>
>>> To fix it, the lock is released before b43legacy_synchronize_irq, and the
>>> lock is acquired again after this function.
>>>
>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
>>> ---
>>>   drivers/net/wireless/broadcom/b43legacy/main.c |    2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c b/drivers/net/wireless/broadcom/b43legacy/main.c
>>> index f1e3dad..31ead21 100644
>>> --- a/drivers/net/wireless/broadcom/b43legacy/main.c
>>> +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
>>> @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct ieee80211_hw *hw,
>>>   	b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
>>>   
>>>   	if (changed & BSS_CHANGED_BSSID) {
>>> +		spin_unlock_irqrestore(&wl->irq_lock, flags);
>>>   		b43legacy_synchronize_irq(dev);
>>> +		spin_lock_irqsave(&wl->irq_lock, flags);
>>
>> To me this looks like a fragile workaround and not a real fix. You can
>> easily add new race conditions with releasing the lock like this.
>>
> 
> 
> I think releasing the lock possibly is fine. It certainly is better than
> sleeping with a lock held.
> We disabled the device interrupts just before this line.
> 
> However I think the synchronize_irq should be outside of the
> conditional right after the write to B43legacy_MMIO_GEN_IRQ_MASK. (So
> two lines above)
> I don't think it makes sense to only synchronize if BSS_CHANGED_BSSID
> is set.
> 
> 
> On the other hand b43 does not have this irq-disabling foobar anymore.
> So somebody must have removed it. Maybe you can find the commit that
> removed this stuff from b43 and port it to b43legacy?
> 
> 
> So I would vote for moving the synchronize_irq up outside of the
> conditional and put the unlock/lock sequence around it.
> And as a second patch on top of that try to remove this stuff
> altogether like b43 did.

The patch that removed it in b43 is

commit 36dbd9548e92268127b0c31b0e121e63e9207108
Author: Michael Buesch <mb@bu3sch.de>
Date:   Fri Sep 4 22:51:29 2009 +0200

     b43: Use a threaded IRQ handler

     Use a threaded IRQ handler to allow locking the mutex and
     sleeping while executing an interrupt.
     This removes usage of the irq_lock spinlock, but introduces
     a new hardirq_lock, which is _only_ used for the PCI/SSB lowlevel
     hard-irq handler. Sleeping busses (SDIO) will use mutex instead.

     Signed-off-by: Michael Buesch <mb@bu3sch.de>
     Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
     Signed-off-by: John W. Linville <linville@tuxdriver.com>

I vaguely remember this patch. Although it is roughly a 1000-line fix, I will 
try to port it to b43legacy. I still have an old BCM4306 PCMCIA card that I can 
test in a PowerBook G4.

I agree with Michael that this is the way to go. Both of Jia-Ju's patches should 
be rejected.

Larry

WARNING: multiple messages have this Message-ID (diff)
From: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
To: "Michael Büsch" <m@bues.ch>,
	"Kalle Valo" <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Jia-Ju Bai <baijiaju1990-9Onoh4P/yGk@public.gmane.org>,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed
Date: Wed, 31 May 2017 19:07:15 -0500	[thread overview]
Message-ID: <284d6d5d-d548-9e05-eafd-a6b521af5a04@lwfinger.net> (raw)
In-Reply-To: <20170531173107.25eeda48@wiggum>

On 05/31/2017 10:32 AM, Michael Büsch wrote:
> On Wed, 31 May 2017 13:26:43 +0300
> Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> 
>> Jia-Ju Bai <baijiaju1990-9Onoh4P/yGk@public.gmane.org> writes:
>>
>>> The driver may sleep under a spin lock, and the function call path is:
>>> b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
>>>    b43legacy_synchronize_irq
>>>      synchronize_irq --> may sleep
>>>
>>> To fix it, the lock is released before b43legacy_synchronize_irq, and the
>>> lock is acquired again after this function.
>>>
>>> Signed-off-by: Jia-Ju Bai <baijiaju1990-9Onoh4P/yGk@public.gmane.org>
>>> ---
>>>   drivers/net/wireless/broadcom/b43legacy/main.c |    2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c b/drivers/net/wireless/broadcom/b43legacy/main.c
>>> index f1e3dad..31ead21 100644
>>> --- a/drivers/net/wireless/broadcom/b43legacy/main.c
>>> +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
>>> @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct ieee80211_hw *hw,
>>>   	b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
>>>   
>>>   	if (changed & BSS_CHANGED_BSSID) {
>>> +		spin_unlock_irqrestore(&wl->irq_lock, flags);
>>>   		b43legacy_synchronize_irq(dev);
>>> +		spin_lock_irqsave(&wl->irq_lock, flags);
>>
>> To me this looks like a fragile workaround and not a real fix. You can
>> easily add new race conditions with releasing the lock like this.
>>
> 
> 
> I think releasing the lock possibly is fine. It certainly is better than
> sleeping with a lock held.
> We disabled the device interrupts just before this line.
> 
> However I think the synchronize_irq should be outside of the
> conditional right after the write to B43legacy_MMIO_GEN_IRQ_MASK. (So
> two lines above)
> I don't think it makes sense to only synchronize if BSS_CHANGED_BSSID
> is set.
> 
> 
> On the other hand b43 does not have this irq-disabling foobar anymore.
> So somebody must have removed it. Maybe you can find the commit that
> removed this stuff from b43 and port it to b43legacy?
> 
> 
> So I would vote for moving the synchronize_irq up outside of the
> conditional and put the unlock/lock sequence around it.
> And as a second patch on top of that try to remove this stuff
> altogether like b43 did.

The patch that removed it in b43 is

commit 36dbd9548e92268127b0c31b0e121e63e9207108
Author: Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
Date:   Fri Sep 4 22:51:29 2009 +0200

     b43: Use a threaded IRQ handler

     Use a threaded IRQ handler to allow locking the mutex and
     sleeping while executing an interrupt.
     This removes usage of the irq_lock spinlock, but introduces
     a new hardirq_lock, which is _only_ used for the PCI/SSB lowlevel
     hard-irq handler. Sleeping busses (SDIO) will use mutex instead.

     Signed-off-by: Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
     Tested-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
     Signed-off-by: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>

I vaguely remember this patch. Although it is roughly a 1000-line fix, I will 
try to port it to b43legacy. I still have an old BCM4306 PCMCIA card that I can 
test in a PowerBook G4.

I agree with Michael that this is the way to go. Both of Jia-Ju's patches should 
be rejected.

Larry

WARNING: multiple messages have this Message-ID (diff)
From: Larry Finger <Larry.Finger@lwfinger.net>
To: "Michael Büsch" <m@bues.ch>, "Kalle Valo" <kvalo@codeaurora.org>
Cc: Jia-Ju Bai <baijiaju1990@163.com>,
	netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	b43-dev@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed
Date: Wed, 31 May 2017 19:07:15 -0500	[thread overview]
Message-ID: <284d6d5d-d548-9e05-eafd-a6b521af5a04@lwfinger.net> (raw)
In-Reply-To: <20170531173107.25eeda48@wiggum>

On 05/31/2017 10:32 AM, Michael B?sch wrote:
> On Wed, 31 May 2017 13:26:43 +0300
> Kalle Valo <kvalo@codeaurora.org> wrote:
> 
>> Jia-Ju Bai <baijiaju1990@163.com> writes:
>>
>>> The driver may sleep under a spin lock, and the function call path is:
>>> b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
>>>    b43legacy_synchronize_irq
>>>      synchronize_irq --> may sleep
>>>
>>> To fix it, the lock is released before b43legacy_synchronize_irq, and the
>>> lock is acquired again after this function.
>>>
>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
>>> ---
>>>   drivers/net/wireless/broadcom/b43legacy/main.c |    2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c b/drivers/net/wireless/broadcom/b43legacy/main.c
>>> index f1e3dad..31ead21 100644
>>> --- a/drivers/net/wireless/broadcom/b43legacy/main.c
>>> +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
>>> @@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct ieee80211_hw *hw,
>>>   	b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
>>>   
>>>   	if (changed & BSS_CHANGED_BSSID) {
>>> +		spin_unlock_irqrestore(&wl->irq_lock, flags);
>>>   		b43legacy_synchronize_irq(dev);
>>> +		spin_lock_irqsave(&wl->irq_lock, flags);
>>
>> To me this looks like a fragile workaround and not a real fix. You can
>> easily add new race conditions with releasing the lock like this.
>>
> 
> 
> I think releasing the lock possibly is fine. It certainly is better than
> sleeping with a lock held.
> We disabled the device interrupts just before this line.
> 
> However I think the synchronize_irq should be outside of the
> conditional right after the write to B43legacy_MMIO_GEN_IRQ_MASK. (So
> two lines above)
> I don't think it makes sense to only synchronize if BSS_CHANGED_BSSID
> is set.
> 
> 
> On the other hand b43 does not have this irq-disabling foobar anymore.
> So somebody must have removed it. Maybe you can find the commit that
> removed this stuff from b43 and port it to b43legacy?
> 
> 
> So I would vote for moving the synchronize_irq up outside of the
> conditional and put the unlock/lock sequence around it.
> And as a second patch on top of that try to remove this stuff
> altogether like b43 did.

The patch that removed it in b43 is

commit 36dbd9548e92268127b0c31b0e121e63e9207108
Author: Michael Buesch <mb@bu3sch.de>
Date:   Fri Sep 4 22:51:29 2009 +0200

     b43: Use a threaded IRQ handler

     Use a threaded IRQ handler to allow locking the mutex and
     sleeping while executing an interrupt.
     This removes usage of the irq_lock spinlock, but introduces
     a new hardirq_lock, which is _only_ used for the PCI/SSB lowlevel
     hard-irq handler. Sleeping busses (SDIO) will use mutex instead.

     Signed-off-by: Michael Buesch <mb@bu3sch.de>
     Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
     Signed-off-by: John W. Linville <linville@tuxdriver.com>

I vaguely remember this patch. Although it is roughly a 1000-line fix, I will 
try to port it to b43legacy. I still have an old BCM4306 PCMCIA card that I can 
test in a PowerBook G4.

I agree with Michael that this is the way to go. Both of Jia-Ju's patches should 
be rejected.

Larry

  reply	other threads:[~2017-06-01  0:07 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-31 10:09 [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed Jia-Ju Bai
2017-05-31 10:26 ` Kalle Valo
2017-05-31 10:26   ` Kalle Valo
2017-05-31 12:15   ` Arend van Spriel
2017-05-31 12:15     ` Arend van Spriel
2017-05-31 15:32   ` Michael Büsch
2017-05-31 15:32     ` Michael Büsch
2017-06-01  0:07     ` Larry Finger [this message]
2017-06-01  0:07       ` Larry Finger
2017-06-01  0:07       ` Larry Finger
2017-06-01  1:07       ` Jia-Ju Bai
2017-06-01  1:07         ` Jia-Ju Bai
2017-06-01  1:07         ` Jia-Ju Bai
2017-06-01  5:31       ` Michael Büsch
2017-06-01  5:31         ` Michael Büsch
2017-06-01  4:27     ` Kalle Valo
2017-06-01  4:27       ` Kalle Valo
2017-06-01  4:27       ` Kalle Valo
2017-06-01  5:29       ` Michael Büsch
2017-06-01  5:29         ` Michael Büsch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=284d6d5d-d548-9e05-eafd-a6b521af5a04@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=b43-dev@lists.infradead.org \
    --cc=baijiaju1990@163.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=m@bues.ch \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.