From: Cong Wang <amwang@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org,
Sylvain Munaut <s.munaut@whatever-company.com>,
David Miller <davem@davemloft.net>
Subject: Re: Q: what protects dev->napi_list?
Date: Fri, 24 Aug 2012 18:39:13 +0800 [thread overview]
Message-ID: <1345804753.11584.43.camel@cr0> (raw)
In-Reply-To: <1345803142.29722.20.camel@edumazet-glaptop>
On Fri, 2012-08-24 at 12:12 +0200, Eric Dumazet wrote:
> On Fri, 2012-08-24 at 17:46 +0800, Cong Wang wrote:
> > Hi,
> >
> > Sylvain reported a netpoll CPU stall
> > http://marc.info/?l=linux-netdev&m=134563282530588&w=2
> >
> > I tried to provide some fix for it:
> > http://marc.info/?l=linux-netdev&m=134571069921429&w=2
> >
> > When reviewing that code, I noticed a problem, it seems dev->napi_list
> > is not protected by any lock? What if the device driver calls
> > netif_napi_del() meanwhile we are iterating &dev->napi_list in
> > poll_napi()? It seems netif_napi_del()/netif_napi_add() are usually
> > called with the RTNL lock held during driver init/uninit, but again
> > poll_napi() doesn't have RTNL lock.
> >
>
> Of course poll_napi() cant try to get RTNL (its a mutex by the way)
>
> There are no problems, since :
>
> netif_napi_add() is called at device open time (before napi_poll() can
> use it)
>
> netif_napi_del() at device dismantle time (after making sure napi_poll()
> wont use the device again)
Yeah, but bnx2 driver calls it at other time too, for example
bnx2_change_ring_size() which in turn could be called by
bnx2_set_channels().
next prev parent reply other threads:[~2012-08-24 10:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-24 9:46 Q: what protects dev->napi_list? Cong Wang
2012-08-24 10:12 ` Eric Dumazet
2012-08-24 10:39 ` Cong Wang [this message]
2012-08-24 11:29 ` Eric Dumazet
2012-08-25 6:08 ` Cong Wang
2012-08-25 6:49 ` Eric Dumazet
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=1345804753.11584.43.camel@cr0 \
--to=amwang@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=s.munaut@whatever-company.com \
/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.