From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org,
"R. Herbst" <ruediger.herbst@googlemail.com>,
Brian Hamilton <bhamilton04@gmail.com>
Subject: Re: [RFC/PATCH] sungem: Spring cleaning and GRO support
Date: Wed, 01 Jun 2011 09:55:32 +1000 [thread overview]
Message-ID: <1306886132.29297.3.camel@pasglop> (raw)
In-Reply-To: <1306880249.2866.53.camel@bwh-desktop>
On Tue, 2011-05-31 at 23:17 +0100, Ben Hutchings wrote:
> On Wed, 2011-06-01 at 07:58 +1000, Benjamin Herrenschmidt wrote:
> [...]
> > > Is the pm_mutex really needed? All control operations should already be
> > > serialised by the RTNL lock, and you've started taking that in the
> > > suspend and resume functions.
> >
> > Well, it's been there forever and I need to get my head around it, but
> > yes, the rtnl lock might be able to get rid of it, good point. I just
> > actually added that :-)
> >
> > So all ndo_set_* are going to be covered by rtnl including the ethtool ?
>
> ethtool ops are almost all covered; the kernel-doc comment has the
> details.
>
> As for net_device_ops, locking varies (and really ought to be documented
> in <linux/netdevice.h>). At least ndo_set_mac_address, ndo_change_mtu
> and ndo_do_ioctl (plus of course ndo_open and ndo_stop) are called
> holding the RTNL lock.
Ok. The main annoyance for locking has always been set_multicast which
is called with a spinlock afaik.
> > I don't really want to take the rtnl lock in the reset task (at least
> > not for the whole duration of it), so I may have to be a bit creative on
> > synchronization there.
> [...]
>
> Unless reset takes more than a second I wouldn't worry about it.
I don't want to take a spinlock for even near that, especially since we
do the reset on every link down. I suppose rtnl might be less of an
issue, I'll have a look.
Cheers,
Ben.
next prev parent reply other threads:[~2011-05-31 23:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-31 7:59 [RFC/PATCH] sungem: Spring cleaning and GRO support Benjamin Herrenschmidt
2011-05-31 20:59 ` Ben Hutchings
2011-05-31 21:58 ` Benjamin Herrenschmidt
2011-05-31 22:17 ` Ben Hutchings
2011-05-31 23:55 ` Benjamin Herrenschmidt [this message]
2011-06-01 0:04 ` Ben Hutchings
2011-06-01 2:41 ` David Miller
2011-06-01 3:45 ` Benjamin Herrenschmidt
2011-06-01 6:24 ` Benjamin Herrenschmidt
2011-06-01 6:35 ` David Miller
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=1306886132.29297.3.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=bhamilton04@gmail.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=ruediger.herbst@googlemail.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.