netdev - [PATCH 0/6] bonding: only advertise LRO if underlying hardware can LRO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1439488980-44738-1-git-send-email-jarod@redhat.com>
Date:	Thu, 13 Aug 2015 14:02:54 -0400
From:	Jarod Wilson <jarod@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	Jarod Wilson <jarod@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Ariel Elior <ariel.elior@...gic.com>,
	Manish Chopra <manish.chopra@...gic.com>,
	Rajesh Borundia <rajesh.borundia@...gic.com>,
	Shahed Shaikh <shahed.shaikh@...gic.com>,
	Sony Chacko <sony.chacko@...gic.com>,
	Dept-GELinuxNICDev@...gic.com, Jiri Pirko <jiri@...nulli.us>,
	Jon Mason <jdmason@...zu.us>,
	Scott Feldman <sfeldma@...il.com>,
	Tom Herbert <therbert@...gle.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org
Subject: [PATCH 0/6] bonding: only advertise LRO if underlying hardware can LRO

At present, you can create a bond, containing only underlying slaves that do
not support LRO, and the bond will happily claim to support LRO, and allow
LRO to be toggled on and off by ethtool. While things actually do function
fine in the scenario, and this is merely cosmetic, its a bit misleading to
users, and its something we can fix.

If we add NETIF_F_LRO to the NETIF_F_ONE_FOR_ALL flags in
netdev_features.h, then netdev_features_increment() will only enable LRO
if 1) its listed in the device's feature mask and 2) if there's actually a
slave present that supports the feature.

However, the bnx2x, ixgbe, netxen, qlcnic and s2io drivers all fail to report
support for LRO in their vlan_features, which requires some minor fixups to
these drivers to keep LRO working in cases where it should have been before
this set. The mellanox mlx5 and cavium liquidio drivers already properly set
the LRO flag in their vlan_features.

Note: I've only tested explicitly with bnx2x, as well as some non-LRO hw,
to confirm that:

1) if all slaves support LRO, the bond enables LRO
2) if some slaves support LRO, the bond enables LRO
3) if no slaves support LRO, the bond disables LRO

This set was generated against net-next master, it applies to 4.2.0-rc6 with
a bit of fuzz.

Jarod Wilson (6):
  net/bonding: enable LRO if one device supports it
  ethernet/bnx2x: advertise LRO support in vlan_features
  ethernet/ixgbe: advertise LRO support in vlan_features
  ethernet/netxen: advertise LRO support in vlan_features
  ethernet/qlcnic: advertise LRO support in vlan_features
  ethernet/s2io: advertise what hw supports in vlan_features

 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c     | 3 ++-
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c        | 4 +++-
 drivers/net/ethernet/neterion/s2io.c                 | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 4 +++-
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c     | 4 +++-
 include/linux/netdev_features.h                      | 3 ++-
 6 files changed, 14 insertions(+), 5 deletions(-)

CC: "David S. Miller" <davem@...emloft.net>
CC: Ariel Elior <ariel.elior@...gic.com>
CC: Manish Chopra <manish.chopra@...gic.com>
CC: Rajesh Borundia <rajesh.borundia@...gic.com>
CC: Shahed Shaikh <shahed.shaikh@...gic.com>
CC: Sony Chacko <sony.chacko@...gic.com>
CC: Dept-GELinuxNICDev@...gic.com
CC: Jiri Pirko <jiri@...nulli.us>
CC: Jon Mason <jdmason@...zu.us>
CC: Scott Feldman <sfeldma@...il.com>
CC: Tom Herbert <therbert@...gle.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
CC: intel-wired-lan@...ts.osuosl.org
CC: netdev@...r.kernel.org
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html