* Re: [PATCH 2/2 net-next] mlxsw: spectrum: Add missing error code on allocation failure
From: Yotam Gigi @ 2017-10-03 10:56 UTC (permalink / raw)
To: Dan Carpenter, Jiri Pirko; +Cc: Ido Schimmel, netdev, kernel-janitors
In-Reply-To: <20171003105340.llwk5oajgrohbksu@mwanda>
On 10/03/2017 01:53 PM, Dan Carpenter wrote:
> We accidentally return success if the kmalloc_array() call fails.
>
> Fixes: 0e14c7777acb ("mlxsw: spectrum: Add the multicast routing hardware logic")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Yotam Gigi <yotamg@mellanox.com>
>
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c
> index 5e4ccbf17e3d..839eadf0765b 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c
> @@ -763,8 +763,10 @@ mlxsw_sp_mr_tcam_region_init(struct mlxsw_sp *mlxsw_sp,
>
> parman_prios = kmalloc_array(MLXSW_SP_MR_ROUTE_PRIO_MAX + 1,
> sizeof(*parman_prios), GFP_KERNEL);
> - if (!parman_prios)
> + if (!parman_prios) {
> + err = -ENOMEM;
> goto err_parman_prios_alloc;
> + }
> mr_tcam_region->parman_prios = parman_prios;
>
> for (i = 0; i < MLXSW_SP_MR_ROUTE_PRIO_MAX + 1; i++)
^ permalink raw reply
* Re: [PATCH 1/2 net-next] mlxsw: spectrum: Fix check for IS_ERR() instead of NULL
From: Yotam Gigi @ 2017-10-03 10:58 UTC (permalink / raw)
To: Dan Carpenter, Jiri Pirko; +Cc: Ido Schimmel, netdev, kernel-janitors
In-Reply-To: <20171003105303.u7yrzxknddmmerol@mwanda>
On 10/03/2017 01:53 PM, Dan Carpenter wrote:
> mlxsw_afa_block_create() doesn't return error pointers, it returns NULL
> on error.
>
> Fixes: 0e14c7777acb ("mlxsw: spectrum: Add the multicast routing hardware logic")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Yotam Gigi <yotamg@mellanox.com>
Thanks!
>
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c
> index cda9e9ad10e3..5e4ccbf17e3d 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c
> @@ -239,8 +239,8 @@ mlxsw_sp_mr_tcam_afa_block_create(struct mlxsw_sp *mlxsw_sp,
> int err;
>
> afa_block = mlxsw_afa_block_create(mlxsw_sp->afa);
> - if (IS_ERR(afa_block))
> - return afa_block;
> + if (!afa_block)
> + return ERR_PTR(-ENOMEM);
>
> err = mlxsw_afa_block_append_counter(afa_block, counter_index);
> if (err)
^ permalink raw reply
* [PATCH net-next] dev: advertise the new nsid when the netns iface changes
From: Nicolas Dichtel @ 2017-10-03 11:53 UTC (permalink / raw)
To: netdev; +Cc: davem, Nicolas Dichtel, Jason A . Donenfeld
In-Reply-To: <52f84baf-8027-d01f-8ece-db4f39a2f76f@6wind.com>
x-netns interfaces are bound to two netns: the link netns and the upper
netns. Usually, this kind of interfaces is created in the link netns and
then moved to the upper netns. At the end, the interface is visible only
in the upper netns. The link nsid is advertised via netlink in the upper
netns, thus the user always knows where is the link part.
There is no such mechanism in the link netns. When the interface is moved
to another netns, the user cannot "follow" it.
This patch adds a new netlink attribute which helps to follow an interface
which moves to another netns. When the interface is unregistered, the new
nsid is advertised. If the interface is a x-netns interface (ie
rtnl_link_ops->get_link_net is defined), the nsid is allocated if needed.
CC: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/linux/rtnetlink.h | 4 +++-
include/uapi/linux/if_link.h | 1 +
net/core/dev.c | 11 ++++++++---
net/core/rtnetlink.c | 31 ++++++++++++++++++++++---------
4 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index dea59c8eec54..1251638e60d3 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -17,9 +17,11 @@ extern int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst,
u32 id, long expires, u32 error);
void rtmsg_ifinfo(int type, struct net_device *dev, unsigned change, gfp_t flags);
+void rtmsg_ifinfo_newnet(int type, struct net_device *dev, unsigned int change,
+ gfp_t flags, int *new_nsid);
struct sk_buff *rtmsg_ifinfo_build_skb(int type, struct net_device *dev,
unsigned change, u32 event,
- gfp_t flags);
+ gfp_t flags, int *new_nsid);
void rtmsg_ifinfo_send(struct sk_buff *skb, struct net_device *dev,
gfp_t flags);
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index ea87bd708ee9..cd580fc0e58f 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -158,6 +158,7 @@ enum {
IFLA_PAD,
IFLA_XDP,
IFLA_EVENT,
+ IFLA_NEW_NETNSID,
__IFLA_MAX
};
diff --git a/net/core/dev.c b/net/core/dev.c
index e350c768d4b5..2341e9d64e02 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -145,6 +145,7 @@
#include <linux/crash_dump.h>
#include <linux/sctp.h>
#include <net/udp_tunnel.h>
+#include <linux/net_namespace.h>
#include "net-sysfs.h"
@@ -7178,7 +7179,7 @@ static void rollback_registered_many(struct list_head *head)
if (!dev->rtnl_link_ops ||
dev->rtnl_link_state == RTNL_LINK_INITIALIZED)
skb = rtmsg_ifinfo_build_skb(RTM_DELLINK, dev, ~0U, 0,
- GFP_KERNEL);
+ GFP_KERNEL, NULL);
/*
* Flush the unicast and multicast chains
@@ -8265,7 +8266,7 @@ EXPORT_SYMBOL(unregister_netdev);
int dev_change_net_namespace(struct net_device *dev, struct net *net, const char *pat)
{
- int err;
+ int err, new_nsid;
ASSERT_RTNL();
@@ -8321,7 +8322,11 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char
call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
rcu_barrier();
call_netdevice_notifiers(NETDEV_UNREGISTER_FINAL, dev);
- rtmsg_ifinfo(RTM_DELLINK, dev, ~0U, GFP_KERNEL);
+ if (dev->rtnl_link_ops && dev->rtnl_link_ops->get_link_net)
+ new_nsid = peernet2id_alloc(dev_net(dev), net);
+ else
+ new_nsid = peernet2id(dev_net(dev), net);
+ rtmsg_ifinfo_newnet(RTM_DELLINK, dev, ~0U, GFP_KERNEL, &new_nsid);
/*
* Flush the unicast and multicast chains
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index e6955da0d58d..5bec24c348bf 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -927,6 +927,7 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
+ nla_total_size(IFNAMSIZ) /* IFLA_PHYS_PORT_NAME */
+ rtnl_xdp_size() /* IFLA_XDP */
+ nla_total_size(4) /* IFLA_EVENT */
+ + nla_total_size(4) /* IFLA_NEW_NETNSID */
+ nla_total_size(1); /* IFLA_PROTO_DOWN */
}
@@ -1386,7 +1387,7 @@ static int rtnl_fill_link_netnsid(struct sk_buff *skb,
static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
int type, u32 pid, u32 seq, u32 change,
unsigned int flags, u32 ext_filter_mask,
- u32 event)
+ u32 event, int *new_nsid)
{
struct ifinfomsg *ifm;
struct nlmsghdr *nlh;
@@ -1475,6 +1476,10 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
if (rtnl_fill_link_netnsid(skb, dev))
goto nla_put_failure;
+ if (new_nsid &&
+ nla_put_s32(skb, IFLA_NEW_NETNSID, *new_nsid) < 0)
+ goto nla_put_failure;
+
if (!(af_spec = nla_nest_start(skb, IFLA_AF_SPEC)))
goto nla_put_failure;
@@ -1704,7 +1709,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq, 0,
flags,
- ext_filter_mask, 0);
+ ext_filter_mask, 0, NULL);
if (err < 0) {
if (likely(skb->len))
@@ -2817,7 +2822,7 @@ static int rtnl_getlink(struct sk_buff *skb, struct nlmsghdr *nlh,
return -ENOBUFS;
err = rtnl_fill_ifinfo(nskb, dev, RTM_NEWLINK, NETLINK_CB(skb).portid,
- nlh->nlmsg_seq, 0, 0, ext_filter_mask, 0);
+ nlh->nlmsg_seq, 0, 0, ext_filter_mask, 0, NULL);
if (err < 0) {
/* -EMSGSIZE implies BUG in if_nlmsg_size */
WARN_ON(err == -EMSGSIZE);
@@ -2902,7 +2907,7 @@ static int rtnl_dump_all(struct sk_buff *skb, struct netlink_callback *cb)
struct sk_buff *rtmsg_ifinfo_build_skb(int type, struct net_device *dev,
unsigned int change,
- u32 event, gfp_t flags)
+ u32 event, gfp_t flags, int *new_nsid)
{
struct net *net = dev_net(dev);
struct sk_buff *skb;
@@ -2913,7 +2918,8 @@ struct sk_buff *rtmsg_ifinfo_build_skb(int type, struct net_device *dev,
if (skb == NULL)
goto errout;
- err = rtnl_fill_ifinfo(skb, dev, type, 0, 0, change, 0, 0, event);
+ err = rtnl_fill_ifinfo(skb, dev, type, 0, 0, change, 0, 0, event,
+ new_nsid);
if (err < 0) {
/* -EMSGSIZE implies BUG in if_nlmsg_size() */
WARN_ON(err == -EMSGSIZE);
@@ -2936,14 +2942,14 @@ void rtmsg_ifinfo_send(struct sk_buff *skb, struct net_device *dev, gfp_t flags)
static void rtmsg_ifinfo_event(int type, struct net_device *dev,
unsigned int change, u32 event,
- gfp_t flags)
+ gfp_t flags, int *new_nsid)
{
struct sk_buff *skb;
if (dev->reg_state != NETREG_REGISTERED)
return;
- skb = rtmsg_ifinfo_build_skb(type, dev, change, event, flags);
+ skb = rtmsg_ifinfo_build_skb(type, dev, change, event, flags, new_nsid);
if (skb)
rtmsg_ifinfo_send(skb, dev, flags);
}
@@ -2951,10 +2957,17 @@ static void rtmsg_ifinfo_event(int type, struct net_device *dev,
void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change,
gfp_t flags)
{
- rtmsg_ifinfo_event(type, dev, change, rtnl_get_event(0), flags);
+ rtmsg_ifinfo_event(type, dev, change, rtnl_get_event(0), flags, NULL);
}
EXPORT_SYMBOL(rtmsg_ifinfo);
+void rtmsg_ifinfo_newnet(int type, struct net_device *dev, unsigned int change,
+ gfp_t flags, int *new_nsid)
+{
+ rtmsg_ifinfo_event(type, dev, change, rtnl_get_event(0), flags,
+ new_nsid);
+}
+
static int nlmsg_populate_fdb_fill(struct sk_buff *skb,
struct net_device *dev,
u8 *addr, u16 vid, u32 pid, u32 seq,
@@ -4330,7 +4343,7 @@ static int rtnetlink_event(struct notifier_block *this, unsigned long event, voi
case NETDEV_RESEND_IGMP:
case NETDEV_CHANGEINFODATA:
rtmsg_ifinfo_event(RTM_NEWLINK, dev, 0, rtnl_get_event(event),
- GFP_KERNEL);
+ GFP_KERNEL, NULL);
break;
default:
break;
--
2.13.2
^ permalink raw reply related
* Re: [PATCH net] net: br: Fix igmp snooping offload with CONFIG_BRIDGE_VLAN_FILTERING
From: Andrew Lunn @ 2017-10-03 12:16 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: David Miller, Vivien Didelot, netdev
In-Reply-To: <37af5488-a064-37dc-b1ce-373119ae7b05@lab.ntt.co.jp>
On Tue, Oct 03, 2017 at 12:29:56PM +0900, Toshiaki Makita wrote:
> On 2017/10/03 9:55, Andrew Lunn wrote:
> > With CONFIG_BRIDGE_VLAN_FILTERING enabled, but the feature not enabled
> > via /sys/class/net/brX/bridge/vlan_filtering, mdb offloaded to the
> > kernel have the wrong VID.
> >
> > When an interface is added to the bridge, switchdev is first used to
> > notify the hardware that a port has joined a bridge. This is
> > immediately followed by the default_pvid, 1, being added to the
> > interface via another switchdev call.
> >
> > The bridge will then perform IGMP snooping, and offload an mdb entries
> > to the switch as needed. With vlan filtering disabled, the vid is left
> > as 0. This causes the switch to put the static mdb into the wrong
> > vlan, and so frames are not forwarded by the mdb entry.
> >
> > If vlan filtering is disable, use the default_pvid, not 0.
> >
> > Fixes: f1fecb1d10ec ("bridge: Reflect MDB entries to hardware")
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> > net/bridge/br_vlan.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> > index 233a30040c91..aa3589891797 100644
> > --- a/net/bridge/br_vlan.c
> > +++ b/net/bridge/br_vlan.c
> > @@ -492,6 +492,7 @@ bool br_allowed_ingress(const struct net_bridge *br,
> > */
> > if (!br->vlan_enabled) {
> > BR_INPUT_SKB_CB(skb)->vlan_filtered = false;
> > + *vid = br_get_pvid(vg);
> > return true;
> > }
> >
>
> This does not look correct.
> This will update fdb with vid which is not 0.
> Pvid can be different between each port even when vlan_filtering is
> disabled so unicast forwarding (fdb learning) will break.
> Also, fdb is visible to userspace so this can break userspace which
> expects fdb entries with 0 as well.
>
> Why does the switch driver use pvid while vlan_filtering is disabled?
Hi Toshiaki
We get a vlan added to the port. I think it comes from a combination
of:
int br_vlan_init(struct net_bridge *br)
{
struct net_bridge_vlan_group *vg;
int ret = -ENOMEM;
vg = kzalloc(sizeof(*vg), GFP_KERNEL);
if (!vg)
goto out;
ret = rhashtable_init(&vg->vlan_hash, &br_vlan_rht_params);
if (ret)
goto err_rhtbl;
ret = vlan_tunnel_init(vg);
if (ret)
goto err_tunnel_init;
INIT_LIST_HEAD(&vg->vlan_list);
br->vlan_proto = htons(ETH_P_8021Q);
br->default_pvid = 1;
and
int nbp_vlan_init(struct net_bridge_port *p)
{
struct switchdev_attr attr = {
.orig_dev = p->br->dev,
.id = SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING,
.flags = SWITCHDEV_F_SKIP_EOPNOTSUPP,
.u.vlan_filtering = p->br->vlan_enabled,
};
struct net_bridge_vlan_group *vg;
int ret = -ENOMEM;
vg = kzalloc(sizeof(struct net_bridge_vlan_group), GFP_KERNEL);
if (!vg)
goto out;
ret = switchdev_port_attr_set(p->dev, &attr);
if (ret && ret != -EOPNOTSUPP)
goto err_vlan_enabled;
ret = rhashtable_init(&vg->vlan_hash, &br_vlan_rht_params);
if (ret)
goto err_rhtbl;
ret = vlan_tunnel_init(vg);
if (ret)
goto err_tunnel_init;
INIT_LIST_HEAD(&vg->vlan_list);
rcu_assign_pointer(p->vlgrp, vg);
if (p->br->default_pvid) {
ret = nbp_vlan_add(p, p->br->default_pvid,
BRIDGE_VLAN_INFO_PVID |
BRIDGE_VLAN_INFO_UNTAGGED);
Now, i just noticed the switchdev call above. I don't think the DSA
layer implements SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING. It probably
should. So what is it supposed to do with this VLAN when filtering is
disabled?
Andrew
^ permalink raw reply
* Re: [PATCH] net: dsa: lan9303: make functions lan9303_mdio_phy_{read|write} static
From: Andrew Lunn @ 2017-10-03 12:41 UTC (permalink / raw)
To: Colin King
Cc: Vivien Didelot, Florian Fainelli, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20171003103918.26934-1-colin.king@canonical.com>
On Tue, Oct 03, 2017 at 11:39:18AM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The functions lan9303_mdio_phy_write and lan9303_mdio_phy_read are local
> to the source and do not need to be in global scope, so make them static.
>
> Cleans up sparse warnings:
> symbol 'lan9303_mdio_phy_write' was not declared. Should it be static?
> symbol 'lan9303_mdio_phy_read' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] net: dsa: mt7530: make functions mt7530_phy_write static
From: Andrew Lunn @ 2017-10-03 12:42 UTC (permalink / raw)
To: Colin King
Cc: Vivien Didelot, Florian Fainelli, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20171003104633.27151-1-colin.king@canonical.com>
On Tue, Oct 03, 2017 at 11:46:33AM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The function mt7530_phy_write is local to the source and does not need to
> be in global scope, so make it static.
>
> Cleans up sparse warnings:
> symbol 'mt7530_phy_write' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* (unknown),
From: marketing @ 2017-10-03 12:43 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 2303159403401.zip --]
[-- Type: application/zip, Size: 7286 bytes --]
^ permalink raw reply
* Re: [PATCH] fsl/fman: remove of_node
From: Andrew Lunn @ 2017-10-03 13:00 UTC (permalink / raw)
To: Madalin-cristian Bucur
Cc: David Miller, netdev@vger.kernel.org, f.fainelli@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <AM5PR0402MB26914CBD37E3F28C17562258EC720@AM5PR0402MB2691.eurprd04.prod.outlook.com>
On Tue, Oct 03, 2017 at 08:49:31AM +0000, Madalin-cristian Bucur wrote:
> > -----Original Message-----
> > From: David Miller [mailto:davem@davemloft.net]
> > Sent: Tuesday, October 03, 2017 2:05 AM
> > To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
> > Subject: Re: [PATCH] fsl/fman: remove of_node
> >
> > From: Madalin Bucur <madalin.bucur@nxp.com>
> > Date: Mon, 2 Oct 2017 13:31:37 +0300
> >
> > > The FMan MAC driver allocates a platform device for the Ethernet
> > > driver to probe on. Setting pdev->dev.of_node with the MAC node
> > > triggers the MAC driver probing of the new platform device. While
> > > this fails quickly and does not affect the functionality of the
> > > drivers, it is incorrect and must be removed. This was added to
> > > address a report that DSA code using of_find_net_device_by_node()
> > > is unable to use the DPAA interfaces. Error message seen before
> > > this fix:
> > >
> > > fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> > > fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> > >
> > > Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
> >
> > Is the DSA issue no longer something we need to be concerned
> > about? If not, why? You have to explain this.
>
> My patch removes the of_node that was set to a device that was not an
> of_device, preventing duplicated probing of both the real of_device
> and the "fake" one created through this assignment.
>
> I understand that the DSA issue that triggered the initial change
> was related to DSA finding the network devices using
> of_find_net_device_by_node(), something that will not work for the
> DPAA case where the netdevice does not have an of_node. I do not know
> enough about DSA to come up with a solution for this problem now.
> Andrew, Florian, can you please comment on this?
>
> Thanks,
Hi Madalin
I guess the real fix is to throw away the platform device. But that is
a big change.
I've not looked at the code in detail. Why is the platform device
needed?
Andrew
^ permalink raw reply
* Re: [PATCH] netfilter: nf_tables: Release memory obtained by kasprintf
From: Pablo Neira Ayuso @ 2017-10-03 13:21 UTC (permalink / raw)
To: Arvind Yadav
Cc: kadlec, fw, davem, netfilter-devel, coreteam, netdev,
linux-kernel
In-Reply-To: <385554261c080cd3fc4adc093e68366a6d3dff77.1505889128.git.arvind.yadav.cs@gmail.com>
On Wed, Sep 20, 2017 at 12:31:28PM +0530, Arvind Yadav wrote:
> Free memory region, if nf_tables_set_alloc_name is not successful.
Applied, thanks.
I have added this tag to this patch:
Fixes: 387454901bd6 ("netfilter: nf_tables: Allow set names of up to 255 chars")
^ permalink raw reply
* Re: [PATCH v2 net-next 06/12] qed: Add LL2 slowpath handling
From: Leon Romanovsky @ 2017-10-03 13:26 UTC (permalink / raw)
To: Michal Kalderon
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
dledford-H+wXaHxf7aLQT0dZR+AlfA, Ariel Elior
In-Reply-To: <1507020902-4952-7-git-send-email-Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3933 bytes --]
On Tue, Oct 03, 2017 at 11:54:56AM +0300, Michal Kalderon wrote:
> For iWARP unaligned MPA flow, a slowpath event of flushing an
> MPA connection that entered an unaligned state is required.
> The flush ramrod is received on the ll2 queue, and a pre-registered
> callback function is called to handle the flush event.
>
> Signed-off-by: Michal Kalderon <Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Ariel Elior <Ariel.Elior-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> ---
> drivers/net/ethernet/qlogic/qed/qed_ll2.c | 40 +++++++++++++++++++++++++++++--
> include/linux/qed/qed_ll2_if.h | 5 ++++
> 2 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_ll2.c b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
> index 8eb9645..047f556 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_ll2.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
> @@ -423,6 +423,41 @@ static void qed_ll2_rxq_parse_reg(struct qed_hwfn *p_hwfn,
> }
>
> static int
> +qed_ll2_handle_slowpath(struct qed_hwfn *p_hwfn,
> + struct qed_ll2_info *p_ll2_conn,
> + union core_rx_cqe_union *p_cqe,
> + unsigned long *p_lock_flags)
> +{
> + struct qed_ll2_rx_queue *p_rx = &p_ll2_conn->rx_queue;
> + struct core_rx_slow_path_cqe *sp_cqe;
> +
> + sp_cqe = &p_cqe->rx_cqe_sp;
> + if (sp_cqe->ramrod_cmd_id != CORE_RAMROD_RX_QUEUE_FLUSH) {
> + DP_NOTICE(p_hwfn,
> + "LL2 - unexpected Rx CQE slowpath ramrod_cmd_id:%d\n",
> + sp_cqe->ramrod_cmd_id);
> + return -EINVAL;
> + }
> +
> + if (!p_ll2_conn->cbs.slowpath_cb) {
> + DP_NOTICE(p_hwfn,
> + "LL2 - received RX_QUEUE_FLUSH but no callback was provided\n");
> + return -EINVAL;
> + }
> +
> + spin_unlock_irqrestore(&p_rx->lock, *p_lock_flags);
Interesting, you are unlock the lock which was taken in upper layer.
It is not actual error, but chances to have such error are pretty high
(for example, after refactoring).
> +
> + p_ll2_conn->cbs.slowpath_cb(p_ll2_conn->cbs.cookie,
> + p_ll2_conn->my_id,
> + le32_to_cpu(sp_cqe->opaque_data.data[0]),
> + le32_to_cpu(sp_cqe->opaque_data.data[1]));
> +
> + spin_lock_irqsave(&p_rx->lock, *p_lock_flags);
> +
> + return 0;
> +}
> +
> +static int
> qed_ll2_rxq_handle_completion(struct qed_hwfn *p_hwfn,
> struct qed_ll2_info *p_ll2_conn,
> union core_rx_cqe_union *p_cqe,
> @@ -495,8 +530,8 @@ static int qed_ll2_rxq_completion(struct qed_hwfn *p_hwfn, void *cookie)
>
> switch (cqe->rx_cqe_sp.type) {
> case CORE_RX_CQE_TYPE_SLOW_PATH:
> - DP_NOTICE(p_hwfn, "LL2 - unexpected Rx CQE slowpath\n");
> - rc = -EINVAL;
> + rc = qed_ll2_handle_slowpath(p_hwfn, p_ll2_conn,
> + cqe, &flags);
> break;
> case CORE_RX_CQE_TYPE_GSI_OFFLOAD:
> case CORE_RX_CQE_TYPE_REGULAR:
> @@ -1214,6 +1249,7 @@ static int qed_ll2_acquire_connection_tx(struct qed_hwfn *p_hwfn,
> p_ll2_info->cbs.rx_release_cb = cbs->rx_release_cb;
> p_ll2_info->cbs.tx_comp_cb = cbs->tx_comp_cb;
> p_ll2_info->cbs.tx_release_cb = cbs->tx_release_cb;
> + p_ll2_info->cbs.slowpath_cb = cbs->slowpath_cb;
> p_ll2_info->cbs.cookie = cbs->cookie;
>
> return 0;
> diff --git a/include/linux/qed/qed_ll2_if.h b/include/linux/qed/qed_ll2_if.h
> index 95fdf02..e755954 100644
> --- a/include/linux/qed/qed_ll2_if.h
> +++ b/include/linux/qed/qed_ll2_if.h
> @@ -151,11 +151,16 @@ struct qed_ll2_comp_rx_data {
> dma_addr_t first_frag_addr,
> bool b_last_fragment, bool b_last_packet);
>
> +typedef
> +void (*qed_ll2_slowpath_cb)(void *cxt, u8 connection_handle,
> + u32 opaque_data_0, u32 opaque_data_1);
> +
> struct qed_ll2_cbs {
> qed_ll2_complete_rx_packet_cb rx_comp_cb;
> qed_ll2_release_rx_packet_cb rx_release_cb;
> qed_ll2_complete_tx_packet_cb tx_comp_cb;
> qed_ll2_release_tx_packet_cb tx_release_cb;
> + qed_ll2_slowpath_cb slowpath_cb;
> void *cookie;
> };
>
> --
> 1.8.3.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] netfilter: SYNPROXY: fix process non tcp packet bug in {ipv4,ipv6}_synproxy_hook
From: Pablo Neira Ayuso @ 2017-10-03 13:28 UTC (permalink / raw)
To: Lin Zhang
Cc: kadlec, fw, davem, kuznet, yoshfuji, netfilter-devel, coreteam,
netdev
In-Reply-To: <1506767115-10051-1-git-send-email-xiaolou4617@gmail.com>
On Sat, Sep 30, 2017 at 06:25:15PM +0800, Lin Zhang wrote:
> In function {ipv4,ipv6}_synproxy_hook we expect a normal tcp packet,
> but the real server maybe reply an icmp error packet related to the
> exist tcp conntrack, so we will access wrong tcp data.
>
> For fix it, check for the protocol field and only process tcp traffic.
Applied, thanks.
I have made minor comestic changes to patch title:
netfilter: SYNPROXY: skip non-TCP packets from {ipv4,ipv6}_synproxy_hook
for the record.
^ permalink raw reply
* Re: [PATCH v2] netfilter: SYNPROXY: fix process non tcp packet bug in {ipv4,ipv6}_synproxy_hook
From: Pablo Neira Ayuso @ 2017-10-03 13:32 UTC (permalink / raw)
To: Lin Zhang
Cc: kadlec, fw, davem, kuznet, yoshfuji, netfilter-devel, coreteam,
netdev
In-Reply-To: <20171003132825.GA11182@salvia>
On Tue, Oct 03, 2017 at 03:28:25PM +0200, Pablo Neira Ayuso wrote:
> On Sat, Sep 30, 2017 at 06:25:15PM +0800, Lin Zhang wrote:
> > In function {ipv4,ipv6}_synproxy_hook we expect a normal tcp packet,
> > but the real server maybe reply an icmp error packet related to the
> > exist tcp conntrack, so we will access wrong tcp data.
> >
> > For fix it, check for the protocol field and only process tcp traffic.
>
> Applied, thanks.
>
> I have made minor comestic changes to patch title:
>
> netfilter: SYNPROXY: skip non-TCP packets from {ipv4,ipv6}_synproxy_hook
>
> for the record.
I have to keep this back, sorry.
This has been not compiled tested.
net/ipv6/netfilter/ip6t_SYNPROXY.c: In function ‘ipv6_synproxy_hook’:
net/ipv6/netfilter/ip6t_SYNPROXY.c:351:19: error: ‘struct ipv6hdr’ has
no member named ‘protocol’
ipv6_hdr(skb)->protocol != IPPROTO_TCP)
^
^ permalink raw reply
* Re: [PATCH] rndis_host: support Novatel Verizon USB730L
From: Bjørn Mork @ 2017-10-03 14:01 UTC (permalink / raw)
To: David Miller
Cc: aleksander-Dvg4H30XQSRVIjRurl1/8g, oliver-GvhC2dPhHPQdnm+yROfE0A,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171002.161750.1123671129875495210.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> From: Aleksander Morgado <aleksander-Dvg4H30XQSRVIjRurl1/8g@public.gmane.org>
> Date: Wed, 27 Sep 2017 23:31:03 +0200
>
>> I'm not sure if binding this logic to a specific vid:pid (1410:9030)
>> would be more appropriate here, or if it's ok to just bind
>> class/subclass/protocol (as in the activesync case). Let me know
>> what you think.
>
> I don't have enough USB Networking knowledge to make a decision here.
>
> Some things seem confusing. For example, if we should be matching
> USB_CLASS_MISC, subclass=4, protocol=1 for RNDIS over Ethernet, then
> we why aren't we also matching USB_CLASS_MISC, subclass=4, protocol=2
> for RNDIS over wireless and instead are matching "Remote RNDIS" in
> the form of USB_CLASS_WIRELSS, subclass=1, protocol=3?
>
> I really don't understand any of this magic :-)
>
> So someone more knowledgable needs to review this.
Let me just say that I am not qualified. But since this needs a review,
I am going to offer my view anyway. FWIW, I don't think *anyone*
understand this magic... I certainly don't.
We can pretty much ignore the USB-IF and any specs, since that is what
the vendors appear to do. They provide device specific drivers for
Windows, so all they care about is that their device "works" with their
driver.
But in Linux we prefer to create drivers for device classes whenever we
can, to avoid having to add every single device by ID. So we try to
guess future patterns based on the devices we have observed, even when
there is no clear spec. This is what Aleksander does here. He has a
device with a 'Cls=ef(misc ) Sub=04 Prot=01' function. This device
works with the rndis_host driver. That is all we know.
We cannot prove that a class match is correct. But it does make sense to
try it. At least we know that this works for one device.
Adding anything else, e.g. based on the table at
http://www.usb.org/developers/defined_class/#BaseClassEFh , is a bit
more risky. We don't know if a driver will work with *any* such device
until we've actually seen one.
This is just my opinion, and probably full of bogus assumptions as
usual. I was sort of hoping that some expert would speak up so I didn't
have to :-)
But FWIW:
Reviewed-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] libbpf: parse maps sections of varying size
From: Jesper Dangaard Brouer @ 2017-10-03 14:03 UTC (permalink / raw)
To: Craig Gallek
Cc: Alexei Starovoitov, Daniel Borkmann, David S . Miller,
Chonggang Li, netdev, brouer, Eric Leblond, Wangnan (F)
In-Reply-To: <20171002164129.47986-2-kraigatgoog@gmail.com>
First of all, thank you Craig for working on this. As Alexei says, we
need to improve tools/lib/bpf/libbpf and move towards converting users
of bpf_load.c to this lib instead.
Comments inlined below.
On Mon, 2 Oct 2017 12:41:28 -0400 Craig Gallek <kraigatgoog@gmail.com> wrote:
> From: Craig Gallek <kraig@google.com>
>
> This library previously assumed a fixed-size map options structure.
> Any new options were ignored. In order to allow the options structure
> to grow and to support parsing older programs, this patch updates
> the maps section parsing to handle varying sizes.
>
> Object files with maps sections smaller than expected will have the new
> fields initialized to zero. Object files which have larger than expected
> maps sections will be rejected unless all of the unrecognized data is zero.
>
> This change still assumes that each map definition in the maps section
> is the same size.
>
> Signed-off-by: Craig Gallek <kraig@google.com>
> ---
> tools/lib/bpf/libbpf.c | 54 ++++++++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 4f402dcdf372..28b300868ad7 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -580,7 +580,7 @@ bpf_object__init_kversion(struct bpf_object *obj,
> }
>
> static int
> -bpf_object__validate_maps(struct bpf_object *obj)
> +bpf_object__validate_maps(struct bpf_object *obj, int map_def_sz)
> {
> int i;
>
> @@ -595,9 +595,11 @@ bpf_object__validate_maps(struct bpf_object *obj)
> const struct bpf_map *a = &obj->maps[i - 1];
> const struct bpf_map *b = &obj->maps[i];
>
> - if (b->offset - a->offset < sizeof(struct bpf_map_def)) {
> - pr_warning("corrupted map section in %s: map \"%s\" too small\n",
> - obj->path, a->name);
> + if (b->offset - a->offset < map_def_sz) {
> + pr_warning("corrupted map section in %s: map \"%s\" too small "
> + "(%zd vs %d)\n",
> + obj->path, a->name, b->offset - a->offset,
> + map_def_sz);
> return -EINVAL;
> }
> }
> @@ -615,7 +617,7 @@ static int compare_bpf_map(const void *_a, const void *_b)
> static int
> bpf_object__init_maps(struct bpf_object *obj)
> {
> - int i, map_idx, nr_maps = 0;
> + int i, map_idx, map_def_sz, nr_maps = 0;
> Elf_Scn *scn;
> Elf_Data *data;
> Elf_Data *symbols = obj->efile.symbols;
> @@ -658,6 +660,15 @@ bpf_object__init_maps(struct bpf_object *obj)
> if (!nr_maps)
> return 0;
>
> + /* Assume equally sized map definitions */
> + map_def_sz = data->d_size / nr_maps;
> + if (!data->d_size || (data->d_size % nr_maps) != 0) {
> + pr_warning("unable to determine map definition size "
> + "section %s, %d maps in %zd bytes\n",
> + obj->path, nr_maps, data->d_size);
> + return -EINVAL;
> + }
> +
> obj->maps = calloc(nr_maps, sizeof(obj->maps[0]));
> if (!obj->maps) {
> pr_warning("alloc maps for object failed\n");
> @@ -690,7 +701,7 @@ bpf_object__init_maps(struct bpf_object *obj)
> obj->efile.strtabidx,
> sym.st_name);
> obj->maps[map_idx].offset = sym.st_value;
> - if (sym.st_value + sizeof(struct bpf_map_def) > data->d_size) {
> + if (sym.st_value + map_def_sz > data->d_size) {
> pr_warning("corrupted maps section in %s: last map \"%s\" too small\n",
> obj->path, map_name);
> return -EINVAL;
> @@ -704,12 +715,39 @@ bpf_object__init_maps(struct bpf_object *obj)
> pr_debug("map %d is \"%s\"\n", map_idx,
> obj->maps[map_idx].name);
> def = (struct bpf_map_def *)(data->d_buf + sym.st_value);
> - obj->maps[map_idx].def = *def;
> + /*
> + * If the definition of the map in the object file fits in
> + * bpf_map_def, copy it. Any extra fields in our version
> + * of bpf_map_def will default to zero as a result of the
> + * calloc above.
> + */
> + if (map_def_sz <= sizeof(struct bpf_map_def)) {
> + memcpy(&obj->maps[map_idx].def, def, map_def_sz);
> + } else {
> + /*
> + * Here the map structure being read is bigger than what
> + * we expect, truncate if the excess bits are all zero.
> + * If they are not zero, reject this map as
> + * incompatible.
> + */
> + char *b;
> + for (b = ((char *)def) + sizeof(struct bpf_map_def);
> + b < ((char *)def) + map_def_sz; b++) {
> + if (*b != 0) {
> + pr_warning("maps section in %s: \"%s\" "
> + "has unrecognized, non-zero "
> + "options\n",
> + obj->path, map_name);
> + return -EINVAL;
> + }
> + }
> + obj->maps[map_idx].def = *def;
I'm not too happy/comfortable with this way of copying the memory of
"def" (the type-cased struct bpf_map_def). I guess it works, and is
part of the C-standard(?).
> + }
> map_idx++;
> }
>
> qsort(obj->maps, obj->nr_maps, sizeof(obj->maps[0]), compare_bpf_map);
> - return bpf_object__validate_maps(obj);
> + return bpf_object__validate_maps(obj, map_def_sz);
> }
>
> static int bpf_object__elf_collect(struct bpf_object *obj)
Besides above comment, I think the patch is correct, based on what I
did in commit 156450d9d964 ("samples/bpf: make bpf_load.c code
compatible with ELF maps section changes").
https://git.kernel.org/torvalds/c/156450d9d964
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] libbpf: parse maps sections of varying size
From: Jesper Dangaard Brouer @ 2017-10-03 14:11 UTC (permalink / raw)
To: Craig Gallek
Cc: Alexei Starovoitov, Daniel Borkmann, David S . Miller,
Chonggang Li, netdev, brouer, Eric Leblond
In-Reply-To: <20171002164129.47986-2-kraigatgoog@gmail.com>
On Mon, 2 Oct 2017 12:41:28 -0400
Craig Gallek <kraigatgoog@gmail.com> wrote:
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 4f402dcdf372..28b300868ad7 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -580,7 +580,7 @@ bpf_object__init_kversion(struct bpf_object *obj,
> }
>
> static int
> -bpf_object__validate_maps(struct bpf_object *obj)
> +bpf_object__validate_maps(struct bpf_object *obj, int map_def_sz)
> {
> int i;
>
> @@ -595,9 +595,11 @@ bpf_object__validate_maps(struct bpf_object *obj)
> const struct bpf_map *a = &obj->maps[i - 1];
> const struct bpf_map *b = &obj->maps[i];
>
> - if (b->offset - a->offset < sizeof(struct bpf_map_def)) {
> - pr_warning("corrupted map section in %s: map \"%s\" too small\n",
> - obj->path, a->name);
> + if (b->offset - a->offset < map_def_sz) {
> + pr_warning("corrupted map section in %s: map \"%s\" too small "
> + "(%zd vs %d)\n",
> + obj->path, a->name, b->offset - a->offset,
> + map_def_sz);
> return -EINVAL;
Hmm... one more comment. You have just coded handling of ELF
map_def_sz which are smaller in a safe manor, but here this case will
get rejected (in bpf_object__validate_maps). That cannot be the right
intend?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] tools: bpftool: add documentation
From: Daniel Borkmann @ 2017-10-03 14:15 UTC (permalink / raw)
To: Jakub Kicinski, Alexei Starovoitov; +Cc: netdev, oss-drivers, David Beckett
In-Reply-To: <20171002183509.76b2cc65@cakuba>
On 10/03/2017 03:35 AM, Jakub Kicinski wrote:
> On Mon, 2 Oct 2017 17:55:02 -0700, Alexei Starovoitov wrote:
>>> +EXAMPLES
>>> +========
>>> +**# bpftool prog show**
>>> +::
>>> +
>>> + 10: xdp name:some_prog tag 00:5a:3d:21:23:62:0c:8b
>>
>> could you please remove ':' in the output to match what
>> show_fdinfo and kallsyms do ?
Yep, iproute2 as well, so would be better indeed.
> Ack.
>
>>> + loaded_at:2024.771 uid:0
>>
>> may be translate that to something human readable?
>
> Oh yes, the code will print a proper date/time, I forgot to
> regenerate the doc :S
>
>>> + xlated:528B jited:370B memlock:4096B map_ids:10
>>> +
>>> +|
>>> +| **# bpftool prog dump xlated id 10 file /tmp/t**
>>> +| **# ls -l /tmp/t**
>>> +| -rw------- 1 root root 560 Jul 22 01:42 /tmp/t
>>> +
>>> +|
>>> +| **# mount -t bpf none /sys/fs/bpf/**
>>> +| **# bpftool prog pin id 10 /sys/fs/bpf/prog**
>>> +| **# bpftool prog dum jited pinned /sys/fs/bpf/prog**
>>> +
>>> +::
>>> +
>>> + push %rbp
>>> + mov %rsp,%rbp
>>> + sub $0x228,%rsp
>>> + sub $0x28,%rbp
>>> + mov %rbx,0x0(%rbp)
>>
>> imo too many steps to dump disasm output.
>> Can it print it if we just say:
>> bpftool prog dump jited id 10
>> and
>> dump xlated
>
> Yes those will work. This example kind of shows pinning and dumping at
> the some time. Perhaps that's ill advised.
>
>> will pretty print them as verifier output as well?
>
> We tried to use LLVM as a library for this but the interface is
> painfully unstable and it's a heavy dependency. The current thinking
> is to try to put the instruction printing code in some higher level
> library, but I would rather leave that as a follow up.
>
>> All that can be changed later. Thanks for the doc.
Fine with that as well, so:
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net] net: rtnetlink: fix info leak in RTM_GETSTATS call
From: Roopa Prabhu @ 2017-10-03 14:18 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: netdev@vger.kernel.org, keescook, Dmitry Vyukov, Andrey Konovalov,
Kostya Serebryany, Alexander Potapenko, davem@davemloft.net,
Eric Dumazet
In-Reply-To: <1507026048-13734-1-git-send-email-nikolay@cumulusnetworks.com>
On Tue, Oct 3, 2017 at 3:20 AM, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
> When RTM_GETSTATS was added the fields of its header struct were not all
> initialized when returning the result thus leaking 4 bytes of information
> to user-space per rtnl_fill_statsinfo call, so initialize them now. Thanks
> to Alexander Potapenko for the detailed report and bisection.
>
> Reported-by: Alexander Potapenko <glider@google.com>
> Fixes: 10c9ead9f3c6 ("rtnetlink: add new RTM_GETSTATS message to dump link stats")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Thanks Nikolay!.
^ permalink raw reply
* Re: [net-next V3 PATCH 3/5] bpf: cpumap xdp_buff to skb conversion and allocation
From: Jesper Dangaard Brouer @ 2017-10-03 14:18 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: netdev, jakub.kicinski, Michael S. Tsirkin, pavel.odintsov,
Jason Wang, mchan, John Fastabend, peter.waskiewicz.jr,
Daniel Borkmann, Andy Gospodarek, brouer
In-Reply-To: <20171003085843.14d3491e@redhat.com>
On Tue, 3 Oct 2017 08:58:43 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> > But that prog can do cpumap redirect again?
> > sort-of recursive redirect? Is it really useful?
> > May be call into __netif_receive_skb_core() directly?
> > not sure.
>
> I like the idea of calling __netif_receive_skb_core() directly. I'll
> send a V4 (after running my different benchmarks).
Using __netif_receive_skb_core() was straight forward/easy.
But I realized I had forgotten about Generic-XDP, which I also need to
code up. And with Generic-XDP we cannot invoke netif_receive_skb(),
because it would recursively invoke itself (which you actually point out
above, thx). I'll send a V4 out tomorrow.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [net-next V3 PATCH 3/5] bpf: cpumap xdp_buff to skb conversion and allocation
From: Daniel Borkmann @ 2017-10-03 14:25 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Alexei Starovoitov
Cc: netdev, jakub.kicinski, Michael S. Tsirkin, pavel.odintsov,
Jason Wang, mchan, John Fastabend, peter.waskiewicz.jr,
Daniel Borkmann, Andy Gospodarek
In-Reply-To: <20171003085843.14d3491e@redhat.com>
On 10/03/2017 08:58 AM, Jesper Dangaard Brouer wrote:
[...]
>> Or you're calling netif_receive_skb() to be able to call
>> generic XDP on that cpu again ?
>
> That should not (currently) be possible. AFAIK we (Daniel) choose to
> not allow Native and Generic XDP to be loaded on the same net_device.
> (With the same ABI argument as here)
Correct, it's either native or generic, but not both.
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] libbpf: parse maps sections of varying size
From: Daniel Borkmann @ 2017-10-03 14:39 UTC (permalink / raw)
To: Alexei Starovoitov, Craig Gallek, Jesper Dangaard Brouer,
David S . Miller
Cc: Chonggang Li, netdev
In-Reply-To: <5082193f-0b59-bc40-290f-4ef3709a1d26@fb.com>
On 10/03/2017 01:07 AM, Alexei Starovoitov wrote:
> On 10/2/17 9:41 AM, Craig Gallek wrote:
>> + /* Assume equally sized map definitions */
>> + map_def_sz = data->d_size / nr_maps;
>> + if (!data->d_size || (data->d_size % nr_maps) != 0) {
>> + pr_warning("unable to determine map definition size "
>> + "section %s, %d maps in %zd bytes\n",
>> + obj->path, nr_maps, data->d_size);
>> + return -EINVAL;
>> + }
>
> this approach is not as flexible as done by samples/bpf/bpf_load.c
> where it looks at every map independently by walking symtab,
> but I guess it's ok.
Regarding different map spec structs in a single prog: unless
we have a good use case why we would need it (and I'm not aware
of anything in particular), I would just go with a fixed size.
I did kind of similar sanity checks in bpf_fetch_maps_end() in
iproute2 loader as well.
^ permalink raw reply
* Re: [PATCH net] net: br: Fix igmp snooping offload with CONFIG_BRIDGE_VLAN_FILTERING
From: Vivien Didelot @ 2017-10-03 14:57 UTC (permalink / raw)
To: Andrew Lunn, Toshiaki Makita; +Cc: David Miller, netdev
In-Reply-To: <20171003121636.GB13548@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
> Now, i just noticed the switchdev call above. I don't think the DSA
> layer implements SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING. It probably
> should. So what is it supposed to do with this VLAN when filtering is
> disabled?
The DSA layer does implement SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING.
Its interpretation is to enable 802.1Q mode on targeted switch ports.
(hoping this is the correct thing to do.)
^ permalink raw reply
* RE: [PATCH 3/7] crypto:gf128mul: The x8_ble multiplication functions
From: David Laight @ 2017-10-03 14:58 UTC (permalink / raw)
To: 'Harsh Jain', herbert@gondor.apana.org.au,
linux-crypto@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <3e443f7a245229a2752fcf21dfed10998847e345.1507010612.git.harsh@chelsio.com>
From: Harsh Jain
> Sent: 03 October 2017 07:46
> It multiply GF(2^128) elements in the ble format.
> It will be used by chelsio driver to fasten gf multiplication.
^ speed up ??
David
^ permalink raw reply
* Re: [PATCH net] net: br: Fix igmp snooping offload with CONFIG_BRIDGE_VLAN_FILTERING
From: Toshiaki Makita @ 2017-10-03 15:03 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Toshiaki Makita, David Miller, Vivien Didelot, netdev
In-Reply-To: <20171003121636.GB13548@lunn.ch>
On 17/10/03 (火) 21:16, Andrew Lunn wrote:
> On Tue, Oct 03, 2017 at 12:29:56PM +0900, Toshiaki Makita wrote:
>> On 2017/10/03 9:55, Andrew Lunn wrote:
>>> With CONFIG_BRIDGE_VLAN_FILTERING enabled, but the feature not enabled
>>> via /sys/class/net/brX/bridge/vlan_filtering, mdb offloaded to the
>>> kernel have the wrong VID.
>>>
>>> When an interface is added to the bridge, switchdev is first used to
>>> notify the hardware that a port has joined a bridge. This is
>>> immediately followed by the default_pvid, 1, being added to the
>>> interface via another switchdev call.
>>>
>>> The bridge will then perform IGMP snooping, and offload an mdb entries
>>> to the switch as needed. With vlan filtering disabled, the vid is left
>>> as 0. This causes the switch to put the static mdb into the wrong
>>> vlan, and so frames are not forwarded by the mdb entry.
>>>
>>> If vlan filtering is disable, use the default_pvid, not 0.
>>>
>>> Fixes: f1fecb1d10ec ("bridge: Reflect MDB entries to hardware")
>>> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>>> ---
>>> net/bridge/br_vlan.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
>>> index 233a30040c91..aa3589891797 100644
>>> --- a/net/bridge/br_vlan.c
>>> +++ b/net/bridge/br_vlan.c
>>> @@ -492,6 +492,7 @@ bool br_allowed_ingress(const struct net_bridge *br,
>>> */
>>> if (!br->vlan_enabled) {
>>> BR_INPUT_SKB_CB(skb)->vlan_filtered = false;
>>> + *vid = br_get_pvid(vg);
>>> return true;
>>> }
>>>
>>
>> This does not look correct.
>> This will update fdb with vid which is not 0.
>> Pvid can be different between each port even when vlan_filtering is
>> disabled so unicast forwarding (fdb learning) will break.
>> Also, fdb is visible to userspace so this can break userspace which
>> expects fdb entries with 0 as well.
>>
>> Why does the switch driver use pvid while vlan_filtering is disabled?
>
> Hi Toshiaki
>
> We get a vlan added to the port. I think it comes from a combination
> of:
>
>
> int br_vlan_init(struct net_bridge *br)
> {
> struct net_bridge_vlan_group *vg;
> int ret = -ENOMEM;
>
> vg = kzalloc(sizeof(*vg), GFP_KERNEL);
> if (!vg)
> goto out;
> ret = rhashtable_init(&vg->vlan_hash, &br_vlan_rht_params);
> if (ret)
> goto err_rhtbl;
> ret = vlan_tunnel_init(vg);
> if (ret)
> goto err_tunnel_init;
> INIT_LIST_HEAD(&vg->vlan_list);
> br->vlan_proto = htons(ETH_P_8021Q);
> br->default_pvid = 1;
>
> and
>
> int nbp_vlan_init(struct net_bridge_port *p)
> {
> struct switchdev_attr attr = {
> .orig_dev = p->br->dev,
> .id = SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING,
> .flags = SWITCHDEV_F_SKIP_EOPNOTSUPP,
> .u.vlan_filtering = p->br->vlan_enabled,
> };
> struct net_bridge_vlan_group *vg;
> int ret = -ENOMEM;
>
> vg = kzalloc(sizeof(struct net_bridge_vlan_group), GFP_KERNEL);
> if (!vg)
> goto out;
>
> ret = switchdev_port_attr_set(p->dev, &attr);
> if (ret && ret != -EOPNOTSUPP)
> goto err_vlan_enabled;
>
> ret = rhashtable_init(&vg->vlan_hash, &br_vlan_rht_params);
> if (ret)
> goto err_rhtbl;
> ret = vlan_tunnel_init(vg);
> if (ret)
> goto err_tunnel_init;
> INIT_LIST_HEAD(&vg->vlan_list);
> rcu_assign_pointer(p->vlgrp, vg);
> if (p->br->default_pvid) {
> ret = nbp_vlan_add(p, p->br->default_pvid,
> BRIDGE_VLAN_INFO_PVID |
> BRIDGE_VLAN_INFO_UNTAGGED);
>
> Now, i just noticed the switchdev call above. I don't think the DSA
> layer implements SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING. It probably
> should. So what is it supposed to do with this VLAN when filtering is
> disabled?
The vlan will be effective only when vlan_filtering is enabled.
When vlan_filtering is disabled, vlan information is still kept in the
bridge and gets effective later when vlan_filtering becomes enable.
Toshiaki Makita
^ permalink raw reply
* Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626
From: Dmitry Vyukov @ 2017-10-03 15:19 UTC (permalink / raw)
To: Eric Dumazet
Cc: Mark Rutland, LKML, netdev, linux-arm-kernel, syzkaller,
David S. Miller, Willem de Bruijn
In-Reply-To: <CANn89i+zQG=rjHRqzsvPzjg5tqW43Lcz-BJ9spLascP9Nt5z8Q@mail.gmail.com>
On Mon, Oct 2, 2017 at 4:42 PM, 'Eric Dumazet' via syzkaller
<syzkaller@googlegroups.com> wrote:
> On Mon, Oct 2, 2017 at 7:21 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> Hi Eric,
>>
>> On Mon, Oct 02, 2017 at 06:36:32AM -0700, Eric Dumazet wrote:
>>> On Mon, Oct 2, 2017 at 3:49 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>>> > I hit the below splat at net/core/skbuff.c:2626 while fuzzing v4.14-rc2
>>> > on arm64 with Syzkaller. This is the BUG_ON(len) at the end of
>>> > skb_copy_and_csum_bits().
>>
>>> > kernel BUG at net/core/skbuff.c:2626!
>>
>>> > [<ffff200009e03214>] skb_copy_and_csum_bits+0x8dc/0xae0 net/core/skbuff.c:2626
>>> > [<ffff20000a01d244>] icmp_glue_bits+0xa4/0x2a0 net/ipv4/icmp.c:357
>>> > [<ffff200009f3f0d4>] __ip_append_data+0x10e4/0x20a8 net/ipv4/ip_output.c:1018
>>> > [<ffff200009f41a88>] ip_append_data.part.3+0xe8/0x1a0 net/ipv4/ip_output.c:1170
>>> > [<ffff200009f46e74>] ip_append_data+0xa4/0xb0 net/ipv4/ip_output.c:1173
>>> > [<ffff20000a01ccc8>] icmp_push_reply+0x1b8/0x690 net/ipv4/icmp.c:375
>>> > [<ffff20000a0211b0>] icmp_send+0x1070/0x1890 net/ipv4/icmp.c:741
>>> > [<ffff200009f41d48>] ip_fragment.constprop.4+0x208/0x340 net/ipv4/ip_output.c:552
>>> > [<ffff200009f42228>] ip_finish_output+0x3a8/0xab0 net/ipv4/ip_output.c:315
>>> > [<ffff200009f468c4>] NF_HOOK_COND include/linux/netfilter.h:238 [inline]
>>> > [<ffff200009f468c4>] ip_output+0x284/0x790 net/ipv4/ip_output.c:405
>>> > [<ffff200009f43204>] dst_output include/net/dst.h:458 [inline]
>>> > [<ffff200009f43204>] ip_local_out+0x9c/0x1b8 net/ipv4/ip_output.c:124
>>> > [<ffff200009f445e8>] ip_queue_xmit+0x850/0x18e0 net/ipv4/ip_output.c:504
>>> > [<ffff200009fb091c>] tcp_transmit_skb+0x107c/0x3338 net/ipv4/tcp_output.c:1123
>>> > [<ffff200009fbbcc4>] __tcp_retransmit_skb+0x614/0x1d18 net/ipv4/tcp_output.c:2847
>>> > [<ffff200009fbd840>] tcp_send_loss_probe+0x478/0x7d0 net/ipv4/tcp_output.c:2457
>>> > [<ffff200009fc707c>] tcp_write_timer_handler+0x50c/0x7e8 net/ipv4/tcp_timer.c:557
>>> > [<ffff200009fc73d0>] tcp_write_timer+0x78/0x170 net/ipv4/tcp_timer.c:579
>>> > [<ffff2000082f8980>] call_timer_fn+0x1b8/0x430 kernel/time/timer.c:1281
>>> > [<ffff2000082f8dcc>] expire_timers+0x1d4/0x320 kernel/time/timer.c:1320
>>> > [<ffff2000082f912c>] __run_timers kernel/time/timer.c:1620 [inline]
>>> > [<ffff2000082f912c>] run_timer_softirq+0x214/0x5f0 kernel/time/timer.c:1646
>>> > [<ffff2000080826c0>] __do_softirq+0x350/0xc0c kernel/softirq.c:284
>>> > [<ffff200008170af4>] do_softirq_own_stack include/linux/interrupt.h:498 [inline]
>>> > [<ffff200008170af4>] invoke_softirq kernel/softirq.c:371 [inline]
>>> > [<ffff200008170af4>] irq_exit+0x1dc/0x2f8 kernel/softirq.c:405
>>> > [<ffff2000082a95bc>] __handle_domain_irq+0xdc/0x230 kernel/irq/irqdesc.c:647
>>> > [<ffff2000080820ac>] handle_domain_irq include/linux/irqdesc.h:175 [inline]
>>> > [<ffff2000080820ac>] gic_handle_irq+0x6c/0xe0 drivers/irqchip/irq-gic.c:367
>>
>>> This is most likely a bug caused by syzkaller setting a ridiculous MTU
>>> on loopback device, below minimum size of ipv4 MTU.
>>
>>> I tried to track it in August [1], but it seems hard to find all the
>>> issues with this.
>>>
>>> commit c780a049f9bf442314335372c9abc4548bfe3e44
>>> Author: Eric Dumazet <edumazet@google.com>
>>> Date: Wed Aug 16 11:09:12 2017 -0700
>>>
>>> ipv4: better IP_MAX_MTU enforcement
>>>
>>> While working on yet another syzkaller report, I found
>>> that our IP_MAX_MTU enforcements were not properly done.
>>>
>>> gcc seems to reload dev->mtu for min(dev->mtu, IP_MAX_MTU), and
>>> final result can be bigger than IP_MAX_MTU :/
>>>
>>> This is a problem because device mtu can be changed on other cpus or
>>> threads.
>>>
>>> While this patch does not fix the issue I am working on, it is
>>> probably worth addressing it.
>>
>> Just to check I've understood correctly, are you suggesting that the
>> IPv4 code should also check the dev->mtu against a IP_MIN_MTU (which
>> doesn't seem to exist today)?
>
> We have plenty of places this is checked.
>
> For example, trying to set MTU < 68 usually removes IPv4 addresses and routes.
>
> Problem is : these checks are not fool proof yet.
>
> ( Only the admin was supposed to play these games )
>
>>
>> Otherwise, I do spot another potential issue. The writer side (e.g. most
>> net_device::ndo_change_mtu implementations and the __dev_set_mtu()
>> fallback) doesn't use WRITE_ONCE().
>
> It does not matter how many strange values can be observed by the reader :
> We must be fool proof anyway from reader point of view, so the
> WRITE_ONCE() is not strictly needed.
Note if writer stores some temporal garbage there (which C language
perfectly allows), it does not matter what we do on reader side --
reader won't get correct data anyway. Say mtu changes from 1000 to
2000, but writer temporary stores 1 there, reader can observe 1 while
it must not. Synchronization is always a game of two.
^ permalink raw reply
* Re: [PATCH net] net: br: Fix igmp snooping offload with CONFIG_BRIDGE_VLAN_FILTERING
From: Andrew Lunn @ 2017-10-03 15:30 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: Toshiaki Makita, David Miller, Vivien Didelot, netdev
In-Reply-To: <ad0d7686-298b-02c7-d8f8-b9363f4630f3@gmail.com>
> The vlan will be effective only when vlan_filtering is enabled.
> When vlan_filtering is disabled, vlan information is still kept in the
> bridge and gets effective later when vlan_filtering becomes enable.
O.K, so things are starting to get clearer.
So when vlan filtering is disabled, the hardware should just ignore
the requests to add the vlan to the hardware?
When vlan_filtering is enabled, are all the vlans in the software
bridge again offloaded? Or do we need to remember all the vlans which
we ignored while vlan filtering was disabled? The average switch has
nowhere to store these disabled vlans. It can only store active vlans.
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox