From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]:51918 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750726AbdFAE1y (ORCPT ); Thu, 1 Jun 2017 00:27:54 -0400 From: Kalle Valo To: Michael =?utf-8?Q?B=C3=BCsch?= Cc: Jia-Ju Bai , netdev@vger.kernel.org, linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org, linux-kernel@vger.kernel.org, Larry.Finger@lwfinger.net Subject: Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed References: <1496225353-5544-1-git-send-email-baijiaju1990@163.com> <877f0xnwyk.fsf@kamboji.qca.qualcomm.com> <20170531173107.25eeda48@wiggum> Date: Thu, 01 Jun 2017 07:27:20 +0300 In-Reply-To: <20170531173107.25eeda48@wiggum> ("Michael \=\?utf-8\?Q\?B\=C3\=BCs\?\= \=\?utf-8\?Q\?ch\=22's\?\= message of "Wed, 31 May 2017 17:32:15 +0200") Message-ID: <878tlcmixj.fsf@kamboji.qca.qualcomm.com> (sfid-20170601_062823_631016_55836DB0) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: Michael B=C3=BCsch writes: >> > --- 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); >> >=20=20 >> > if (changed & BSS_CHANGED_BSSID) { >> > + spin_unlock_irqrestore(&wl->irq_lock, flags); >> > b43legacy_synchronize_irq(dev); >> > + spin_lock_irqsave(&wl->irq_lock, flags);=20=20 >>=20 >> 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. >>=20 > > > I think releasing the lock possibly is fine. It certainly is better than > sleeping with a lock held. Sure, but IMHO in general I think the practise of releasing the lock like this in a middle of function is dangerous as one can easily miss that upper and lower halves of the function are not actually atomic anymore. And in this case that it's under a conditional makes it even worse. --=20 Kalle Valo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751242AbdFAE15 (ORCPT ); Thu, 1 Jun 2017 00:27:57 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:51918 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750726AbdFAE1y (ORCPT ); Thu, 1 Jun 2017 00:27:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 8522460618 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=kvalo@codeaurora.org From: Kalle Valo To: Michael =?utf-8?Q?B=C3=BCsch?= Cc: Jia-Ju Bai , netdev@vger.kernel.org, linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org, linux-kernel@vger.kernel.org, Larry.Finger@lwfinger.net Subject: Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed References: <1496225353-5544-1-git-send-email-baijiaju1990@163.com> <877f0xnwyk.fsf@kamboji.qca.qualcomm.com> <20170531173107.25eeda48@wiggum> Date: Thu, 01 Jun 2017 07:27:20 +0300 In-Reply-To: <20170531173107.25eeda48@wiggum> ("Michael \=\?utf-8\?Q\?B\=C3\=BCs\?\= \=\?utf-8\?Q\?ch\=22's\?\= message of "Wed, 31 May 2017 17:32:15 +0200") Message-ID: <878tlcmixj.fsf@kamboji.qca.qualcomm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v514SPJV031597 Michael Büsch writes: >> > --- 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. Sure, but IMHO in general I think the practise of releasing the lock like this in a middle of function is dangerous as one can easily miss that upper and lower halves of the function are not actually atomic anymore. And in this case that it's under a conditional makes it even worse. -- Kalle Valo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kalle Valo Date: Thu, 01 Jun 2017 07:27:20 +0300 Subject: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed In-Reply-To: <20170531173107.25eeda48@wiggum> ("Michael \=\?utf-8\?Q\?B\=C3\=BCs\?\= \=\?utf-8\?Q\?ch\=22's\?\= message of "Wed, 31 May 2017 17:32:15 +0200") References: <1496225353-5544-1-git-send-email-baijiaju1990@163.com> <877f0xnwyk.fsf@kamboji.qca.qualcomm.com> <20170531173107.25eeda48@wiggum> Message-ID: <878tlcmixj.fsf@kamboji.qca.qualcomm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michael =?utf-8?Q?B=C3=BCsch?= Cc: Jia-Ju Bai , netdev@vger.kernel.org, linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org, linux-kernel@vger.kernel.org, Larry.Finger@lwfinger.net Michael B?sch writes: >> > --- 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. Sure, but IMHO in general I think the practise of releasing the lock like this in a middle of function is dangerous as one can easily miss that upper and lower halves of the function are not actually atomic anymore. And in this case that it's under a conditional makes it even worse. -- Kalle Valo