Netdev List
 help / color / mirror / Atom feed
* [PATCH net-next 0/2] selftests: forwarding: mirror_vlan: Fixlets
From: Petr Machata @ 2018-05-31 22:37 UTC (permalink / raw)
  To: netdev, linux-kselftest; +Cc: davem, shuah, idosch

This patchset includes two small fixes for the tests that were
introduced in commit 1bb58d2d3cbe ("Merge branch
'Mirroring-tests-involving-VLAN'").

In patch #1, a "tc action trap" is uninstalled after the suite runs,
instead of being installed again.

In patch #2, a test in suite is renamed to differentiate it from another
test of the same name.

Petr Machata (2):
  selftests: forwarding: mirror_vlan: Uninstall trap
  selftests: forwarding: mirror_vlan: Change test description

 tools/testing/selftests/net/forwarding/mirror_vlan.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.4.11

^ permalink raw reply

* Re: [PATCH v2 net] ixgbe: fix parsing of TC actions for HW offload
From: Jeff Kirsher @ 2018-05-31 21:46 UTC (permalink / raw)
  To: Ondřej Hlavatý; +Cc: netdev, Andrew Bowers
In-Reply-To: <20180531212104.23572-1-ohlavaty@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

On Thu, 2018-05-31 at 23:21 +0200, Ondřej Hlavatý wrote:
> The previous code was optimistic, accepting the offload of whole
> action
> chain when there was a single known action (drop/redirect). This
> results
> in offloading a rule which should not be offloaded, because its
> behavior
> cannot be reproduced in the hardware.
> 
> For example:
> 
> $ tc filter add dev eno1 parent ffff: protocol ip \
>     u32 ht 800: order 1 match tcp src 42 FFFF \
>     action mirred egress mirror dev enp1s16 pipe \
>     drop
> 
> The controller is unable to mirror the packet to a VF, but still
> offloads the rule by dropping the packet.
> 
> Change the approach of the function to a pessimistic one, rejecting
> the
> chain when an unknown action is found. This is better suited for
> future
> extensions.
> 
> Note that both recognized actions always return TC_ACT_SHOT,
> therefore
> it is safe to ignore actions behind them.
> 
> Signed-off-by: Ondřej Hlavatý <ohlavaty@redhat.com>

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Note- I am having our validation move to testing with GCC 8.1.1 or
later so that we can catch warnings like Dave found in the future.

Dave- Please go ahead and pick this up.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply

* [PATCH v2 net] ixgbe: fix parsing of TC actions for HW offload
From: Ondřej Hlavatý @ 2018-05-31 21:21 UTC (permalink / raw)
  To: Jeff Kirsher; +Cc: netdev, Andrew Bowers, Ondřej Hlavatý

The previous code was optimistic, accepting the offload of whole action
chain when there was a single known action (drop/redirect). This results
in offloading a rule which should not be offloaded, because its behavior
cannot be reproduced in the hardware.

For example:

$ tc filter add dev eno1 parent ffff: protocol ip \
    u32 ht 800: order 1 match tcp src 42 FFFF \
    action mirred egress mirror dev enp1s16 pipe \
    drop

The controller is unable to mirror the packet to a VF, but still
offloads the rule by dropping the packet.

Change the approach of the function to a pessimistic one, rejecting the
chain when an unknown action is found. This is better suited for future
extensions.

Note that both recognized actions always return TC_ACT_SHOT, therefore
it is safe to ignore actions behind them.

Signed-off-by: Ondřej Hlavatý <ohlavaty@redhat.com>

---

Changes from v1: Fix the introduced warning by rejecting hypothetical
empty action chains as well. Removed Cc's from description.

 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index afadba99f7b8..2ecd55856c50 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9054,7 +9054,6 @@ static int parse_tc_actions(struct ixgbe_adapter *adapter,
 {
 	const struct tc_action *a;
 	LIST_HEAD(actions);
-	int err;
 
 	if (!tcf_exts_has_actions(exts))
 		return -EINVAL;
@@ -9075,11 +9074,11 @@ static int parse_tc_actions(struct ixgbe_adapter *adapter,
 
 			if (!dev)
 				return -EINVAL;
-			err = handle_redirect_action(adapter, dev->ifindex, queue,
-						     action);
-			if (err == 0)
-				return err;
+			return handle_redirect_action(adapter, dev->ifindex,
+						      queue, action);
 		}
+
+		return -EINVAL;
 	}
 
 	return -EINVAL;
-- 
2.17.1

^ permalink raw reply related

* Re: [PATCH] rtnetlink: Add more well known protocol values
From: Stephen Hemminger @ 2018-05-31 21:13 UTC (permalink / raw)
  To: Donald Sharp; +Cc: netdev, dsahern
In-Reply-To: <20180530122732.3688-1-sharpd@cumulusnetworks.com>

On Wed, 30 May 2018 08:27:32 -0400
Donald Sharp <sharpd@cumulusnetworks.com> wrote:

> FRRouting installs routes into the kernel associated with
> the originating protocol.  Add these values to the well
> known values in rtnetlink.h.
> 
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> v2: Fixed whitespace issues
>  include/uapi/linux/rtnetlink.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
> index cabb210c93af..7d8502313c99 100644
> --- a/include/uapi/linux/rtnetlink.h
> +++ b/include/uapi/linux/rtnetlink.h
> @@ -254,6 +254,11 @@ enum {
>  #define RTPROT_DHCP	16      /* DHCP client */
>  #define RTPROT_MROUTED	17      /* Multicast daemon */
>  #define RTPROT_BABEL	42      /* Babel daemon */
> +#define RTPROT_BGP	186     /* BGP Routes */
> +#define RTPROT_ISIS	187     /* ISIS Routes */
> +#define RTPROT_OSPF	188     /* OSPF Routes */
> +#define RTPROT_RIP	189     /* RIP Routes */
> +#define RTPROT_EIGRP	192     /* EIGRP Routes */
>  
>  /* rtm_scope
>  

There is a matching table in iproute2 which should also be updated.
See etc/iproute/rt_protos

There also seems to be some leftover gated garbage there as well...

^ permalink raw reply

* [PATCH] ixgbe: fix broken ipsec Rx with proper cast on spi
From: Shannon Nelson @ 2018-05-31 21:12 UTC (permalink / raw)
  To: intel-wired-lan, jeffrey.t.kirsher; +Cc: netdev

Fix up a cast problem introduced by a sparse cleanup patch.  This fixes
a problem where the encrypted packets were not recognized on Rx and
subsequently dropped.

Fixes: 9cfbfa701b55 ("ixgbe: cleanup sparse warnings")
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index e1c9762..344a1f2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -663,7 +663,7 @@ static int ixgbe_ipsec_add_sa(struct xfrm_state *xs)
 
 		/* hash the new entry for faster search in Rx path */
 		hash_add_rcu(ipsec->rx_sa_list, &ipsec->rx_tbl[sa_idx].hlist,
-			     (__force u64)rsa.xs->id.spi);
+			     (__force u32)rsa.xs->id.spi);
 	} else {
 		struct tx_sa tsa;
 
-- 
2.7.4

^ permalink raw reply related

* Re: [PATCH net-next v12 2/5] netvsc: refactor notifier/event handling code to use the failover framework
From: Siwei Liu @ 2018-05-31 20:41 UTC (permalink / raw)
  To: Michael S. Tsirkin, venu.busireddy
  Cc: Stephen Hemminger, Sridhar Samudrala, David Miller, Netdev,
	virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
	Jakub Kicinski, Jason Wang, Jiri Pirko, aaron.f.brown,
	anjali.singhai
In-Reply-To: <20180531212356-mutt-send-email-mst@kernel.org>

On Thu, May 31, 2018 at 11:35 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, May 30, 2018 at 10:06:35PM -0400, Stephen Hemminger wrote:
>> On Thu, 24 May 2018 09:55:14 -0700
>> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>>
>> > Use the registration/notification framework supported by the generic
>> > failover infrastructure.
>> >
>> > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>
>> Why was this merged? It was never signed off by any of the netvsc maintainers,
>> and there were still issues unresolved.
>>
>> There are also namespaces issues I am fixing and this breaks them.
>> Will start my patch set with a revert for this. Sorry
>
> As long as you finish the patch set with re-integrating with failover,
> that's fine IMHO.
>
> I suspect it's easier to add the code to failover though - namespace
> things likely affect virtio as well. Lookup by ID would be an optional
> feature for virtio, but probably a useful one - I won't ask you
I would think for production uses this is a required feature and
should be enabled by default.

Venu (cc'ed) is working on the group ID stuff currently for pairing
virtio and passthrough devices. Would appreciate feedback on the group
ID proposal on virtio-dev.

-Siwei

> to add it to virtio but it could be a mode in failover
> that virtio will activate down the road. And reducing the number of
> times we look cards up based on ID can only be a good thing.
>
> --
> MST

^ permalink raw reply

* Re: [PATCH net-next v2 0/2] net: phy: improve PHY suspend/resume
From: Heiner Kallweit @ 2018-05-31 20:28 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20180531183040.GA7378@lunn.ch>

On 31.05.2018 20:30, Andrew Lunn wrote:
>> By the way: The problem is related to an experimental patch series for
>> splitting r8169/r8168 drivers and switching r8168 to phylib.
>> Therefore the change to r8168.c won't apply to existing kernel code.
> 
> Hi Heiner
> 
> I still think you are trying to fix the wrong problem.
> 
> Lets take a look at these patches, particularly your code for
> interfacing to phylib.
> 
> Thanks
> 	Andrew
> 
Hi Andrew,

I skip some intermediate patches and in the following just list the
patch adding basic phylib support. The code shouldn't be a big
surprise ..

The network chip integrates subsystems like MAC and PHY, and the
driver takes care that in suspend / resume the different components
are suspended / resumed in the right order.
This includes actions like speeding down the PHY from 1GB to
preferably 10MB (to save energy) in case WoL is configured.

It causes issues like the one I face now, if subsystems like the
MDIO bus suddenly trigger own suspend / resume actions w/o knowing
about status of the other chip subsystems.
Main issue I think is that we loose control over what is done in
which order.

To provide just one example of typical issues:
Configuring the different WoL options isn't handled by writing to
the PHY registers but by writing to chip / MAC registers.
Therefore phy_suspend() isn't able to figure out whether WoL is
enabled or not. Only the parent has the full picture.

To consider dependencies and ensure the right order of suspend /
resume actions I think a parent should be allowed to request that
it takes care of PM of its subsystems.

Regards,
Heiner

---
 drivers/net/ethernet/realtek/Kconfig |   1 +
 drivers/net/ethernet/realtek/r8168.c | 140 +++++++++++++++++++++------
 drivers/net/ethernet/realtek/r8169.h |   2 +
 3 files changed, 116 insertions(+), 27 deletions(-)

diff --git a/drivers/net/ethernet/realtek/Kconfig b/drivers/net/ethernet/realtek/Kconfig
index 404e1f288..f1e9e8cc2 100644
--- a/drivers/net/ethernet/realtek/Kconfig
+++ b/drivers/net/ethernet/realtek/Kconfig
@@ -105,6 +105,7 @@ config R8168
 	select R8169_COMMON
 	select FW_LOADER
 	select CRC32
+	select PHYLIB
 	select MII
 	help
 	  Say Y here if you have a Realtek 8168 PCI Gigabit Ethernet adapter.
diff --git a/drivers/net/ethernet/realtek/r8168.c b/drivers/net/ethernet/realtek/r8168.c
index 546115344..473a147ec 100644
--- a/drivers/net/ethernet/realtek/r8168.c
+++ b/drivers/net/ethernet/realtek/r8168.c
@@ -16,6 +16,7 @@
 #include <linux/delay.h>
 #include <linux/ethtool.h>
 #include <linux/mii.h>
+#include <linux/phy.h>
 #include <linux/if_vlan.h>
 #include <linux/in.h>
 #include <linux/ip.h>
@@ -868,25 +869,6 @@ static void rtl_link_chg_patch(struct rtl8169_private *tp)
 	}
 }
 
-static void rtl8169_check_link_status(struct net_device *dev,
-				      struct rtl8169_private *tp)
-{
-	struct device *d = tp_to_dev(tp);
-
-	if (rtl8169_xmii_link_ok(tp)) {
-		rtl_link_chg_patch(tp);
-		/* This is to cancel a scheduled suspend if there's one. */
-		pm_request_resume(d);
-		netif_carrier_on(dev);
-		if (net_ratelimit())
-			netif_info(tp, ifup, dev, "link up\n");
-	} else {
-		netif_carrier_off(dev);
-		netif_info(tp, ifdown, dev, "link down\n");
-		pm_runtime_idle(d);
-	}
-}
-
 #define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
 
 static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
@@ -4444,8 +4426,8 @@ static void rtl_reset_work(struct rtl8169_private *tp)
 
 	napi_enable(&tp->napi);
 	rtl8169_hw_start(tp);
+	phy_start(dev->phydev);
 	netif_wake_queue(dev);
-	rtl8169_check_link_status(dev, tp);
 }
 
 static bool rtl_test_hw_pad_bug(struct rtl8169_private *tp, struct sk_buff *skb)
