All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@gmail.com>
To: Alan Cox <alan@linux.intel.com>
Cc: jesse.brandeburg@intel.com, netdev@vger.kernel.org
Subject: Re: [RFC PATCH] e100: Fix workqueue race
Date: Fri, 22 Jan 2010 09:38:34 +0000	[thread overview]
Message-ID: <20100122093834.GA7629@ff.dom.local> (raw)
In-Reply-To: <20100122090731.GC6200@ff.dom.local>

On Fri, Jan 22, 2010 at 09:07:31AM +0000, Jarek Poplawski wrote:
> On Fri, Jan 22, 2010 at 08:42:00AM +0000, Jarek Poplawski wrote:
> > On 21-01-2010 17:48, Alan Cox wrote:
> > > (Incidentally this doesn't seem to be the only net driver that looks
> > > suspect here)
> > > 
> > > e100: Fix the TX workqueue race
> > > 
> > > From: Alan Cox <alan@linux.intel.com>
> > > 
> > > Nothing stops the workqueue being left to run in parallel with close or a
> > > few other operations. This causes double unmaps and the like.
> > > 
> > > See kerneloops.org #1041230 for an example
> > > 
> > > Signed-off-by: Alan Cox <alan@linux.intel.com>
> > > ---
> > > 
> > >  drivers/net/e100.c |   13 +++++++++++--
> > >  1 files changed, 11 insertions(+), 2 deletions(-)
> > > 
> > > 
> > > diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> > > index 5c7a155..5e02e4f 100644
> > > --- a/drivers/net/e100.c
> > > +++ b/drivers/net/e100.c
> > > @@ -2232,7 +2232,7 @@ err_rx_clean_list:
> > >  	return err;
> > >  }
> > >  
> > > -static void e100_down(struct nic *nic)
> > > +static void e100_do_down(struct nic *nic)
> > >  {
> > >  	/* wait here for poll to complete */
> > >  	napi_disable(&nic->napi);
> > > @@ -2245,6 +2245,15 @@ static void e100_down(struct nic *nic)
> > >  	e100_rx_clean_list(nic);
> > >  }
> > >  
> > > +/* For the non TX timeout case we want to kill the tx timeout before
> > > +   we do this otherwise a parallel tx timeout will make a nasty mess. */
> > > +
> > > +static void e100_down(struct nic *nic)
> > > +{
> > > +	cancel_work_sync(&nic->tx_timeout_task);
> > 
> > Can't tx_timeout_task be triggered just between these two calls here?
> 
> More exactly: except when this is called from dev_close(), where it
> should work OK. (At least until tx_timeout_task doesn't take any lock
> held here - especially rtnl_lock.)

Hmm... Even more exactly, since tx_timeout_task can be triggered not
only by dev_watchdog(), dev_close() is suspicious too.

Jarek P.

      reply	other threads:[~2010-01-22  9:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-21 16:48 [RFC PATCH] e100: Fix workqueue race Alan Cox
2010-01-21 17:20 ` Stephen Hemminger
2010-01-22  8:42 ` Jarek Poplawski
2010-01-22  9:07   ` Jarek Poplawski
2010-01-22  9:38     ` Jarek Poplawski [this message]

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=20100122093834.GA7629@ff.dom.local \
    --to=jarkao2@gmail.com \
    --cc=alan@linux.intel.com \
    --cc=jesse.brandeburg@intel.com \
    --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.