From: Ben Hutchings <bhutchings@solarflare.com>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC PATCH 02/12] net: Introduce new feature setting ops
Date: Sun, 19 Dec 2010 21:22:39 +0000 [thread overview]
Message-ID: <1292793759.2874.14.camel@localhost> (raw)
In-Reply-To: <20101219004959.GA12005@rere.qmqm.pl>
On Sun, 2010-12-19 at 01:49 +0100, Michał Mirosław wrote:
> On Thu, Dec 16, 2010 at 11:13:06PM +0000, Ben Hutchings wrote:
> > On Wed, 2010-12-15 at 23:24 +0100, Michał Mirosław wrote:
[...]
> > > +static int ethtool_set_features(struct net_device *dev, void __user *useraddr)
> > > +{
> > > + struct ethtool_features cmd;
> > > + struct ethtool_set_features_block features[ETHTOOL_DEV_FEATURE_WORDS];
> > > +
> > > + if (copy_from_user(&cmd, useraddr, sizeof(cmd)))
> > > + return -EFAULT;
> > > + useraddr += sizeof(cmd);
> > > +
> > > + if (cmd.count > ETHTOOL_DEV_FEATURE_WORDS)
> > > + cmd.count = ETHTOOL_DEV_FEATURE_WORDS;
> > So additional feature words will be silently ignored...
> > > + if (copy_from_user(features, useraddr, sizeof(*features) * cmd.count))
> > > + return -EFAULT;
> > > + memset(features + cmd.count, 0,
> > > + sizeof(features) - sizeof(*features) * cmd.count);
> > > +
> > > + features[0].valid &= dev->hw_features | NETIF_F_SOFT_FEATURES;
> > [...]
> >
> > ...as will any other unsupported features. This is not a good idea.
> > (However, remembering which features are wanted does seem like a good
> > idea.)
>
> That's intentional. Unsupported features can't be enabled anyway.
> hw_features is supposed to contain all features that the device can support
> and is able to enable/disable. This set should be constant and anything that
> is in the wanted_features set but is not supported because of other conditions
> will be stripped by ndo_fix_features() call.
>
> Other way would be to return EINVAL when bits not changeable are present in
> the valid mask. I don't want to do that, since then your example of changing
> a feature without GFEATURES first will not work.
That's right, it shouldn't work.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2010-12-19 21:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-15 22:24 [RFC PATCH 00/12] net: Unified offload configuration Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 07/12] vlan: convert VLAN devices to use ndo_fix_features() Michał Mirosław
2010-12-16 23:36 ` Ben Hutchings
2010-12-19 1:01 ` Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 01/12] net: Move check of checksum features to netdev_fix_features() Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 06/12] bridge: convert br_features_recompute() to ndo_fix_features Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 02/12] net: Introduce new feature setting ops Michał Mirosław
2010-12-16 23:13 ` Ben Hutchings
2010-12-19 0:49 ` Michał Mirosław
2010-12-19 21:22 ` Ben Hutchings [this message]
2010-12-19 23:43 ` Michał Mirosław
2010-12-20 16:41 ` Ben Hutchings
2010-12-15 22:24 ` [RFC PATCH 03/12] net: ethtool: use ndo_fix_features for offload setting Michał Mirosław
2010-12-16 23:23 ` Ben Hutchings
2010-12-19 0:54 ` Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 05/12] net: ethtool: use ndo_fix_features for ethtool_ops->set_flags Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 04/12] net: introduce NETIF_F_RXCSUM Michał Mirosław
2010-12-16 23:27 ` Ben Hutchings
2010-12-19 0:57 ` Michał Mirosław
2011-01-04 18:33 ` Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 11/12] veth: convert to hw_features Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 09/12] virtio_net: convert to ndo_fix_features Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 08/12] jme: convert offload constraints " Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 10/12] Intel net drivers: convert " Michał Mirosław
2010-12-15 22:24 ` [RFC PATCH 12/12] skge: convert to hw_features Michał Mirosław
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=1292793759.2874.14.camel@localhost \
--to=bhutchings@solarflare.com \
--cc=mirq-linux@rere.qmqm.pl \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).