@@ -4615,7 +4597,7 @@ static void rtl_slow_event_work(struct rtl8169_private *tp)
 		rtl8169_pcierr_interrupt(dev);
 
 	if (status & LinkChg)
-		rtl8169_check_link_status(dev, tp);
+		phy_mac_interrupt(dev->phydev);
 
 	rtl_irq_enable_all(tp);
 }
@@ -4658,6 +4640,8 @@ static void rtl8169_down(struct net_device *dev)
 {
 	struct rtl8169_private *tp = netdev_priv(dev);
 
+	phy_stop(dev->phydev);
+
 	del_timer_sync(&tp->timer);
 
 	napi_disable(&tp->napi);
@@ -4762,14 +4746,13 @@ static int rtl_open(struct net_device *dev)
 	if (!rtl8169_init_counter_offsets(tp))
 		netif_warn(tp, hw, dev, "counter reset/update failed\n");
 
+	phy_start(dev->phydev);
 	netif_start_queue(dev);
 
 	rtl_unlock_work(tp);
 
 	tp->saved_wolopts = 0;
 	pm_runtime_put_sync(&pdev->dev);
-
-	rtl8169_check_link_status(dev, tp);
 out:
 	return retval;
 
@@ -4796,6 +4779,7 @@ static void rtl8169_net_suspend(struct net_device *dev)
 	if (!netif_running(dev))
 		return;
 
+	phy_stop(dev->phydev);
 	netif_device_detach(dev);
 	netif_stop_queue(dev);
 
@@ -4827,6 +4811,8 @@ static void __rtl8169_resume(struct net_device *dev)
 
 	rtl_pll_power_up(tp);
 
+	phy_start(tp->dev->phydev);
+
 	rtl_lock_work(tp);
 	napi_enable(&tp->napi);
 	set_bit(RTL_FLAG_TASK_ENABLED, tp->wk.flags);
@@ -4979,6 +4965,8 @@ static void rtl_remove_one(struct pci_dev *pdev)
 	netif_napi_del(&tp->napi);
 
 	unregister_netdev(dev);
+	phy_disconnect(dev->phydev);
+	mdiobus_unregister(tp->mii_bus);
 
 	rtl_release_firmware(tp);
 
@@ -5041,6 +5029,92 @@ DECLARE_RTL_COND(rtl_rxtx_empty_cond)
 	return (RTL_R8(tp, MCU) & RXTX_EMPTY) == RXTX_EMPTY;
 }
 
