All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Felix Fietkau <nbd@nbd.name>
Cc: "Kalle Valo" <kvalo@codeaurora.org>,
	"Sujith Manoharan" <c_manoha@qca.qualcomm.com>,
	ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org,
	"David S . Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"John W . Linville" <linville@tuxdriver.com>,
	"Felix Fietkau" <nbd@openwrt.org>,
	"Simon Wunderlich" <sw@simonwunderlich.de>,
	"Sven Eckelmann" <sven@narfation.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Linus Lüssing" <ll@simonwunderlich.de>
Subject: Re: [PATCH 3/3] ath9k: Fix potential hw interrupt resume during reset
Date: Wed, 15 Sep 2021 21:18:03 +0200	[thread overview]
Message-ID: <YUJGxZW1a+vlG335@sellars> (raw)
In-Reply-To: <255a49c7-d763-50d9-87e0-da22f4a9b053@nbd.name>

On Wed, Sep 15, 2021 at 11:48:55AM +0200, Felix Fietkau wrote:
> 
> On 2021-09-14 21:25, Linus Lüssing wrote:
> > From: Linus Lüssing <ll@simonwunderlich.de>
> > 
> > There is a small risk of the ath9k hw interrupts being reenabled in the
> > following way:
> > 
> > 1) ath_reset_internal()
> >    ...
> >    -> disable_irq()
> >       ...
> >       <- returns
> > 
> >                       2) ath9k_tasklet()
> >                          ...
> >                          -> ath9k_hw_resume_interrupts()
> >                          ...
> > 
> > 1) ath_reset_internal() continued:
> >    -> tasklet_disable(&sc->intr_tq); (= ath9k_tasklet() off)
> > 
> > By first disabling the ath9k interrupt there is a small window
> > afterwards which allows ath9k hw interrupts being reenabled through
> > the ath9k_tasklet() before we disable this tasklet in
> > ath_reset_internal(). Leading to having the ath9k hw interrupts enabled
> > during the reset, which we should avoid.
> I don't see a way in which interrupts can be re-enabled through the
> tasklet. disable_irq disables the entire PCI IRQ (not through ath9k hw
> registers), and they will only be re-enabled by the corresponding
> enable_irq call.

Ah, okay, then I think I misunderstood the previous fixes to the
ath9k interrupt shutdown during reset here. I had only tested the
following diff and assumed that it were not okay to have the ath9k
hw interrupt registers enabled within the spinlock'd section:

```
@@ -299,11 +299,23 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan)
 
        __ath_cancel_work(sc);
 
        disable_irq(sc->irq);
+       for (r = 0; r < 200; r++) {
+               msleep(5);
+
+               if (REG_READ(ah, AR_INTR_SYNC_CAUSE) ||
+                   REG_READ(ah, AR_INTR_ASYNC_CAUSE)) {
+                       break;
+               }
+       }
        tasklet_disable(&sc->intr_tq);
        tasklet_disable(&sc->bcon_tasklet);
        spin_lock_bh(&sc->sc_pcu_lock);
 
+       if (REG_READ(ah, AR_INTR_SYNC_CAUSE) ||
+           REG_READ(ah, AR_INTR_ASYNC_CAUSE))
+               ATH_DBG_WARN(1, "%s: interrupts are enabled", __func__);
+
        if (!sc->cur_chan->offchannel) {
                fastcc = false;
                caldata = &sc->cur_chan->caldata;
```

And yes, the general ath9k interrupt should still be disabled. Didn't
test for that but seems like it.


(And now I noticed that actually
 ath_reset_internal()
 -> ath_prepare_reset()
   -> ath9k_hw_disable_interrupts()
     -> ath9k_hw_kill_interrupts()
 disables the ath9k hw interrupt registers before the
 ath_reset_internal()->ath9k_hw_reset() call anyway.)


What would you prefer, should this patch just be dropped or should
I resend it without the "Fixes:" line as a cosmetic change? (e.g. to
have the order in reverse to reenablement at the end of
ath_reset_internal(), to avoid confusion in the future?)

Regards, Linus

  reply	other threads:[~2021-09-15 19:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14 19:25 [PATCH 0/3] ath9k: interrupt fixes on queue reset Linus Lüssing
2021-09-14 19:25 ` [PATCH 1/3] ath9k: add option to reset the wifi chip via debugfs Linus Lüssing
2021-10-05 14:27   ` Kalle Valo
2021-09-14 19:25 ` [PATCH 2/3] ath9k: Fix potential interrupt storm on queue reset Linus Lüssing
2021-09-14 19:25 ` [PATCH 3/3] ath9k: Fix potential hw interrupt resume during reset Linus Lüssing
2021-09-15  9:48   ` Felix Fietkau
2021-09-15 19:18     ` Linus Lüssing [this message]
2021-09-14 19:53 ` [PATCH 0/3] ath9k: interrupt fixes on queue reset Toke Høiland-Jørgensen
2021-09-15  9:23   ` Linus Lüssing
2021-10-05 14:12 ` Linus Lüssing
2021-10-05 14:24   ` Kalle Valo

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=YUJGxZW1a+vlG335@sellars \
    --to=linus.luessing@c0d3.blue \
    --cc=ath9k-devel@qca.qualcomm.com \
    --cc=c_manoha@qca.qualcomm.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=ll@simonwunderlich.de \
    --cc=nbd@nbd.name \
    --cc=nbd@openwrt.org \
    --cc=netdev@vger.kernel.org \
    --cc=sven@narfation.org \
    --cc=sw@simonwunderlich.de \
    /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.