From: Steve Wise <swise@opengridcomputing.com>
To: Roland Dreier <rdreier@cisco.com>
Cc: David Miller <davem@davemloft.net>,
shemminger@vyatta.com, arjan@infradead.org,
netdev@vger.kernel.org
Subject: Re: Printing the driver name as part of the netdev watchdog message
Date: Tue, 08 Jul 2008 14:13:43 -0500 [thread overview]
Message-ID: <4873BC67.8010205@opengridcomputing.com> (raw)
In-Reply-To: <adazlotwalk.fsf@cisco.com>
Roland Dreier wrote:
> > I doubt it uses the RTNL semaphore elsewhere to protect
> > against this path, which is the only protection these
> > calls currently have.
>
> As far as I can tell from reading the code, the only places in cxgb3
> that use t3_read_flash() are in the netdevice's open and ioctl methods,
> and the ethtool get_drvinfo method. So as far as I can tell the current
> code is fine as long as rtnl is held across get_drvinfo.
>
> > Please don't bring up scarecrows, this looks like simply
> > a bug which already exists.
>
> I don't even know how to take this. "Please don't review our changes"??
> "Please don't report bugs"??
>
>
So what is the conclusion here? If the rtnl doesn't need to be held
around calls to ethtool ops, then cxgb3 is broken. In addition, the
iw_cxgb3 driver is currently broken too because a recent commit
(f4e91eb4a81559da87a3843758a641b5cc590b65) accidentally removed
acquiring of the rtnl before calling an ethtool op in cxgb3. I want to
resolve this.
So should I put the rtnl acquisitions back in iw_cxgb3? Or fix cxgb3 to
not assume rtnl is held?
Steve.
next prev parent reply other threads:[~2008-07-08 19:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-06 20:08 Printing the driver name as part of the netdev watchdog message Arjan van de Ven
2008-07-06 22:53 ` David Miller
2008-07-06 23:56 ` Arjan van de Ven
2008-07-07 1:51 ` Wang Chen
2008-07-07 3:59 ` David Miller
2008-07-07 4:34 ` Arjan van de Ven
2008-07-07 4:49 ` David Miller
2008-07-07 4:57 ` Arjan van de Ven
2008-07-07 6:44 ` David Miller
2008-07-07 15:23 ` Arjan van de Ven
2008-07-07 1:08 ` Stephen Hemminger
2008-07-07 1:22 ` David Miller
2008-07-07 1:53 ` Jeff Garzik
2008-07-07 17:05 ` Stephen Hemminger
2008-07-07 22:45 ` Roland Dreier
2008-07-07 22:57 ` David Miller
2008-07-07 23:14 ` Roland Dreier
2008-07-07 23:44 ` Stephen Hemminger
2008-07-08 0:10 ` Arjan van de Ven
2008-07-08 19:13 ` Steve Wise [this message]
2008-07-08 21:31 ` David Miller
2008-07-08 21:47 ` Arjan van de Ven
2008-07-08 21:57 ` David Miller
2008-07-08 23:48 ` Arjan van de Ven
2008-07-08 23:53 ` David Miller
2008-07-09 0:17 ` Arjan van de Ven
2008-07-09 1:44 ` Arjan van de Ven
2008-07-09 3:16 ` Stephen Hemminger
2008-07-09 17:20 ` Joe Perches
2008-07-09 17:56 ` Arjan van de Ven
2008-07-09 18:20 ` Joe Perches
2008-07-09 18:50 ` Arjan van de Ven
2008-07-09 18:28 ` Ben Hutchings
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=4873BC67.8010205@opengridcomputing.com \
--to=swise@opengridcomputing.com \
--cc=arjan@infradead.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=rdreier@cisco.com \
--cc=shemminger@vyatta.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.