All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
	nbd@nbd.name, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] mt76: usb: fix possible memory leak during suspend/resume
Date: Mon, 15 Apr 2019 13:53:53 +0200	[thread overview]
Message-ID: <20190415115352.GA4143@redhat.com> (raw)
In-Reply-To: <20190413101056.GA7940@localhost.localdomain>

On Sat, Apr 13, 2019 at 12:10:59PM +0200, Lorenzo Bianconi wrote:
> > On Fri, Apr 12, 2019 at 06:27:48PM +0200, Lorenzo Bianconi wrote:
> > > > > On Fri, Apr 12, 2019 at 02:27:16PM +0200, Lorenzo Bianconi wrote:
> > > > > > Disable mt76u_tx_tasklet at the end of mt76u_stop_queues in order to
> > > > > > properly deallocate all pending skbs during suspend/resume phase
> > > > > 
> > > > > On suspend/resume tx skb's are processed after tasklet_enable()
> > > > > in resume callback. There is issue with device removal though
> > > > > (during suspend or otherwise).
> > > > 
> > > > Hi Stanislaw,
> > > > 
> > > > I guess the right moment to deallocate the skbs is during suspend since resume
> > > > can happen in very far future
> > 
> > Yes, it's better to free on suspend, but in practice does not really matter since
> > system is disabled till resume.
> > 
> > > > > > Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer")
> > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > > ---
> > > > > >  drivers/net/wireless/mediatek/mt76/usb.c | 4 ++--
> > > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
> > > > > > index a3acc070063a..575207133775 100644
> > > > > > --- a/drivers/net/wireless/mediatek/mt76/usb.c
> > > > > > +++ b/drivers/net/wireless/mediatek/mt76/usb.c
> > > > > > @@ -842,10 +842,10 @@ static void mt76u_stop_tx(struct mt76_dev *dev)
> > > > > >  void mt76u_stop_queues(struct mt76_dev *dev)
> > > > > >  {
> > > > > >  	tasklet_disable(&dev->usb.rx_tasklet);
> > > > > > -	tasklet_disable(&dev->usb.tx_tasklet);
> > > > > > -
> > > > > >  	mt76u_stop_rx(dev);
> > > > > > +
> > > > > >  	mt76u_stop_tx(dev);
> > > > > > +	tasklet_disable(&dev->usb.tx_tasklet);
> > > > > 
> > > > > If tasklet is scheduled and we disable it and never enable, we end up
> > > > > with infinite loop in tasklet_action_common(). This patch make the
> > > > > problem less reproducible since tasklet_disable() is moved after
> > > > > usb_kill_urb() -> tasklet_schedule(), but it is still possible.
> > > > 
> > > > I can see the point here. Maybe we can just run tasklet_kill instead of
> > > > tasklet_disable here (at least for tx one)
> > 
> > I think you have right as tasklet_kill() will wait for scheduled tasklet .
> > Originally in my patch (see below) I used wait_event as I thought
> > tasklet_kill() may prevent scheduled tasklet to be executed (hence cause
> > leak) but that seems to be not true.
> 
> I agree with rx side (good catch!!), but on tx one I guess usb_kill_urb()
> is already waiting for tx pending so we just need to use tasklet_kill
> at the end of mt76u_stop_queues, in this way we will free pending skbs during
> suspend

I looked more into that and there are some issues with this approach.
tx_tasklet do mt76_txq_schedule() which can queue tx frames. Also we
do not free skb's that require status check and dev->usb.stat_work 
is already (correctly) stopped on mac80211.stop. 

I'll use wait_event(dev->tx_wait) on mac80211 stop to handle those
issues correctly.

Stanislaw

  reply	other threads:[~2019-04-15 11:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1555071870.git.lorenzo@kernel.org>
2019-04-12 12:27 ` [PATCH] mt76: usb: fix possible memory leak during suspend/resume Lorenzo Bianconi
2019-04-12 14:54   ` Stanislaw Gruszka
2019-04-12 15:35     ` Lorenzo Bianconi
2019-04-12 16:27       ` Lorenzo Bianconi
2019-04-13  8:30         ` Stanislaw Gruszka
2019-04-13 10:10           ` Lorenzo Bianconi
2019-04-15 11:53             ` Stanislaw Gruszka [this message]
2019-04-15 15:04               ` Lorenzo Bianconi
2019-04-16  8:04                 ` Stanislaw Gruszka
2019-04-16  8:12                   ` Lorenzo Bianconi
2019-04-16  8:27                     ` Stanislaw Gruszka
2019-04-16  8:33                       ` Lorenzo Bianconi

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=20190415115352.GA4143@redhat.com \
    --to=sgruszka@redhat.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=lorenzo@kernel.org \
    --cc=nbd@nbd.name \
    /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.