From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Amit Salecha <amit.salecha@qlogic.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Jesper Dangaard Brouer <hawk@comx.dk>,
Alexander Duyck <alexander.h.duyck@intel.com>,
netdev <netdev@vger.kernel.org>,
Neil Horman <nhorman@tuxdriver.com>,
Ben Hutchings <bhutchings@solarflare.com>
Subject: Re: LRO disable warnings on kernel 2.6.38
Date: Mon, 21 Mar 2011 14:46:48 +0100 [thread overview]
Message-ID: <20110321134647.GA3126@redhat.com> (raw)
In-Reply-To: <20110321123406.GA2376@redhat.com>
On Mon, Mar 21, 2011 at 01:34:06PM +0100, Stanislaw Gruszka wrote:
> On Mon, Mar 21, 2011 at 05:00:31AM -0500, Amit Salecha wrote:
> > > Well, this warning can be ignored since these NIC dont receive packets
> > > to be forwarded in your setup.
> > >
> > > I would say netxen_nic_set_flags() is buggy : It rejects data if other
> > > flag than ETH_FLAG_LRO is set.
> > >
> > > if (data & ~ETH_FLAG_LRO)
> > > return -EINVAL;
> > >
> > > Brought by commit ef2519b1dd39940 (netxen: fail when try to setup
> > > unsupported features) later corrected by commit 97d1935a61b7fe7a65f98f
> > > (Make ethtool_ops::set_flags() return -EINVAL for unsupported flags)
> > >
> > > Since this drivers asserts NETIF_F_HW_VLAN_TX (mirroring
> > > ETH_FLAG_TXVLAN), ethtool_op_get_flags() can return more than
> > > ETH_FLAG_LRO.
> > >
> > > dev_disable_lro() then calls netxen_nic_set_flags() with
> > > ETH_FLAG_TXVLAN
> > > -> -EINVAL, and ETH_FLAG_LRO stay ORed in dev->features -> WARNING
> > >
> > >
> > Thanks Eric.
> >
> > Instead of
> > if (data & ~ETH_FLAG_LRO)
> > return -EINVAL;
> >
> > check should be like this:
> >
> > + if ((ethtool_op_get_flags(netdev) & ~ETH_FLAG_LRO) !=
> > + (data & ~ETH_FLAG_LRO))
> > return -EINVAL;
> >
> > Will provide patch soon.
>
> Yep, that should fix issue in netxen.
>
> I'm afraid some other drivers can have similar problem after
> adding ETH_FLAG_{TX,RX}VLAN. I think we need to distinguish features
> that are configurable at runtime from features that are hardcoded.
> I'm going to look at that.
Other drivers have this bug too. I'm going to prepare patch with similar fix
like Amit proposed, but also for other drivers. Something like below:
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index c1a71bb..38fd0cb 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -141,9 +141,17 @@ u32 ethtool_op_get_flags(struct net_device *dev)
}
EXPORT_SYMBOL(ethtool_op_get_flags);
+bool ethtool_invalid_flags(struct net_device *dev, u32 data, u32 supported)
+{
+ if ((dev->features & ~supported) != (data & ~supported))
+ return true;
+ else
+ return false;
+}
+
int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported)
{
- if (data & ~supported)
+ if (ethtool_invalid_flags(dev, data, supported);
return -EINVAL;
dev->features = ((dev->features & ~flags_dup_features) |
diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c b/drivers/net/vmxnet3/vmxnet3_ethtool.c
index 81254be..7a662f1 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethtool.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethtool.c
@@ -304,8 +304,8 @@ vmxnet3_set_flags(struct net_device *netdev, u32 data)
u8 lro_present = (netdev->features & NETIF_F_LRO) == 0 ? 0 : 1;
unsigned long flags;
- if (data & ~ETH_FLAG_LRO)
- return -EOPNOTSUPP;
+ if (ethtool_invalid_flags(netdev, data, ETH_FLAG_LRO))
+ return -EINVAL;
if (lro_requested ^ lro_present) {
/* toggle the LRO feature*/
next prev parent reply other threads:[~2011-03-21 13:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-18 11:12 LRO disable warnings on kernel 2.6.38 Jesper Dangaard Brouer
2011-03-18 13:05 ` Eric Dumazet
2011-03-18 14:17 ` Ben Hutchings
2011-03-18 14:33 ` Eric Dumazet
2011-03-18 15:15 ` Stephen Hemminger
2011-03-18 19:52 ` David Miller
2011-03-18 19:58 ` Ben Hutchings
2011-03-18 19:59 ` David Miller
2011-03-18 15:40 ` Ben Hutchings
2011-03-18 16:18 ` Alexander Duyck
2011-03-21 9:21 ` Jesper Dangaard Brouer
2011-03-21 9:45 ` Eric Dumazet
2011-03-21 9:53 ` Eric Dumazet
2011-03-21 10:04 ` Jesper Dangaard Brouer
2011-03-21 10:11 ` Eric Dumazet
2011-03-21 10:27 ` Jesper Dangaard Brouer
2011-03-21 10:00 ` Amit Salecha
2011-03-21 12:34 ` Stanislaw Gruszka
2011-03-21 13:46 ` Stanislaw Gruszka [this message]
2011-03-21 13:52 ` Ben Hutchings
2011-03-21 15:10 ` [RFC] net: fix ethtool->set_flags not intended -EINVAL return value Stanislaw Gruszka
2011-03-21 15:15 ` Ben Hutchings
2011-03-22 2:41 ` Jesse Gross
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=20110321134647.GA3126@redhat.com \
--to=sgruszka@redhat.com \
--cc=alexander.h.duyck@intel.com \
--cc=amit.salecha@qlogic.com \
--cc=bhutchings@solarflare.com \
--cc=eric.dumazet@gmail.com \
--cc=hawk@comx.dk \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.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.