+static int r8168_mdio_read_reg(struct mii_bus *mii_bus, int phyaddr, int phyreg)
+{
+	struct rtl8169_private *tp = mii_bus->priv;
+
+	return tp->mdio_ops.read(tp, phyreg);
+}
+
+static int r8168_mdio_write_reg(struct mii_bus *mii_bus, int phyaddr,
+				int phyreg, u16 val)
+{
+	struct rtl8169_private *tp = mii_bus->priv;
+
+	tp->mdio_ops.write(tp, phyreg, val);
+
+	return 0;
+}
+
+static int r8168_mdio_register(struct rtl8169_private *tp)
+{
+	struct pci_dev *pdev = tp->pci_dev;
+	struct mii_bus *new_bus;
+	int ret;
+
+	new_bus = devm_mdiobus_alloc(&pdev->dev);
+	if (!new_bus)
+		return -ENOMEM;
+
+	new_bus->name = "r8168";
+	new_bus->priv = tp;
+	new_bus->phy_mask = ~1;
+	new_bus->parent = &pdev->dev;
+	new_bus->irq[0] = PHY_IGNORE_INTERRUPT;
+	snprintf(new_bus->id, MII_BUS_ID_SIZE, "r8168-%x",
+		 PCI_DEVID(pdev->bus->number, pdev->devfn));
+
+	new_bus->read = r8168_mdio_read_reg;
+	new_bus->write = r8168_mdio_write_reg;
+
+	ret = mdiobus_register(new_bus);
+	if (!ret)
+		tp->mii_bus = new_bus;
+
+	return ret;
+}
+
+static void r8168_phylink_handler(struct net_device *ndev)
+{
+	struct rtl8169_private *tp = netdev_priv(ndev);
+
+	if (netif_carrier_ok(ndev)) {
+		rtl_link_chg_patch(tp);
+		pm_request_resume(&tp->pci_dev->dev);
+	} else {
+		pm_runtime_idle(&tp->pci_dev->dev);
+	}
+
+	if (net_ratelimit())
+		phy_print_status(ndev->phydev);
+}
+
+static int r8168_phy_connect(struct rtl8169_private *tp)
+{
+	struct phy_device *phydev;
+	phy_interface_t phy_mode;
+	int ret;
+
+	phy_mode = tp->mii.supports_gmii ? PHY_INTERFACE_MODE_GMII :
+		   PHY_INTERFACE_MODE_MII;
+
+	phydev = phy_find_first(tp->mii_bus);
+	if (!phydev)
+		return -ENODEV;
+
+	if (!tp->mii.supports_gmii && phydev->supported & PHY_1000BT_FEATURES) {
+		netif_info(tp, probe, tp->dev, "Restrict PHY to 100Mbit because MAC doesn't support 1GBit\n");
+		phy_set_max_speed(phydev, SPEED_100);
+	}
+
+	ret = phy_connect_direct(tp->dev, phydev, r8168_phylink_handler,
+				 phy_mode);
+	if (!ret)
+		phy_attached_info(phydev);
+
+	return ret;
+}
+
 static void rtl_hw_init_8168g(struct rtl8169_private *tp)
 {
 	u32 data;
@@ -5287,10 +5361,18 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 	pci_set_drvdata(pdev, dev);
 
-	rc = register_netdev(dev);
-	if (rc < 0)
+	rc = r8168_mdio_register(tp);
+	if (rc)
 		return rc;
 
+	rc = r8168_phy_connect(tp);
+	if (rc)
+		goto err_mdio_unregister;
+
+	rc = register_netdev(dev);
+	if (rc)
+		goto err_phy_disconnect;
+
 	netif_info(tp, probe, dev, "%s, %pM, XID %08x, IRQ %d\n",
 		   rtl_chip_infos[chipset].name, dev->dev_addr,
 		   (u32)(RTL_R32(tp, TxConfig) & 0xfcf0f8ff),
@@ -5303,12 +5385,16 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (r8168_check_dash(tp))
 		rtl8168_driver_start(tp);
 
-	netif_carrier_off(dev);
-
 	if (pci_dev_run_wake(pdev))
 		pm_runtime_put_sync(&pdev->dev);
 
 	return 0;
+
+err_phy_disconnect:
+	phy_disconnect(dev->phydev);
+err_mdio_unregister:
+	mdiobus_unregister(tp->mii_bus);
+	return rc;
 }
 
 static struct pci_driver rtl8168_pci_driver = {
diff --git a/drivers/net/ethernet/realtek/r8169.h b/drivers/net/ethernet/realtek/r8169.h
index 355bbcd0f..2f18e5dee 100644
--- a/drivers/net/ethernet/realtek/r8169.h
+++ b/drivers/net/ethernet/realtek/r8169.h
@@ -14,6 +14,7 @@
 #include <linux/delay.h>
 #include <linux/ethtool.h>
 #include <linux/mii.h>
+#include <linux/phy.h>
 #include <linux/if_vlan.h>
 #include <linux/in.h>
 #include <linux/ip.h>
@@ -475,6 +476,7 @@ struct rtl8169_private {
 	} wk;
 
 	struct mii_if_info mii;
+	struct mii_bus *mii_bus;
 	dma_addr_t counters_phys_addr;
 	struct rtl8169_counters *counters;
 	struct rtl8169_tc_offsets tc_offset;
-- 
2.17.0

^ permalink raw reply related

* [net PATCH] net-sysfs: Fix memory leak in XPS configuration
From: Alexander Duyck @ 2018-05-31 19:59 UTC (permalink / raw)
  To: netdev, davem

This patch reorders the error cases in showing the XPS configuration so
that we hold off on memory allocation until after we have verified that we
can support XPS on a given ring.

Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes")
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 net/core/net-sysfs.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index c476f07..bb7e80f 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -1214,9 +1214,6 @@ static ssize_t xps_cpus_show(struct netdev_queue *queue,
 	cpumask_var_t mask;
 	unsigned long index;
 
-	if (!zalloc_cpumask_var(&mask, GFP_KERNEL))
-		return -ENOMEM;
-
 	index = get_netdev_queue_index(queue);
 
 	if (dev->num_tc) {
@@ -1226,6 +1223,9 @@ static ssize_t xps_cpus_show(struct netdev_queue *queue,
 			return -EINVAL;
 	}
 
+	if (!zalloc_cpumask_var(&mask, GFP_KERNEL))
+		return -ENOMEM;
+
 	rcu_read_lock();
 	dev_maps = rcu_dereference(dev->xps_maps);
 	if (dev_maps) {

^ permalink raw reply related

* Re: [net] ixgbe: fix parsing of TC actions for HW offload
From: Ondřej Hlavatý @ 2018-05-31 20:01 UTC (permalink / raw)
  To: David Miller
  Cc: jeffrey.t.kirsher, netdev, nhorman, sassmann, jogreene, jhs, jiri
In-Reply-To: <20180531.154106.1949427114118876175.davem@davemloft.net>

On 31.05., David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Wed, 30 May 2018 11:01:34 -0700
> 
> > From: Ondřej Hlavatý <ohlavaty@redhat.com>
> > 
> > The previous code was optimistic, accepting the offload of whole action
> > chain when there was a single known action (drop/redirect). This results
> > in offloading a rule which should not be offloaded, because its behavior
> > cannot be reproduced in the hardware.
> > 
> 
> This introduces a new warning with gcc-8.1.1 on Fedora 28.

Indeed. Sorry for noticing that it was introduced by my patch. The
issue is pretty obvious - empty action chain will not select a queue. As
the Flow Director rules always need to explicitly set a queue index when
they match (as far as I'm concerned), the correct solution should be to
just reject empty chains for offload as well. I will prepare v2 soon.

Ondřej

^ permalink raw reply

* Re: [PATCH net] net/ncsi: Fix array size in dumpit handler
From: David Miller @ 2018-05-31 19:59 UTC (permalink / raw)
  To: sam; +Cc: netdev, linux-kernel, openbmc
In-Reply-To: <20180531041004.20172-1-sam@mendozajonas.com>

From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Date: Thu, 31 May 2018 14:10:04 +1000

> With CONFIG_CC_STACKPROTECTOR enabled the kernel panics as below when
> parsing a NCSI_CMD_PKG_INFO command:
 ...
> This turns out to be because the attrs array in ncsi_pkg_info_all_nl()
> is initialised to a length of NCSI_ATTR_MAX which is the maximum
> attribute number, not the number of attributes.
> 
> Fixes: 955dc68cb9b2 ("net/ncsi: Add generic netlink family")
> Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next] net: dsa: mv88e6xxx: Be explicit about DT or pdata
From: David Miller @ 2018-05-31 19:54 UTC (permalink / raw)
  To: andrew; +Cc: vivien.didelot, f.fainelli, dan.carpenter, netdev
In-Reply-To: <1527718542-22658-1-git-send-email-andrew@lunn.ch>

From: Andrew Lunn <andrew@lunn.ch>
Date: Thu, 31 May 2018 00:15:42 +0200

> Make it explicit that either device tree is used or platform data.  If
> neither is available, abort the probe.
> 
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Fixes: 877b7cb0b6f2 ("net: dsa: mv88e6xxx: Add minimal platform_data support")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] net: ti: cpsw: include gpio/consumer.h
From: David Miller @ 2018-05-31 19:47 UTC (permalink / raw)
  To: arnd
  Cc: grygorii.strashko, linux-gpio, f.fainelli, ivan.khoronzhuk,
	j-keerthy, linux-omap, netdev, linux-kernel
In-Reply-To: <20180530215212.1151415-1-arnd@arndb.de>

From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 30 May 2018 23:51:54 +0200

> On platforms that don't always enable CONFIG_GPIOLIB, we run into
> a build failure:
> 
> drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_probe':
> drivers/net/ethernet/ti/cpsw.c:3006:9: error: implicit declaration of function 'devm_gpiod_get_array_optional' [-Werror=implicit-function-declaration]
>   mode = devm_gpiod_get_array_optional(&pdev->dev, "mode", GPIOD_OUT_LOW);
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/ethernet/ti/cpsw.c:3006:59: error: 'GPIOD_OUT_LOW' undeclared (first use in this function); did you mean 'GPIOF_INIT_LOW'?
>   mode = devm_gpiod_get_array_optional(&pdev->dev, "mode", GPIOD_OUT_LOW);
> 
> Since we cannot rely on this to be visible from gpio.h, we have to include
> gpio/consumer.h directly.
> 
> Fixes: 2652113ff043 ("net: ethernet: ti: Allow most drivers with COMPILE_TEST")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied, thanks Arnd.

^ permalink raw reply

* Re: [net] ixgbe: fix parsing of TC actions for HW offload
From: David Miller @ 2018-05-31 19:41 UTC (permalink / raw)
  To: jeffrey.t.kirsher
  Cc: ohlavaty, netdev, nhorman, sassmann, jogreene, jhs, jiri
In-Reply-To: <20180530180134.5497-1-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 30 May 2018 11:01:34 -0700

> From: Ondřej Hlavatý <ohlavaty@redhat.com>
> 
> The previous code was optimistic, accepting the offload of whole action
> chain when there was a single known action (drop/redirect). This results
> in offloading a rule which should not be offloaded, because its behavior
> cannot be reproduced in the hardware.
> 
> For example:
> 
> $ tc filter add dev eno1 parent ffff: protocol ip \
>     u32 ht 800: order 1 match tcp src 42 FFFF \
>     action mirred egress mirror dev enp1s16 pipe \
>     drop
> 
> The controller is unable to mirror the packet to a VF, but still
> offloads the rule by dropping the packet.
> 
> Change the approach of the function to a pessimistic one, rejecting the
> chain when an unknown action is found. This is better suited for future
> extensions.
> 
> Note that both recognized actions always return TC_ACT_SHOT, therefore
> it is safe to ignore actions behind them.
> 
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Ondřej Hlavatý <ohlavaty@redhat.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

This introduces a new warning with gcc-8.1.1 on Fedora 28.

drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function ‘ixgbe_configure_clsu32’:
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:9311:8: warning: ‘queue’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  err = ixgbe_fdir_write_perfect_filter_82599(hw, &input->filter,
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           input->sw_idx, queue);
           ~~~~~~~~~~~~~~~~~~~~~

^ permalink raw reply

* Re: [PATCH V2 mlx5-next 0/2] Mellanox, mlx5 new device events
From: David Miller @ 2018-05-31 19:36 UTC (permalink / raw)
  To: saeedm; +Cc: netdev, linux-rdma, leonro, jgg
In-Reply-To: <20180530175950.9488-1-saeedm@mellanox.com>

From: Saeed Mahameed <saeedm@mellanox.com>
Date: Wed, 30 May 2018 10:59:48 -0700

> The following series is for mlx5-next tree [1], it adds the support of two
> new device events, from Ilan Tayari:
> 
> 1. High temperature warnings.
> 2. FPGA QP error event.
> 
> In case of no objection this series will be applied to mlx5-next tree
> and will be sent later as a pull request to both rdma and net trees.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=mlx5-next
> 
> v1->v2:
>   - improve commit message of the FPGA QP error event patch.

Series applied, thanks.

^ permalink raw reply

* [PATCH iproute2] configure: require libmnl
From: Stephen Hemminger @ 2018-05-31 19:32 UTC (permalink / raw)
  To: netdev; +Cc: Stephen Hemminger

Several users of BPF and other features are trying to build without
libmnl, then complaining that features don't work.  The time has
come to require libmnl to build iproute2.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 configure        | 20 +++++++++++---------
 lib/libnetlink.c | 10 ----------
 2 files changed, 11 insertions(+), 19 deletions(-)

diff --git a/configure b/configure
index 5ef5cd4cf9cd..209d78b6bf19 100755
--- a/configure
+++ b/configure
@@ -281,16 +281,18 @@ check_selinux()
 
 check_mnl()
 {
-	if ${PKG_CONFIG} libmnl --exists
-	then
-		echo "HAVE_MNL:=y" >>$CONFIG
-		echo "yes"
+    if ${PKG_CONFIG} libmnl --exists
+    then
+	echo "HAVE_MNL:=y" >>$CONFIG
+	echo "yes"
 
-		echo 'CFLAGS += -DHAVE_LIBMNL' `${PKG_CONFIG} libmnl --cflags` >>$CONFIG
-		echo 'LDLIBS +=' `${PKG_CONFIG} libmnl --libs` >> $CONFIG
-	else
-		echo "no"
-	fi
+	echo 'CFLAGS += -DHAVE_LIBMNL' `${PKG_CONFIG} libmnl --cflags` >>$CONFIG
+	echo 'LDLIBS +=' `${PKG_CONFIG} libmnl --libs` >> $CONFIG
+    else
+	echo "no"
+	echo "libmnl is required. please install libmnl-dev or libmnl-devel" 1>&2
+	exit 1
+    fi
 }
 
 check_berkeley_db()
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 928de1dd16d8..ab8ea85d5dd9 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -35,7 +35,6 @@
 
 int rcvbuf = 1024 * 1024;
 
-#ifdef HAVE_LIBMNL
 #include <libmnl/libmnl.h>
 
 static const enum mnl_attr_data_type extack_policy[NLMSGERR_ATTR_MAX + 1] = {
@@ -116,15 +115,6 @@ int nl_dump_ext_ack(const struct nlmsghdr *nlh, nl_ext_ack_fn_t errfn)
 
 	return 0;
 }
-#else
-#warning "libmnl required for error support"
-
-/* No extended error ack without libmnl */
-int nl_dump_ext_ack(const struct nlmsghdr *nlh, nl_ext_ack_fn_t errfn)
-{
-	return 0;
-}
-#endif
 
 void rtnl_close(struct rtnl_handle *rth)
 {
-- 
2.17.0

^ permalink raw reply related

* Re: pull-request: wireless-drivers 2018-05-30
From: David Miller @ 2018-05-31 19:28 UTC (permalink / raw)
  To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
  Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87vab52po0.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>

From: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Date: Wed, 30 May 2018 17:17:51 +0300

> I now this is late but hopefully this pull request can make it to net
> tree and to the final 4.17 release still. But if not, please let me know
> and I'll pull this to wireless-drivers-next instead.
> 
> More info in the signed tag below, and please let me know if there are
> any problems.

Pulled, thanks Kalle.

^ permalink raw reply

* Re: [PATCH] rtnetlink: Add more well known protocol values
From: David Miller @ 2018-05-31 19:25 UTC (permalink / raw)
  To: sharpd; +Cc: netdev, dsahern
In-Reply-To: <20180530122732.3688-1-sharpd@cumulusnetworks.com>

From: Donald Sharp <sharpd@cumulusnetworks.com>
Date: Wed, 30 May 2018 08:27:32 -0400

> FRRouting installs routes into the kernel associated with
> the originating protocol.  Add these values to the well
> known values in rtnetlink.h.
> 
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Applied, thanks Donald.

^ permalink raw reply

* Re: [PATCH net-next] cxgb4: Add FORCE_PAUSE bit to 32 bit port caps
From: David Miller @ 2018-05-31 19:23 UTC (permalink / raw)
  To: ganeshgr; +Cc: netdev, nirranjan, indranil, santosh, leedom
In-Reply-To: <1527680750-12636-1-git-send-email-ganeshgr@chelsio.com>

From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 30 May 2018 17:15:50 +0530

> Add FORCE_PAUSE bit to force local pause settings instead
> of using auto negotiated values.
> 
> Signed-off-by: Santosh Rastapur <santosh@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>

Applied, thank you.

^ permalink raw reply

* Re: [PATCH net] cls_flower: Fix incorrect idr release when failing to modify rule
From: David Miller @ 2018-05-31 19:19 UTC (permalink / raw)
  To: paulb
  Cc: jiri, xiyou.wangcong, jhs, netdev, kliteyn, roid, shahark, markb,
	ogerlitz
In-Reply-To: <1527668955-28752-1-git-send-email-paulb@mellanox.com>

From: Paul Blakey <paulb@mellanox.com>
Date: Wed, 30 May 2018 11:29:15 +0300

> When we fail to modify a rule, we incorrectly release the idr handle
> of the unmodified old rule.
> 
> Fix that by checking if we need to release it.
> 
> Fixes: fe2502e49b58 ("net_sched: remove cls_flower idr on failure")
> Reported-by: Vlad Buslov <vladbu@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Paul Blakey <paulb@mellanox.com>

Applied and queued up for -stable.

^ permalink raw reply

* Re: [PATCH net-next] netfilter: nf_tables: check msg_type before nft_trans_set(trans)
From: Florian Westphal @ 2018-05-31 19:07 UTC (permalink / raw)
  To: Alexey Kodanev
  Cc: netfilter-devel, Pablo Neira Ayuso, Jozsef Kadlecsik,
	Florian Westphal, coreteam, netdev
In-Reply-To: <1527785613-32005-1-git-send-email-alexey.kodanev@oracle.com>

Alexey Kodanev <alexey.kodanev@oracle.com> wrote:
> The patch moves the "trans->msg_type == NFT_MSG_NEWSET" check before
> using nft_trans_set(trans). Otherwise we can get out of bounds read.

Indeed, thanks for fixining this.

Acked-by: Florian Westphal <fw@strlen.de>

^ permalink raw reply

* Re: [PATCH net-next 0/2] cls_flower: Various fixes
From: David Miller @ 2018-05-31 18:36 UTC (permalink / raw)
  To: paulb
  Cc: jiri, xiyou.wangcong, jhs, netdev, kliteyn, roid, shahark, markb,
	ogerlitz
In-Reply-To: <1527668258-27174-1-git-send-email-paulb@mellanox.com>

From: Paul Blakey <paulb@mellanox.com>
Date: Wed, 30 May 2018 11:17:36 +0300

> Two of the fixes are for my multiple mask patch

This series doesn't apply cleanly to net-next.

Please respin.

^ permalink raw reply

* Re: [PATCH net-next v12 2/5] netvsc: refactor notifier/event handling code to use the failover framework
From: Michael S. Tsirkin @ 2018-05-31 18:35 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Sridhar Samudrala, davem, netdev, virtualization, virtio-dev,
	jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
	loseweigh, jiri, aaron.f.brown, anjali.singhai
In-Reply-To: <20180530220635.206ee6d7@shemminger-XPS-13-9360>

On Wed, May 30, 2018 at 10:06:35PM -0400, Stephen Hemminger wrote:
> On Thu, 24 May 2018 09:55:14 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
> 
> > Use the registration/notification framework supported by the generic
> > failover infrastructure.
> > 
> > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> 
> Why was this merged? It was never signed off by any of the netvsc maintainers,
> and there were still issues unresolved.
> 
> There are also namespaces issues I am fixing and this breaks them.
> Will start my patch set with a revert for this. Sorry

As long as you finish the patch set with re-integrating with failover,
that's fine IMHO.

I suspect it's easier to add the code to failover though - namespace
things likely affect virtio as well. Lookup by ID would be an optional
feature for virtio, but probably a useful one - I won't ask you
to add it to virtio but it could be a mode in failover
that virtio will activate down the road. And reducing the number of
times we look cards up based on ID can only be a good thing.

-- 
MST

^ permalink raw reply

* Re: [PATCH net-next v2 0/2] net: phy: improve PHY suspend/resume
From: Andrew Lunn @ 2018-05-31 18:30 UTC (permalink / raw)
  To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <1d79c2ae-6f63-694f-6c63-6369c854de69@gmail.com>

> By the way: The problem is related to an experimental patch series for
> splitting r8169/r8168 drivers and switching r8168 to phylib.
> Therefore the change to r8168.c won't apply to existing kernel code.

Hi Heiner

I still think you are trying to fix the wrong problem.

Lets take a look at these patches, particularly your code for
interfacing to phylib.

Thanks
	Andrew

^ permalink raw reply

* Re: [PATCH net] net/sonic: Use dma_mapping_error()
From: David Miller @ 2018-05-31 18:18 UTC (permalink / raw)
  To: fthain; +Cc: tsbogend, netdev, linux-kernel
In-Reply-To: <cba8175deaf9d631ae000088aea1ccf1c444909b.1527649393.git.fthain@telegraphics.com.au>

From: Finn Thain <fthain@telegraphics.com.au>
Date: Wed, 30 May 2018 13:03:51 +1000

> With CONFIG_DMA_API_DEBUG=y, calling sonic_open() produces the
> message, "DMA-API: device driver failed to check map error".
> Add the missing dma_mapping_error() call.
> 
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next v4 0/8] net: bridge: Notify about bridge VLANs
From: David Miller @ 2018-05-31 18:14 UTC (permalink / raw)
  To: petrm
  Cc: netdev, devel, bridge, jiri, idosch, razvan.stefanescu, gregkh,
	stephen, andrew, vivien.didelot, f.fainelli, nikolay,
	dan.carpenter
In-Reply-To: <cover.1527641426.git.petrm@mellanox.com>

From: Petr Machata <petrm@mellanox.com>
Date: Wed, 30 May 2018 02:55:34 +0200

> In commit 946a11e7408e ("mlxsw: spectrum_span: Allow bridge for gretap
> mirror"), mlxsw got support for offloading mirror-to-gretap such that
> the underlay packet path involves a bridge. In that case, the offload is
> also influenced by PVID setting of said bridge. However, changes to VLAN
> configuration of the bridge itself do not generate switchdev
> notifications, so there's no mechanism to prod mlxsw to update the
> offload when these settings change.
> 
> In this patchset, the problem is resolved by distributing the switchdev
> notification SWITCHDEV_OBJ_ID_PORT_VLAN also for configuration changes
> on bridge VLANs. Since stacked devices distribute the notification to
> lower devices, such event eventually reaches the driver, which can
> determine whether it's a bridge or port VLAN by inspecting orig_dev.
> 
> To keep things consistent, the newly-distributed notifications observe
> the same protocol as the existing ones: dual prepare/commit, with
> -EOPNOTSUPP indicating lack of support, even though there's currently
> nothing to prepare for and nothing to support. Correspondingly, all
> switchdev drivers have been updated to return -EOPNOTSUPP for bridge
> VLAN notifications.
> 
> In patches #1 and #2, the code base is changed to support the following
> additions: functions br_switchdev_port_vlan_add() and
> br_switchdev_port_vlan_del() are introduced to simplify sending
> notifications; and br_vlan_add_existing() is introduced to later make it
> simpler to add error-handling code for the case of configuring a
> preexisting VLAN on bridge CPU port.
> 
> In patches #3-#6, respectively for mlxsw, rocker, DSA and DPAA2 ethsw,
> the new notifications (which are not enabled yet) are ignored to
> maintain the current behavior.
> 
> In patch #7, the notification is actually enabled.
> 
> In patch #8, mlxsw is changed to update offloads of mirror-to-gre also
> for bridge-related notifications.
 ...

Series applied, thanks.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox