* Re: [PATCH net-next 0/8] net: sched: pie: align PIE implementation with RFC 8033
From: David Miller @ 2018-10-31 17:43 UTC (permalink / raw)
To: lesliemonis
Cc: jhs, netdev, tahiliani, dhavaljkhandla26, hrishihiraskar,
bmanish15597, sdp.sachin
In-Reply-To: <1541002772-28040-1-git-send-email-lesliemonis@gmail.com>
net-next is closed, please resubmit this when net-next opens back up.
Thank you.
^ permalink raw reply
* [PATCH net] openvswitch: Fix push/pop ethernet validation
From: Jaime Caamaño Ruiz @ 2018-10-31 17:52 UTC (permalink / raw)
To: netdev; +Cc: pshelar, Jaime Caamaño Ruiz
When there are both pop and push ethernet header actions among the
actions to be applied to a packet, an unexpected EINVAL (Invalid
argument) error is obtained. This is due to mac_proto not being reset
correctly when those actions are validated.
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-October/047554.html
Fixes: 91820da6ae85 ("openvswitch: add Ethernet push and pop actions")
Signed-off-by: Jaime Caamaño Ruiz <jcaamano@suse.com>
---
net/openvswitch/flow_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index a70097ecf33c..865ecef68196 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -3030,7 +3030,7 @@ static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
* is already present */
if (mac_proto != MAC_PROTO_NONE)
return -EINVAL;
- mac_proto = MAC_PROTO_NONE;
+ mac_proto = MAC_PROTO_ETHERNET;
break;
case OVS_ACTION_ATTR_POP_ETH:
@@ -3038,7 +3038,7 @@ static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
return -EINVAL;
if (vlan_tci & htons(VLAN_TAG_PRESENT))
return -EINVAL;
- mac_proto = MAC_PROTO_ETHERNET;
+ mac_proto = MAC_PROTO_NONE;
break;
case OVS_ACTION_ATTR_PUSH_NSH:
--
2.16.4
^ permalink raw reply related
* Re: [PATCH iproute2] Use libbsd for strlcpy if available
From: Luca Boccassi @ 2018-10-31 17:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, dsahern
In-Reply-To: <20181031080922.2ff123eb@xeon-e3>
[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]
On Wed, 2018-10-31 at 08:09 -0700, Stephen Hemminger wrote:
> On Mon, 29 Oct 2018 10:46:50 +0000
> Luca Boccassi <bluca@debian.org> wrote:
>
> > If libc does not provide strlcpy check for libbsd with pkg-config
> > to
> > avoid relying on inline version.
> >
> > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > ---
> > This allows distro maintainers to be able to choose to reduce
> > duplication and let this code be maintained in one place, in the
> > external library.
> >
>
> I like the idea, but it causes warnings on Debian testing, and maybe
> other distros.
>
> ipnetns.c:2: warning: "_ATFILE_SOURCE" redefined
> #define _ATFILE_SOURCE
>
> In file included from /usr/include/x86_64-linux-gnu/bits/libc-header-
> start.h:33,
> from /usr/include/string.h:26,
> from /usr/include/bsd/string.h:30,
> from <command-line>:
> /usr/include/features.h:326: note: this is the location of the
> previous definition
> # define _ATFILE_SOURCE 1
>
>
> Please figure out how to handle this and resubmit. SUSE open build
> service might
> also work to test multiple distro's
Ah missed that. That happens because features.h defines _ATFILE_SOURCE
to 1, but ip/ipnetns.c defines it without a value. According to the
spec either way doesn't change the result.
This happens because of the quick hack of using -include
/usr/include/bsd/string.h which was, well, a quick hack and didn't
require to add the include manually everywhere strlcpy was used, even
in the future. But it has side effects like this.
So I'll send v2 with a less hacky fix, which means defining HAVE_LIBBSD
in configure and doing #ifdef HAVE_LIBBSD #include <bsd/string.h> in
every file. It also means that this needs to be done for every future
use of strlcpy, or the build with libbsd will break.
If you or David prefer the hacky way, I can instead send a v3 that does
the quick hack, and also changes _ATFILE_SOURCE to 1 so that there is
no complaint from the compiler, as the values will be the same.
--
Kind regards,
Luca Boccassi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH iproute2 v2] Use libbsd for strlcpy if available
From: Luca Boccassi @ 2018-10-31 18:00 UTC (permalink / raw)
To: netdev; +Cc: stephen, dsahern
In-Reply-To: <20181029104650.24924-1-bluca@debian.org>
If libc does not provide strlcpy check for libbsd with pkg-config to
avoid relying on inline version.
Signed-off-by: Luca Boccassi <bluca@debian.org>
---
Changed from -include /usr/include/bsd/string.h hack to HAVE_LIBBSD
and proper includes in each file that uses strlcpy.
The hack causes a compiler warning as ip/ipnetns.c defines
_ATFILE_SOURCE without a value, but system headers use 1, so there's
a mismatch.
configure | 11 +++++++++--
genl/ctrl.c | 3 +++
ip/iplink.c | 3 +++
ip/ipnetns.c | 3 +++
ip/iproute_lwtunnel.c | 3 +++
ip/ipvrf.c | 3 +++
ip/ipxfrm.c | 3 +++
ip/tunnel.c | 3 +++
ip/xfrm_state.c | 3 +++
lib/bpf.c | 3 +++
lib/fs.c | 3 +++
lib/inet_proto.c | 3 +++
misc/ss.c | 3 +++
tc/em_ipset.c | 3 +++
tc/m_pedit.c | 3 +++
15 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 744d6282..c5655978 100755
--- a/configure
+++ b/configure
@@ -330,8 +330,15 @@ EOF
then
echo "no"
else
- echo 'CFLAGS += -DNEED_STRLCPY' >>$CONFIG
- echo "yes"
+ if ${PKG_CONFIG} libbsd --exists
+ then
+ echo 'CFLAGS += -DHAVE_LIBBSD' `${PKG_CONFIG} libbsd --cflags` >>$CONFIG
+ echo 'LDLIBS +=' `${PKG_CONFIG} libbsd --libs` >> $CONFIG
+ echo "no"
+ else
+ echo 'CFLAGS += -DNEED_STRLCPY' >>$CONFIG
+ echo "yes"
+ fi
fi
rm -f $TMPDIR/strtest.c $TMPDIR/strtest
}
diff --git a/genl/ctrl.c b/genl/ctrl.c
index 6133336a..fef6aaa9 100644
--- a/genl/ctrl.c
+++ b/genl/ctrl.c
@@ -18,6 +18,9 @@
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include "utils.h"
#include "genl_utils.h"
diff --git a/ip/iplink.c b/ip/iplink.c
index b5519201..067f5409 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -24,6 +24,9 @@
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <sys/ioctl.h>
#include <stdbool.h>
#include <linux/mpls.h>
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 0eac18cf..da019d76 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -8,6 +8,9 @@
#include <sys/syscall.h>
#include <stdio.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <sched.h>
#include <fcntl.h>
#include <dirent.h>
diff --git a/ip/iproute_lwtunnel.c b/ip/iproute_lwtunnel.c
index 8f497015..2285bc1d 100644
--- a/ip/iproute_lwtunnel.c
+++ b/ip/iproute_lwtunnel.c
@@ -16,6 +16,9 @@
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <linux/ila.h>
#include <linux/lwtunnel.h>
#include <linux/mpls_iptunnel.h>
diff --git a/ip/ipvrf.c b/ip/ipvrf.c
index 8a6b7f97..8572b4f2 100644
--- a/ip/ipvrf.c
+++ b/ip/ipvrf.c
@@ -21,6 +21,9 @@
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <dirent.h>
#include <errno.h>
#include <limits.h>
diff --git a/ip/ipxfrm.c b/ip/ipxfrm.c
index 17ab4abe..b02f30a6 100644
--- a/ip/ipxfrm.c
+++ b/ip/ipxfrm.c
@@ -28,6 +28,9 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <sys/types.h>
#include <sys/socket.h>
#include <time.h>
diff --git a/ip/tunnel.c b/ip/tunnel.c
index d0d55f37..73abb2e2 100644
--- a/ip/tunnel.c
+++ b/ip/tunnel.c
@@ -24,6 +24,9 @@
#include <stdio.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <unistd.h>
#include <errno.h>
#include <sys/types.h>
diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
index e8c01746..18e0c6fa 100644
--- a/ip/xfrm_state.c
+++ b/ip/xfrm_state.c
@@ -27,6 +27,9 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <netdb.h>
#include "utils.h"
#include "xfrm.h"
diff --git a/lib/bpf.c b/lib/bpf.c
index 45f279fa..35d7c45a 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -15,6 +15,9 @@
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <stdbool.h>
#include <stdint.h>
#include <errno.h>
diff --git a/lib/fs.c b/lib/fs.c
index 86efd4ed..af36bea0 100644
--- a/lib/fs.c
+++ b/lib/fs.c
@@ -20,6 +20,9 @@
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <errno.h>
#include <limits.h>
diff --git a/lib/inet_proto.c b/lib/inet_proto.c
index 0836a4c9..b379d8f8 100644
--- a/lib/inet_proto.c
+++ b/lib/inet_proto.c
@@ -18,6 +18,9 @@
#include <netinet/in.h>
#include <netdb.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include "rt_names.h"
#include "utils.h"
diff --git a/misc/ss.c b/misc/ss.c
index 4d12fb5d..c472fbd9 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -19,6 +19,9 @@
#include <sys/sysmacros.h>
#include <netinet/in.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <errno.h>
#include <netdb.h>
#include <arpa/inet.h>
diff --git a/tc/em_ipset.c b/tc/em_ipset.c
index 48b287f5..550b2101 100644
--- a/tc/em_ipset.c
+++ b/tc/em_ipset.c
@@ -20,6 +20,9 @@
#include <netdb.h>
#include <unistd.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <stdlib.h>
#include <getopt.h>
diff --git a/tc/m_pedit.c b/tc/m_pedit.c
index 2aeb56d9..baacc80d 100644
--- a/tc/m_pedit.c
+++ b/tc/m_pedit.c
@@ -23,6 +23,9 @@
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
+#ifdef HAVE_LIBBSD
+#include <bsd/string.h>
+#endif
#include <dlfcn.h>
#include "utils.h"
#include "tc_util.h"
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net-next v2 5/6] net/ncsi: Reset channel state in ncsi_start_dev()
From: Samuel Mendoza-Jonas @ 2018-11-01 4:30 UTC (permalink / raw)
To: Justin.Lee1, netdev; +Cc: davem, linux-kernel, openbmc
In-Reply-To: <2be6038ad8cb43559495e6f84e97b8a6@AUSX13MPS306.AMER.DELL.COM>
On Tue, 2018-10-30 at 18:23 +0000, Justin.Lee1@Dell.com wrote:
> > On Fri, 2018-10-26 at 17:25 +0000, Justin.Lee1@Dell.com wrote:
> > > Hi Samuel,
> > >
> > > I noticed a few issues and commented below.
> > >
> > > Thanks,
> > > Justin
> > >
> > >
> > > > /* Resources */
> > > > +int ncsi_reset_dev(struct ncsi_dev *nd);
> > > > void ncsi_start_channel_monitor(struct ncsi_channel *nc);
> > > > void ncsi_stop_channel_monitor(struct ncsi_channel *nc);
> > > > struct ncsi_channel *ncsi_find_channel(struct ncsi_package *np,
> > > > diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
> > > > index 014321ad31d3..9bad03e3fa5e 100644
> > > > --- a/net/ncsi/ncsi-manage.c
> > > > +++ b/net/ncsi/ncsi-manage.c
> > > > @@ -550,8 +550,10 @@ static void ncsi_suspend_channel(struct ncsi_dev_priv *ndp)
> > > > spin_lock_irqsave(&nc->lock, flags);
> > > > nc->state = NCSI_CHANNEL_INACTIVE;
> > > > spin_unlock_irqrestore(&nc->lock, flags);
> > > > - ncsi_process_next_channel(ndp);
> > > > -
> > > > + if (ndp->flags & NCSI_DEV_RESET)
> > > > + ncsi_reset_dev(nd);
> > > > + else
> > > > + ncsi_process_next_channel(ndp);
> > > > break;
> > > > default:
> > > > netdev_warn(nd->dev, "Wrong NCSI state 0x%x in suspend\n",
> > > > @@ -1554,7 +1556,7 @@ int ncsi_start_dev(struct ncsi_dev *nd)
> > > > return 0;
> > > > }
> > > >
> > > > - return ncsi_choose_active_channel(nd);
> > > > + return ncsi_reset_dev(nd);
> > >
> > > If there is no available channel due to the whitelist, ncsi_start_dev() function will return failed
> > > Status and the network interface may fail to bring up too. It is possible for user to disable all
> > > channels and leave the interface up for checking the LOM status.
> > >
> >
> > I'm not sure that that is a bug, or at least not in the scope of this
> > series. If the whitelist is set such that no channels are valid then
> > there's nothing for NCSI to do. If we want to do something like always
> > monitor all channels then that would be best to do in another patch.
> >
> > > > }
> > > > EXPORT_SYMBOL_GPL(ncsi_start_dev);
> > >
> > > Also, if I send set_package_mask and set_channel_mask commands back to back in a program,
> > > the state machine doesn't work well. If I use command line and wait for it to complete for
> > > each step, then it is fine.
> >
> > Yeah that's not great; probably hitting some corner cases in the NCSI
> > locking. I'll look into the multi-channel related stuff but I have a
> > feeling that if you tried this with the existing set/clear commands you
> > would probably hit something similar, especially on your dual core
> > platform. If so this is probably something to fix separately.
> >
>
> It is possible that it is causing by the following code in ncsi_reset_dev() function.
> The state might be overwritten and the previous operation is interrupted.
>
> spin_lock_irqsave(&ndp->lock, flags);
> ndp->flags |= NCSI_DEV_RESET;
> ndp->active_channel = active;
> ndp->active_package = active->package;
> spin_unlock_irqrestore(&ndp->lock, flags);
>
> nd->state = ncsi_dev_state_suspend;
Yep, we should probably add a check before calling ncsi_reset_dev() in
the netlink code if we're already in reset, and check in ncsi_reset_dev()
if we mid-configuration.
For your trace below can you share exactly which commands you were
sending? Those messages aren't upstream so it's not 100% clear what's
being sent.
Thanks!
Sam
>
> > > npcm7xx-emc f0825000.eth eth2: NCSI: Multi-package enabled on ifindex 2, mask 0x00000001
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_stop_channel_monitor() - pkg 0 ch 0
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_dev_work()
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_suspend_channel() - pkg 0 ch 0 state 0400
> > > npcm7xx-emc f0825000.eth eth2: NCSI: pkg 0 ch 0 set as preferred channel
> > > npcm7xx-emc f0825000.eth eth2: NCSI: Multi-channel enabled on ifindex 2, mask 0x00000003
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_stop_channel_monitor() - pkg 0 ch 1
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_dev_work()
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_suspend_channel() - pkg 0 ch 1 state 0400
> > > npcm7xx-emc f0825000.eth eth2: NCSI: Package 1 set to all channels disabled
> > > npcm7xx-emc f0825000.eth eth2: NCSI: Multi-channel enabled on ifindex 2, mask 0x00000000
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel()
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel() - pkg 0
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel() - pass pkg whitelist
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel() - ch 0
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel() - pass ch whitelist
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel() - skip
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel() - ch 1
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel() - pass ch whitelist
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel() - skip
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel() - next pkg
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_choose_active_channel() - pkg 1
> > > npcm7xx-emc f0825000.eth eth2: NCSI: No channel found to configure!
> > > npcm7xx-emc f0825000.eth eth2: NCSI interface down
> > > npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_dev_work()
> > > npcm7xx-emc f0825000.eth eth2: Wrong NCSI state 0x100 in workqueue
> > >
> > > All masks are set correctly, but you can see the PS column is not right and channel doesn't
> > > configure correctly.
> > >
> > > /sys/kernel/debug/ncsi_protocol# cat ncsi_device_status
> > > IFIDX IFNAME NAME PID CID RX TX MP MC WP WC PC PS LS RU CR NQ HA
> > > ===================================================================
> > > 2 eth2 ncsi0 000 000 1 1 1 1 1 1 1 0 1 1 1 0 1
> > > 2 eth2 ncsi1 000 001 1 0 1 1 1 1 0 0 1 1 1 0 1
> > > 2 eth2 ncsi2 001 000 0 0 1 1 0 0 0 0 1 1 1 0 1
> > > 2 eth2 ncsi3 001 001 0 0 1 1 0 0 0 0 1 1 1 0 1
> > > ===================================================================
> > > MP: Multi-mode Package WP: Whitelist Package
> > > MC: Multi-mode Channel WC: Whitelist Channel
> > > PC: Primary Channel
> > > PS: Poll Status
> > > LS: Link Status
> > > RU: Running
> > > CR: Carrier OK
> > > NQ: Queue Stopped
> > > HA: Hardware Arbitration
> > >
> > > PS column is getting from (int)nc->monitor.enabled.
>
>
^ permalink raw reply
* Re: [Patch net] net: make pskb_trim_rcsum_slow() robust
From: David Miller @ 2018-10-31 19:36 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, edumazet
In-Reply-To: <20181030003515.12075-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 29 Oct 2018 17:35:15 -0700
> Most callers of pskb_trim_rcsum() simply drops the skb when
> it fails, however, ip_check_defrag() still continues to pass
> the skb up to stack. In that case, we should restore its previous
> csum if __pskb_trim() fails.
>
> Found this during code review.
>
> Fixes: 88078d98d1bb ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends")
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
I kind of agree with Eric that we should make all callers, including
ip_check_defrag(), fail just as with any memory allocation failure.
^ permalink raw reply
* Re: [PATCH 1/2] net: add an identifier name for 'struct sock *'
From: David Miller @ 2018-10-31 19:37 UTC (permalink / raw)
To: tsu.yubo; +Cc: yuzibode, netdev
In-Reply-To: <e71ca1167e90b50d11c4024e6bbd30c18c9e826b.1540868768.git.tsu.yubo@gmail.com>
From: Bo YU <tsu.yubo@gmail.com>
Date: Mon, 29 Oct 2018 23:42:09 -0400
> Fix a warning from checkpatch:
> function definition argument 'struct sock *' should also have an
> identifier name in include/net/af_unix.h.
>
> Signed-off-by: Bo YU <tsu.yubo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] net: drop a space before tabs
From: David Miller @ 2018-10-31 19:38 UTC (permalink / raw)
To: tsu.yubo; +Cc: yuzibode, netdev
In-Reply-To: <fd9196479a6994755968e57bbe412a962cc77cf3.1540868768.git.tsu.yubo@gmail.com>
From: Bo YU <tsu.yubo@gmail.com>
Date: Mon, 29 Oct 2018 23:42:10 -0400
> Fix a warning from checkpatch.pl:'please no space before tabs'
> in include/net/af_unix.h
>
> Signed-off-by: Bo YU <tsu.yubo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net/mlx5e: fix csum adjustments caused by RXFCS
From: David Miller @ 2018-10-31 19:41 UTC (permalink / raw)
To: edumazet
Cc: netdev, eric.dumazet, eranbe, saeedm, dmichail, xiyou.wangcong,
pstaszewski
In-Reply-To: <20181030075725.195824-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 30 Oct 2018 00:57:25 -0700
> As shown by Dmitris, we need to use csum_block_add() instead of csum_add()
> when adding the FCS contribution to skb csum.
>
> Before 4.18 (more exactly commit 88078d98d1bb "net: pskb_trim_rcsum()
> and CHECKSUM_COMPLETE are friends"), the whole skb csum was thrown away,
> so RXFCS changes were ignored.
>
> Then before commit d55bef5059dd ("net: fix pskb_trim_rcsum_slow() with
> odd trim offset") both mlx5 and pskb_trim_rcsum_slow() bugs were canceling
> each other.
>
> Now we fixed pskb_trim_rcsum_slow() we need to fix mlx5.
>
> Note that this patch also rewrites mlx5e_get_fcs() to :
>
> - Use skb_header_pointer() instead of reinventing it.
> - Use __get_unaligned_cpu32() to avoid possible non aligned accesses
> as Dmitris pointed out.
>
> Fixes: 902a545904c7 ("net/mlx5e: When RXFCS is set, add FCS data into checksum calculation")
> Reported-by: Paweł Staszewski <pstaszewski@itcare.pl>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [Patch V5 net 00/11] Bugfix for the HNS3 driver
From: David Miller @ 2018-10-31 19:42 UTC (permalink / raw)
To: tanhuazhong
Cc: sergei.shtylyov, joe, netdev, linuxarm, salil.mehta, yisen.zhuang,
lipeng321, linyunsheng
In-Reply-To: <1540907453-42276-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Tue, 30 Oct 2018 21:50:42 +0800
> This patch series include bugfix for the HNS3 ethernet
> controller driver.
>
> Change log:
> V4->V5:
> Fixes comments from Joe Perches & Sergei Shtylyov
> V3->V4:
> Fixes comments from Sergei Shtylyov
> V2->V3:
> Fixes comments from Sergei Shtylyov
> V1->V2:
> Fixes the compilation break reported by kbuild test robot
> http://patchwork.ozlabs.org/patch/989818/
Series applied.
^ permalink raw reply
* [net 1/8] igb: shorten maximum PHC timecounter update interval
From: Jeff Kirsher @ 2018-10-31 19:42 UTC (permalink / raw)
To: davem
Cc: Miroslav Lichvar, netdev, nhorman, sassmann, Jacob Keller,
Richard Cochran, Thomas Gleixner, Jeff Kirsher
In-Reply-To: <20181031194254.16417-1-jeffrey.t.kirsher@intel.com>
From: Miroslav Lichvar <mlichvar@redhat.com>
The timecounter needs to be updated at least once per ~550 seconds in
order to avoid a 40-bit SYSTIM timestamp to be misinterpreted as an old
timestamp.
Since commit 500462a9d ("timers: Switch to a non-cascading wheel"),
scheduling of delayed work seems to be less accurate and a requested
delay of 540 seconds may actually be longer than 550 seconds. Shorten
the delay to 480 seconds to be sure the timecounter is updated in time.
This fixes an issue with HW timestamps on 82580/I350/I354 being off by
~1100 seconds for few seconds every ~9 minutes.
Cc: Jacob Keller <jacob.e.keller@intel.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_ptp.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
index 9f4d700e09df..29ced6b74d36 100644
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -51,9 +51,15 @@
*
* The 40 bit 82580 SYSTIM overflows every
* 2^40 * 10^-9 / 60 = 18.3 minutes.
+ *
+ * SYSTIM is converted to real time using a timecounter. As
+ * timecounter_cyc2time() allows old timestamps, the timecounter
+ * needs to be updated at least once per half of the SYSTIM interval.
+ * Scheduling of delayed work is not very accurate, so we aim for 8
+ * minutes to be sure the actual interval is shorter than 9.16 minutes.
*/
-#define IGB_SYSTIM_OVERFLOW_PERIOD (HZ * 60 * 9)
+#define IGB_SYSTIM_OVERFLOW_PERIOD (HZ * 60 * 8)
#define IGB_PTP_TX_TIMEOUT (HZ * 15)
#define INCPERIOD_82576 BIT(E1000_TIMINCA_16NS_SHIFT)
#define INCVALUE_82576_MASK GENMASK(E1000_TIMINCA_16NS_SHIFT - 1, 0)
--
2.17.2
^ permalink raw reply related
* [net 0/8][pull request] Intel Wired LAN Driver Updates 2018-10-31
From: Jeff Kirsher @ 2018-10-31 19:42 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann
This series contains a various collection of fixes.
Miroslav Lichvar from Red Hat or should I say IBM now? Updates the PHC
timecounter interval for igb so that it gets updated at least once
every 550 seconds.
Ngai-Mint provides a fix for fm10k to prevent a soft lockup or system
crash by adding a new condition to determine if the SM mailbox is in the
correct state before proceeding.
Jake provides several fm10k fixes, first one marks complier aborts as
non-fatal since on some platforms trigger machine check errors when the
compile aborts. Added missing device ids to the in-kernel driver. Due
to the recent fixes, bumped the driver version.
I (Jeff Kirsher) fixed a XFRM_ALGO dependency for both ixgbe and
ixgbevf. This fix was based on the original work from Arnd Bergmann,
which only fixed ixgbe.
Mitch provides a fix for i40e/avf to update the status codes, which
resolves an issue between a mis-match between i40e and the iavf driver,
which also supports the ice LAN driver.
Radoslaw fixes the ixgbe where the driver is logging a message about
spoofed packets detected when the VF is re-started with a different MAC
address.
The following are changes since commit a6b3a3fa042343e29ffaf9169f5ba3c819d4f9a2:
net: mvpp2: Fix affinity hint allocation
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue 10GbE
Jacob Keller (3):
fm10k: ensure completer aborts are marked as non-fatal after a resume
fm10k: add missing device IDs to the upstream driver
fm10k: bump driver version to match out-of-tree release
Jeff Kirsher (1):
ixgbe/ixgbevf: fix XFRM_ALGO dependency
Miroslav Lichvar (1):
igb: shorten maximum PHC timecounter update interval
Mitch Williams (1):
i40e: Update status codes
Ngai-Mint Kwan (1):
fm10k: fix SM mailbox full condition
Radoslaw Tyl (1):
ixgbe: fix MAC anti-spoofing filter after VFLR
drivers/net/ethernet/intel/Kconfig | 18 +++++++
drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 51 +++++++++++--------
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +-
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 2 +
drivers/net/ethernet/intel/fm10k/fm10k_type.h | 2 +
.../ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +-
drivers/net/ethernet/intel/igb/igb_ptp.c | 8 ++-
drivers/net/ethernet/intel/ixgbe/Makefile | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 8 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +--
.../net/ethernet/intel/ixgbe/ixgbe_sriov.c | 4 +-
drivers/net/ethernet/intel/ixgbevf/Makefile | 2 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 4 +-
.../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +-
include/linux/avf/virtchnl.h | 12 +++--
net/xfrm/Kconfig | 1 -
16 files changed, 85 insertions(+), 41 deletions(-)
--
2.17.2
^ permalink raw reply
* [net 2/8] fm10k: fix SM mailbox full condition
From: Jeff Kirsher @ 2018-10-31 19:42 UTC (permalink / raw)
To: davem; +Cc: Ngai-Mint Kwan, netdev, nhorman, sassmann, Jacob Keller,
Jeff Kirsher
In-Reply-To: <20181031194254.16417-1-jeffrey.t.kirsher@intel.com>
From: Ngai-Mint Kwan <ngai-mint.kwan@intel.com>
Current condition will always incorrectly report a full SM mailbox if an
IES API application is not running. Due to this, the
"fm10k_service_task" will be infinitely queued into the driver's
workqueue. This, in turn, will cause a "kworker" thread to report 100%
CPU utilization and might cause "soft lockup" events or system crashes.
To fix this issue, a new condition is added to determine if the SM
mailbox is in the correct state of FM10K_STATE_OPEN before proceeding.
In other words, an instance of the IES API must be running. If there is,
the remainder of the flow stays the same which is to determine if the SM
mailbox capacity has been exceeded or not and take appropriate action.
Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
index e707d717012f..74160c2095ee 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
@@ -244,7 +244,8 @@ s32 fm10k_iov_mbx(struct fm10k_intfc *interface)
}
/* guarantee we have free space in the SM mailbox */
- if (!hw->mbx.ops.tx_ready(&hw->mbx, FM10K_VFMBX_MSG_MTU)) {
+ if (hw->mbx.state == FM10K_STATE_OPEN &&
+ !hw->mbx.ops.tx_ready(&hw->mbx, FM10K_VFMBX_MSG_MTU)) {
/* keep track of how many times this occurs */
interface->hw_sm_mbx_full++;
--
2.17.2
^ permalink raw reply related
* [net 3/8] fm10k: ensure completer aborts are marked as non-fatal after a resume
From: Jeff Kirsher @ 2018-10-31 19:42 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181031194254.16417-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
VF drivers can trigger PCIe completer aborts any time they read a queue
that they don't own. Even in nominal circumstances, it is not possible
to prevent the VF driver from reading queues it doesn't own. VF drivers
may attempt to read queues it previously owned, but which it no longer
does due to a PF reset.
Normally these completer aborts aren't an issue. However, on some
platforms these trigger machine check errors. This is true even if we
lower their severity from fatal to non-fatal. Indeed, we already have
code for lowering the severity.
We could attempt to mask these errors conditionally around resets, which
is the most common time they would occur. However this would essentially
be a race between the PF and VF drivers, and we may still occasionally
see machine check exceptions on these strictly configured platforms.
Instead, mask the errors entirely any time we resume VFs. By doing so,
we prevent the completer aborts from being sent to the parent PCIe
device, and thus these strict platforms will not upgrade them into
machine check errors.
Additionally, we don't lose any information by masking these errors,
because we'll still report VFs which attempt to access queues via the
FUM_BAD_VF_QACCESS errors.
Without this change, on platforms where completer aborts cause machine
check exceptions, the VF reading queues it doesn't own could crash the
host system. Masking the completer abort prevents this, so we should
mask it for good, and not just around a PCIe reset. Otherwise malicious
or misconfigured VFs could cause the host system to crash.
Because we are masking the error entirely, there is little reason to
also keep setting the severity bit, so that code is also removed.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 48 ++++++++++++--------
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
index 74160c2095ee..5d4f1761dc0c 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
@@ -303,6 +303,28 @@ void fm10k_iov_suspend(struct pci_dev *pdev)
}
}
+static void fm10k_mask_aer_comp_abort(struct pci_dev *pdev)
+{
+ u32 err_mask;
+ int pos;
+
+ pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ERR);
+ if (!pos)
+ return;
+
+ /* Mask the completion abort bit in the ERR_UNCOR_MASK register,
+ * preventing the device from reporting these errors to the upstream
+ * PCIe root device. This avoids bringing down platforms which upgrade
+ * non-fatal completer aborts into machine check exceptions. Completer
+ * aborts can occur whenever a VF reads a queue it doesn't own.
+ */
+ pci_read_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, &err_mask);
+ err_mask |= PCI_ERR_UNC_COMP_ABORT;
+ pci_write_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, err_mask);
+
+ mmiowb();
+}
+
int fm10k_iov_resume(struct pci_dev *pdev)
{
struct fm10k_intfc *interface = pci_get_drvdata(pdev);
@@ -318,6 +340,12 @@ int fm10k_iov_resume(struct pci_dev *pdev)
if (!iov_data)
return -ENOMEM;
+ /* Lower severity of completer abort error reporting as
+ * the VFs can trigger this any time they read a queue
+ * that they don't own.
+ */
+ fm10k_mask_aer_comp_abort(pdev);
+
/* allocate hardware resources for the VFs */
hw->iov.ops.assign_resources(hw, num_vfs, num_vfs);
@@ -461,20 +489,6 @@ void fm10k_iov_disable(struct pci_dev *pdev)
fm10k_iov_free_data(pdev);
}
-static void fm10k_disable_aer_comp_abort(struct pci_dev *pdev)
-{
- u32 err_sev;
- int pos;
-
- pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ERR);
- if (!pos)
- return;
-
- pci_read_config_dword(pdev, pos + PCI_ERR_UNCOR_SEVER, &err_sev);
- err_sev &= ~PCI_ERR_UNC_COMP_ABORT;
- pci_write_config_dword(pdev, pos + PCI_ERR_UNCOR_SEVER, err_sev);
-}
-
int fm10k_iov_configure(struct pci_dev *pdev, int num_vfs)
{
int current_vfs = pci_num_vf(pdev);
@@ -496,12 +510,6 @@ int fm10k_iov_configure(struct pci_dev *pdev, int num_vfs)
/* allocate VFs if not already allocated */
if (num_vfs && num_vfs != current_vfs) {
- /* Disable completer abort error reporting as
- * the VFs can trigger this any time they read a queue
- * that they don't own.
- */
- fm10k_disable_aer_comp_abort(pdev);
-
err = pci_enable_sriov(pdev, num_vfs);
if (err) {
dev_err(&pdev->dev,
--
2.17.2
^ permalink raw reply related
* [net 7/8] i40e: Update status codes
From: Jeff Kirsher @ 2018-10-31 19:42 UTC (permalink / raw)
To: davem; +Cc: Mitch Williams, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181031194254.16417-1-jeffrey.t.kirsher@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
Add a few new status code which will be used by the ice driver, and
rename a few to make them more consistent. Error code are mapped to
similar values as in i40e_status.h, so as to be compatible with older
VF drivers not using this status enum.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +-
include/linux/avf/virtchnl.h | 12 +++++++++---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 81b0e1f8d14b..ac5698ed0b11 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -3674,7 +3674,7 @@ int i40e_vc_process_vf_msg(struct i40e_pf *pf, s16 vf_id, u32 v_opcode,
dev_err(&pf->pdev->dev, "Invalid message from VF %d, opcode %d, len %d\n",
local_vf_id, v_opcode, msglen);
switch (ret) {
- case VIRTCHNL_ERR_PARAM:
+ case VIRTCHNL_STATUS_ERR_PARAM:
return -EPERM;
default:
return -EINVAL;
diff --git a/include/linux/avf/virtchnl.h b/include/linux/avf/virtchnl.h
index 2c9756bd9c4c..b2488055fd1d 100644
--- a/include/linux/avf/virtchnl.h
+++ b/include/linux/avf/virtchnl.h
@@ -62,13 +62,19 @@
/* Error Codes */
enum virtchnl_status_code {
VIRTCHNL_STATUS_SUCCESS = 0,
- VIRTCHNL_ERR_PARAM = -5,
+ VIRTCHNL_STATUS_ERR_PARAM = -5,
+ VIRTCHNL_STATUS_ERR_NO_MEMORY = -18,
VIRTCHNL_STATUS_ERR_OPCODE_MISMATCH = -38,
VIRTCHNL_STATUS_ERR_CQP_COMPL_ERROR = -39,
VIRTCHNL_STATUS_ERR_INVALID_VF_ID = -40,
- VIRTCHNL_STATUS_NOT_SUPPORTED = -64,
+ VIRTCHNL_STATUS_ERR_ADMIN_QUEUE_ERROR = -53,
+ VIRTCHNL_STATUS_ERR_NOT_SUPPORTED = -64,
};
+/* Backward compatibility */
+#define VIRTCHNL_ERR_PARAM VIRTCHNL_STATUS_ERR_PARAM
+#define VIRTCHNL_STATUS_NOT_SUPPORTED VIRTCHNL_STATUS_ERR_NOT_SUPPORTED
+
#define VIRTCHNL_LINK_SPEED_100MB_SHIFT 0x1
#define VIRTCHNL_LINK_SPEED_1000MB_SHIFT 0x2
#define VIRTCHNL_LINK_SPEED_10GB_SHIFT 0x3
@@ -831,7 +837,7 @@ virtchnl_vc_validate_vf_msg(struct virtchnl_version_info *ver, u32 v_opcode,
case VIRTCHNL_OP_EVENT:
case VIRTCHNL_OP_UNKNOWN:
default:
- return VIRTCHNL_ERR_PARAM;
+ return VIRTCHNL_STATUS_ERR_PARAM;
}
/* few more checks */
if (err_msg_format || valid_len != msglen)
--
2.17.2
^ permalink raw reply related
* [net 4/8] fm10k: add missing device IDs to the upstream driver
From: Jeff Kirsher @ 2018-10-31 19:42 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181031194254.16417-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
The device IDs for the Ethernet SDI Adapter devices were never added to
the upstream driver. The IDs are already in the pci.ids database, and
are supported by the out-of-tree driver.
Add the device IDs now, so that the upstream driver can recognize and
load these devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 2 ++
drivers/net/ethernet/intel/fm10k/fm10k_type.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
index 02345d381303..e49fb51d3613 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
@@ -23,6 +23,8 @@ static const struct fm10k_info *fm10k_info_tbl[] = {
*/
static const struct pci_device_id fm10k_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, FM10K_DEV_ID_PF), fm10k_device_pf },
+ { PCI_VDEVICE(INTEL, FM10K_DEV_ID_SDI_FM10420_QDA2), fm10k_device_pf },
+ { PCI_VDEVICE(INTEL, FM10K_DEV_ID_SDI_FM10420_DA2), fm10k_device_pf },
{ PCI_VDEVICE(INTEL, FM10K_DEV_ID_VF), fm10k_device_vf },
/* required last entry */
{ 0, }
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_type.h b/drivers/net/ethernet/intel/fm10k/fm10k_type.h
index 3e608e493f9d..9fb9fca375e3 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_type.h
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_type.h
@@ -15,6 +15,8 @@ struct fm10k_hw;
#define FM10K_DEV_ID_PF 0x15A4
#define FM10K_DEV_ID_VF 0x15A5
+#define FM10K_DEV_ID_SDI_FM10420_QDA2 0x15D0
+#define FM10K_DEV_ID_SDI_FM10420_DA2 0x15D5
#define FM10K_MAX_QUEUES 256
#define FM10K_MAX_QUEUES_PF 128
--
2.17.2
^ permalink raw reply related
* [net 5/8] fm10k: bump driver version to match out-of-tree release
From: Jeff Kirsher @ 2018-10-31 19:42 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181031194254.16417-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
The upstream and out-of-tree drivers are once again at comparable
functionality. It's been a while since we updated the upstream driver
version, so bump it now.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_main.c b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
index 503bbc017792..5b2a50e5798f 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
@@ -11,7 +11,7 @@
#include "fm10k.h"
-#define DRV_VERSION "0.23.4-k"
+#define DRV_VERSION "0.26.1-k"
#define DRV_SUMMARY "Intel(R) Ethernet Switch Host Interface Driver"
const char fm10k_driver_version[] = DRV_VERSION;
char fm10k_driver_name[] = "fm10k";
--
2.17.2
^ permalink raw reply related
* [net 6/8] ixgbe/ixgbevf: fix XFRM_ALGO dependency
From: Jeff Kirsher @ 2018-10-31 19:42 UTC (permalink / raw)
To: davem
Cc: Jeff Kirsher, netdev, nhorman, sassmann, Arnd Bergmann,
Shannon Nelson
In-Reply-To: <20181031194254.16417-1-jeffrey.t.kirsher@intel.com>
Based on the original work from Arnd Bergmann.
When XFRM_ALGO is not enabled, the new ixgbe IPsec code produces a
link error:
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.o: In function `ixgbe_ipsec_vf_add_sa':
ixgbe_ipsec.c:(.text+0x1266): undefined reference to `xfrm_aead_get_byname'
Simply selecting XFRM_ALGO from here causes circular dependencies, so
to fix it, we probably want this slightly more complex solution that is
similar to what other drivers with XFRM offload do:
A separate Kconfig symbol now controls whether we include the IPsec
offload code. To keep the old behavior, this is left as 'default y'. The
dependency in XFRM_OFFLOAD still causes a circular dependency but is
not actually needed because this symbol is not user visible, so removing
that dependency on top makes it all work.
CC: Arnd Bergmann <arnd@arndb.de>
CC: Shannon Nelson <shannon.nelson@oracle.com>
Fixes: eda0333ac293 ("ixgbe: add VF IPsec management")
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
---
drivers/net/ethernet/intel/Kconfig | 18 ++++++++++++++++++
drivers/net/ethernet/intel/ixgbe/Makefile | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 8 ++++----
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +++---
drivers/net/ethernet/intel/ixgbevf/Makefile | 2 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 4 ++--
.../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +-
net/xfrm/Kconfig | 1 -
8 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index fd3373d82a9e..59e1bc0f609e 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -200,6 +200,15 @@ config IXGBE_DCB
If unsure, say N.
+config IXGBE_IPSEC
+ bool "IPSec XFRM cryptography-offload acceleration"
+ depends on IXGBE
+ depends on XFRM_OFFLOAD
+ default y
+ select XFRM_ALGO
+ ---help---
+ Enable support for IPSec offload in ixgbe.ko
+
config IXGBEVF
tristate "Intel(R) 10GbE PCI Express Virtual Function Ethernet support"
depends on PCI_MSI
@@ -217,6 +226,15 @@ config IXGBEVF
will be called ixgbevf. MSI-X interrupt support is required
for this driver to work correctly.
+config IXGBEVF_IPSEC
+ bool "IPSec XFRM cryptography-offload acceleration"
+ depends on IXGBEVF
+ depends on XFRM_OFFLOAD
+ default y
+ select XFRM_ALGO
+ ---help---
+ Enable support for IPSec offload in ixgbevf.ko
+
config I40E
tristate "Intel(R) Ethernet Controller XL710 Family support"
imply PTP_1588_CLOCK
diff --git a/drivers/net/ethernet/intel/ixgbe/Makefile b/drivers/net/ethernet/intel/ixgbe/Makefile
index ca6b0c458e4a..4fb0d9e3f2da 100644
--- a/drivers/net/ethernet/intel/ixgbe/Makefile
+++ b/drivers/net/ethernet/intel/ixgbe/Makefile
@@ -17,4 +17,4 @@ ixgbe-$(CONFIG_IXGBE_DCB) += ixgbe_dcb.o ixgbe_dcb_82598.o \
ixgbe-$(CONFIG_IXGBE_HWMON) += ixgbe_sysfs.o
ixgbe-$(CONFIG_DEBUG_FS) += ixgbe_debugfs.o
ixgbe-$(CONFIG_FCOE:m=y) += ixgbe_fcoe.o
-ixgbe-$(CONFIG_XFRM_OFFLOAD) += ixgbe_ipsec.o
+ixgbe-$(CONFIG_IXGBE_IPSEC) += ixgbe_ipsec.o
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index ec1b87cc4410..143bdd5ee2a0 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -769,9 +769,9 @@ struct ixgbe_adapter {
#define IXGBE_RSS_KEY_SIZE 40 /* size of RSS Hash Key in bytes */
u32 *rss_key;
-#ifdef CONFIG_XFRM_OFFLOAD
+#ifdef CONFIG_IXGBE_IPSEC
struct ixgbe_ipsec *ipsec;
-#endif /* CONFIG_XFRM_OFFLOAD */
+#endif /* CONFIG_IXGBE_IPSEC */
/* AF_XDP zero-copy */
struct xdp_umem **xsk_umems;
@@ -1008,7 +1008,7 @@ void ixgbe_store_key(struct ixgbe_adapter *adapter);
void ixgbe_store_reta(struct ixgbe_adapter *adapter);
s32 ixgbe_negotiate_fc(struct ixgbe_hw *hw, u32 adv_reg, u32 lp_reg,
u32 adv_sym, u32 adv_asm, u32 lp_sym, u32 lp_asm);
-#ifdef CONFIG_XFRM_OFFLOAD
+#ifdef CONFIG_IXGBE_IPSEC
void ixgbe_init_ipsec_offload(struct ixgbe_adapter *adapter);
void ixgbe_stop_ipsec_offload(struct ixgbe_adapter *adapter);
void ixgbe_ipsec_restore(struct ixgbe_adapter *adapter);
@@ -1036,5 +1036,5 @@ static inline int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter,
u32 *mbuf, u32 vf) { return -EACCES; }
static inline int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter,
u32 *mbuf, u32 vf) { return -EACCES; }
-#endif /* CONFIG_XFRM_OFFLOAD */
+#endif /* CONFIG_IXGBE_IPSEC */
#endif /* _IXGBE_H_ */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 0049a2becd7e..113b38e0defb 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -8694,7 +8694,7 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct sk_buff *skb,
#endif /* IXGBE_FCOE */
-#ifdef CONFIG_XFRM_OFFLOAD
+#ifdef CONFIG_IXGBE_IPSEC
if (skb->sp && !ixgbe_ipsec_tx(tx_ring, first, &ipsec_tx))
goto out_drop;
#endif
@@ -10190,7 +10190,7 @@ ixgbe_features_check(struct sk_buff *skb, struct net_device *dev,
* the TSO, so it's the exception.
*/
if (skb->encapsulation && !(features & NETIF_F_TSO_MANGLEID)) {
-#ifdef CONFIG_XFRM_OFFLOAD
+#ifdef CONFIG_IXGBE_IPSEC
if (!skb->sp)
#endif
features &= ~NETIF_F_TSO;
@@ -10883,7 +10883,7 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (hw->mac.type >= ixgbe_mac_82599EB)
netdev->features |= NETIF_F_SCTP_CRC;
-#ifdef CONFIG_XFRM_OFFLOAD
+#ifdef CONFIG_IXGBE_IPSEC
#define IXGBE_ESP_FEATURES (NETIF_F_HW_ESP | \
NETIF_F_HW_ESP_TX_CSUM | \
NETIF_F_GSO_ESP)
diff --git a/drivers/net/ethernet/intel/ixgbevf/Makefile b/drivers/net/ethernet/intel/ixgbevf/Makefile
index 297d0f0858b5..186a4bb24fde 100644
--- a/drivers/net/ethernet/intel/ixgbevf/Makefile
+++ b/drivers/net/ethernet/intel/ixgbevf/Makefile
@@ -10,5 +10,5 @@ ixgbevf-objs := vf.o \
mbx.o \
ethtool.o \
ixgbevf_main.o
-ixgbevf-$(CONFIG_XFRM_OFFLOAD) += ipsec.o
+ixgbevf-$(CONFIG_IXGBEVF_IPSEC) += ipsec.o
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index e399e1c0c54a..ecab686574b6 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -459,7 +459,7 @@ int ethtool_ioctl(struct ifreq *ifr);
extern void ixgbevf_write_eitr(struct ixgbevf_q_vector *q_vector);
-#ifdef CONFIG_XFRM_OFFLOAD
+#ifdef CONFIG_IXGBEVF_IPSEC
void ixgbevf_init_ipsec_offload(struct ixgbevf_adapter *adapter);
void ixgbevf_stop_ipsec_offload(struct ixgbevf_adapter *adapter);
void ixgbevf_ipsec_restore(struct ixgbevf_adapter *adapter);
@@ -482,7 +482,7 @@ static inline int ixgbevf_ipsec_tx(struct ixgbevf_ring *tx_ring,
struct ixgbevf_tx_buffer *first,
struct ixgbevf_ipsec_tx_data *itd)
{ return 0; }
-#endif /* CONFIG_XFRM_OFFLOAD */
+#endif /* CONFIG_IXGBEVF_IPSEC */
void ixgbe_napi_add_all(struct ixgbevf_adapter *adapter);
void ixgbe_napi_del_all(struct ixgbevf_adapter *adapter);
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 98707ee11d72..5e47ede7e832 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -4150,7 +4150,7 @@ static int ixgbevf_xmit_frame_ring(struct sk_buff *skb,
first->tx_flags = tx_flags;
first->protocol = vlan_get_protocol(skb);
-#ifdef CONFIG_XFRM_OFFLOAD
+#ifdef CONFIG_IXGBEVF_IPSEC
if (skb->sp && !ixgbevf_ipsec_tx(tx_ring, first, &ipsec_tx))
goto out_drop;
#endif
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index 4a9ee2d83158..140270a13d54 100644
--- a/net/xfrm/Kconfig
+++ b/net/xfrm/Kconfig
@@ -8,7 +8,6 @@ config XFRM
config XFRM_OFFLOAD
bool
- depends on XFRM
config XFRM_ALGO
tristate
--
2.17.2
^ permalink raw reply related
* [net 8/8] ixgbe: fix MAC anti-spoofing filter after VFLR
From: Jeff Kirsher @ 2018-10-31 19:42 UTC (permalink / raw)
To: davem; +Cc: Radoslaw Tyl, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181031194254.16417-1-jeffrey.t.kirsher@intel.com>
From: Radoslaw Tyl <radoslawx.tyl@intel.com>
This change resolves a driver bug where the driver is logging a
message that says "Spoofed packets detected". This can occur on the PF
(host) when a VF has VLAN+MACVLAN enabled and is re-started with a
different MAC address.
MAC and VLAN anti-spoofing filters are to be enabled together.
Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Acked-by: Piotr Skajewski <piotrx.skajewski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index af25a8fffeb8..5dacfc870259 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -722,8 +722,10 @@ static inline void ixgbe_vf_reset_event(struct ixgbe_adapter *adapter, u32 vf)
ixgbe_set_vmvir(adapter, vfinfo->pf_vlan,
adapter->default_up, vf);
- if (vfinfo->spoofchk_enabled)
+ if (vfinfo->spoofchk_enabled) {
hw->mac.ops.set_vlan_anti_spoofing(hw, true, vf);
+ hw->mac.ops.set_mac_anti_spoofing(hw, true, vf);
+ }
}
/* reset multicast table array for vf */
--
2.17.2
^ permalink raw reply related
* Re: [PATCH net] net: dsa: microchip: initialize mutex before use
From: David Miller @ 2018-10-31 19:52 UTC (permalink / raw)
To: Tristram.Ha; +Cc: andrew, f.fainelli, pavel, UNGLinuxDriver, netdev
In-Reply-To: <1540943149-26832-1-git-send-email-Tristram.Ha@microchip.com>
From: <Tristram.Ha@microchip.com>
Date: Tue, 30 Oct 2018 16:45:49 -0700
> @@ -1206,6 +1201,12 @@ int ksz_switch_register(struct ksz_device *dev)
> if (dev->pdata)
> dev->chip_id = dev->pdata->chip_id;
>
> + /* mutex is used in next function call. */
> + mutex_init(&dev->reg_mutex);
> + mutex_init(&dev->stats_mutex);
> + mutex_init(&dev->alu_mutex);
> + mutex_init(&dev->vlan_mutex);
> +
Please remove this comment, as per Andrew Lunn's feedback.
^ permalink raw reply
* Re: [PATCH net 0/4] mlxsw: Enable minimum shaper on MC TCs
From: David Miller @ 2018-10-31 19:57 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, mlxsw
In-Reply-To: <20181031095601.29846-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Wed, 31 Oct 2018 09:56:41 +0000
> Petr says:
>
> An MC-aware mode was introduced in commit 7b8195306694 ("mlxsw:
> spectrum: Configure MC-aware mode on mlxsw ports"). In MC-aware mode,
> BUM traffic gets a special treatment by being assigned to a separate set
> of traffic classes 8..15. Pairs of TCs 0 and 8, 1 and 9, etc., are then
> configured to strictly prioritize the lower-numbered ones. The intention
> is to prevent BUM traffic from flooding the switch and push out all UC
> traffic, which would otherwise happen, and instead give UC traffic
> precedence.
>
> However strictly prioritizing UC traffic has the effect that UC overload
> pushes out all BUM traffic, such as legitimate ARP queries. These
> packets are kept in queues for a while, but under sustained UC overload,
> their lifetime eventually expires and these packets are dropped. That is
> detrimental to network performance as well.
>
> In this patchset, MC TCs (8..15) are configured with minimum shaper of
> 200Mbps (a minimum permitted value) to allow a trickle of necessary
> control traffic to get through.
>
> First in patch #1, the QEEC register is extended with fields necessary
> to configure the minimum shaper.
>
> In patch #2, minimum shaper is enabled on TCs 8..15.
>
> In patches #3 and #4, first the MC-awareness test is tweaked to support
> the minimum shaper, and then a new test is introduced to test that MC
> traffic behaves well under UC overload.
Series applied, thanks.
^ permalink raw reply
* [PATCH bpf] libbpf: Fix compile error in libbpf_attach_type_by_name
From: Andrey Ignatov @ 2018-10-31 19:57 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team, acme
Arnaldo Carvalho de Melo reported build error in libbpf when clang
version 3.8.1-24 (tags/RELEASE_381/final) is used:
libbpf.c:2201:36: error: comparison of constant -22 with expression of
type 'const enum bpf_attach_type' is always false
[-Werror,-Wtautological-constant-out-of-range-compare]
if (section_names[i].attach_type == -EINVAL)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~
1 error generated.
Fix the error by keeping "is_attachable" property of a program in a
separate struct field instead of trying to use attach_type itself.
Fixes: commit 956b620fcf0b ("libbpf: Introduce libbpf_attach_type_by_name")
Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/lib/bpf/libbpf.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index b607be7236d3..d6e62e90e8d4 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -2084,19 +2084,19 @@ void bpf_program__set_expected_attach_type(struct bpf_program *prog,
prog->expected_attach_type = type;
}
-#define BPF_PROG_SEC_IMPL(string, ptype, eatype, atype) \
- { string, sizeof(string) - 1, ptype, eatype, atype }
+#define BPF_PROG_SEC_IMPL(string, ptype, eatype, is_attachable, atype) \
+ { string, sizeof(string) - 1, ptype, eatype, is_attachable, atype }
/* Programs that can NOT be attached. */
-#define BPF_PROG_SEC(string, ptype) BPF_PROG_SEC_IMPL(string, ptype, 0, -EINVAL)
+#define BPF_PROG_SEC(string, ptype) BPF_PROG_SEC_IMPL(string, ptype, 0, 0, 0)
/* Programs that can be attached. */
#define BPF_APROG_SEC(string, ptype, atype) \
- BPF_PROG_SEC_IMPL(string, ptype, 0, atype)
+ BPF_PROG_SEC_IMPL(string, ptype, 0, 1, atype)
/* Programs that must specify expected attach type at load time. */
#define BPF_EAPROG_SEC(string, ptype, eatype) \
- BPF_PROG_SEC_IMPL(string, ptype, eatype, eatype)
+ BPF_PROG_SEC_IMPL(string, ptype, eatype, 1, eatype)
/* Programs that can be attached but attach type can't be identified by section
* name. Kept for backward compatibility.
@@ -2108,6 +2108,7 @@ static const struct {
size_t len;
enum bpf_prog_type prog_type;
enum bpf_attach_type expected_attach_type;
+ int is_attachable;
enum bpf_attach_type attach_type;
} section_names[] = {
BPF_PROG_SEC("socket", BPF_PROG_TYPE_SOCKET_FILTER),
@@ -2198,7 +2199,7 @@ int libbpf_attach_type_by_name(const char *name,
for (i = 0; i < ARRAY_SIZE(section_names); i++) {
if (strncmp(name, section_names[i].sec, section_names[i].len))
continue;
- if (section_names[i].attach_type == -EINVAL)
+ if (!section_names[i].is_attachable)
return -EINVAL;
*attach_type = section_names[i].attach_type;
return 0;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] openvswitch: Fix push/pop ethernet validation
From: Gregory Rose @ 2018-10-31 20:13 UTC (permalink / raw)
To: Jaime Caamaño Ruiz, netdev; +Cc: pshelar
In-Reply-To: <20181031175203.23808-1-jcaamano@suse.com>
On 10/31/2018 10:52 AM, Jaime Caamaño Ruiz wrote:
> When there are both pop and push ethernet header actions among the
> actions to be applied to a packet, an unexpected EINVAL (Invalid
> argument) error is obtained. This is due to mac_proto not being reset
> correctly when those actions are validated.
>
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-October/047554.html
> Fixes: 91820da6ae85 ("openvswitch: add Ethernet push and pop actions")
> Signed-off-by: Jaime Caamaño Ruiz <jcaamano@suse.com>
> ---
> net/openvswitch/flow_netlink.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> index a70097ecf33c..865ecef68196 100644
> --- a/net/openvswitch/flow_netlink.c
> +++ b/net/openvswitch/flow_netlink.c
> @@ -3030,7 +3030,7 @@ static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
> * is already present */
> if (mac_proto != MAC_PROTO_NONE)
> return -EINVAL;
> - mac_proto = MAC_PROTO_NONE;
> + mac_proto = MAC_PROTO_ETHERNET;
> break;
>
> case OVS_ACTION_ATTR_POP_ETH:
> @@ -3038,7 +3038,7 @@ static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
> return -EINVAL;
> if (vlan_tci & htons(VLAN_TAG_PRESENT))
> return -EINVAL;
> - mac_proto = MAC_PROTO_ETHERNET;
> + mac_proto = MAC_PROTO_NONE;
> break;
>
> case OVS_ACTION_ATTR_PUSH_NSH:
Thanks Jaime!
Tested-by: Greg Rose <gvrose8192@gmail.com>
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] kretprobe: produce sane stack traces
From: kbuild test robot @ 2018-10-31 20:18 UTC (permalink / raw)
To: Aleksa Sarai
Cc: kbuild-all, Naveen N. Rao, Anil S Keshavamurthy, David S. Miller,
Masami Hiramatsu, Jonathan Corbet, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Steven Rostedt, Shuah Khan, Alexei Starovoitov,
Daniel Borkmann, Aleksa Sarai, Brendan Gregg, Christian Brauner,
Aleksa
In-Reply-To: <20181031152543.12138-2-cyphar@cyphar.com>
[-- Attachment #1: Type: text/plain, Size: 3347 bytes --]
Hi Aleksa,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.19 next-20181031]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Aleksa-Sarai/kretprobe-produce-sane-stack-traces/20181101-034104
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
kernel/events/callchain.c: In function 'get_perf_callchain':
>> kernel/events/callchain.c:201:35: error: implicit declaration of function 'current_kretprobe_instance'; did you mean 'current_top_of_stack'? [-Werror=implicit-function-declaration]
struct kretprobe_instance *ri = current_kretprobe_instance();
^~~~~~~~~~~~~~~~~~~~~~~~~~
current_top_of_stack
>> kernel/events/callchain.c:201:35: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
>> kernel/events/callchain.c:206:4: error: implicit declaration of function 'kretprobe_perf_callchain_kernel'; did you mean 'perf_callchain_kernel'? [-Werror=implicit-function-declaration]
kretprobe_perf_callchain_kernel(ri, &ctx);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
perf_callchain_kernel
cc1: some warnings being treated as errors
vim +201 kernel/events/callchain.c
178
179 struct perf_callchain_entry *
180 get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
181 u32 max_stack, bool crosstask, bool add_mark)
182 {
183 struct perf_callchain_entry *entry;
184 struct perf_callchain_entry_ctx ctx;
185 int rctx;
186
187 entry = get_callchain_entry(&rctx);
188 if (rctx == -1)
189 return NULL;
190
191 if (!entry)
192 goto exit_put;
193
194 ctx.entry = entry;
195 ctx.max_stack = max_stack;
196 ctx.nr = entry->nr = init_nr;
197 ctx.contexts = 0;
198 ctx.contexts_maxed = false;
199
200 if (kernel && !user_mode(regs)) {
> 201 struct kretprobe_instance *ri = current_kretprobe_instance();
202
203 if (add_mark)
204 perf_callchain_store_context(&ctx, PERF_CONTEXT_KERNEL);
205 if (ri)
> 206 kretprobe_perf_callchain_kernel(ri, &ctx);
207 else
208 perf_callchain_kernel(&ctx, regs);
209 }
210
211 if (user) {
212 if (!user_mode(regs)) {
213 if (current->mm)
214 regs = task_pt_regs(current);
215 else
216 regs = NULL;
217 }
218
219 if (regs) {
220 mm_segment_t fs;
221
222 if (crosstask)
223 goto exit_put;
224
225 if (add_mark)
226 perf_callchain_store_context(&ctx, PERF_CONTEXT_USER);
227
228 fs = get_fs();
229 set_fs(USER_DS);
230 perf_callchain_user(&ctx, regs);
231 set_fs(fs);
232 }
233 }
234
235 exit_put:
236 put_callchain_entry(rctx);
237
238 return entry;
239 }
240
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6493 bytes --]
^ permalink raw reply
* Re: [PATCH bpf] libbpf: Fix compile error in libbpf_attach_type_by_name
From: Arnaldo Carvalho de Melo @ 2018-10-31 20:49 UTC (permalink / raw)
To: Andrey Ignatov; +Cc: netdev, ast, daniel, kernel-team
In-Reply-To: <20181031195718.307757-1-rdna@fb.com>
Em Wed, Oct 31, 2018 at 12:57:18PM -0700, Andrey Ignatov escreveu:
> Arnaldo Carvalho de Melo reported build error in libbpf when clang
> version 3.8.1-24 (tags/RELEASE_381/final) is used:
>
> libbpf.c:2201:36: error: comparison of constant -22 with expression of
> type 'const enum bpf_attach_type' is always false
> [-Werror,-Wtautological-constant-out-of-range-compare]
> if (section_names[i].attach_type == -EINVAL)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~
> 1 error generated.
>
> Fix the error by keeping "is_attachable" property of a program in a
> separate struct field instead of trying to use attach_type itself.
Thanks, now it builds in all the previously failing systems:
# export PERF_TARBALL=http://192.168.86.4/perf/perf-4.19.0.tar.xz
# dm debian:9 fedora:25 fedora:26 fedora:27 ubuntu:16.04 ubuntu:17.10
1 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 clang version 3.8.1-24 (tags/RELEASE_381/final)
2 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1) clang version 3.9.1 (tags/RELEASE_391/final)
3 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2) clang version 4.0.1 (tags/RELEASE_401/final)
4 fedora:27 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6) clang version 5.0.2 (tags/RELEASE_502/final)
5 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609 clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
6 ubuntu:17.10 : Ok gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0 clang version 4.0.1-6 (tags/RELEASE_401/final)
#
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
I also have it tentatively applied to my perf/urgent branch, that I'll
push upstream soon.
- Arnaldo
> Fixes: commit 956b620fcf0b ("libbpf: Introduce libbpf_attach_type_by_name")
> Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
> Signed-off-by: Andrey Ignatov <rdna@fb.com>
> ---
> tools/lib/bpf/libbpf.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index b607be7236d3..d6e62e90e8d4 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -2084,19 +2084,19 @@ void bpf_program__set_expected_attach_type(struct bpf_program *prog,
> prog->expected_attach_type = type;
> }
>
> -#define BPF_PROG_SEC_IMPL(string, ptype, eatype, atype) \
> - { string, sizeof(string) - 1, ptype, eatype, atype }
> +#define BPF_PROG_SEC_IMPL(string, ptype, eatype, is_attachable, atype) \
> + { string, sizeof(string) - 1, ptype, eatype, is_attachable, atype }
>
> /* Programs that can NOT be attached. */
> -#define BPF_PROG_SEC(string, ptype) BPF_PROG_SEC_IMPL(string, ptype, 0, -EINVAL)
> +#define BPF_PROG_SEC(string, ptype) BPF_PROG_SEC_IMPL(string, ptype, 0, 0, 0)
>
> /* Programs that can be attached. */
> #define BPF_APROG_SEC(string, ptype, atype) \
> - BPF_PROG_SEC_IMPL(string, ptype, 0, atype)
> + BPF_PROG_SEC_IMPL(string, ptype, 0, 1, atype)
>
> /* Programs that must specify expected attach type at load time. */
> #define BPF_EAPROG_SEC(string, ptype, eatype) \
> - BPF_PROG_SEC_IMPL(string, ptype, eatype, eatype)
> + BPF_PROG_SEC_IMPL(string, ptype, eatype, 1, eatype)
>
> /* Programs that can be attached but attach type can't be identified by section
> * name. Kept for backward compatibility.
> @@ -2108,6 +2108,7 @@ static const struct {
> size_t len;
> enum bpf_prog_type prog_type;
> enum bpf_attach_type expected_attach_type;
> + int is_attachable;
> enum bpf_attach_type attach_type;
> } section_names[] = {
> BPF_PROG_SEC("socket", BPF_PROG_TYPE_SOCKET_FILTER),
> @@ -2198,7 +2199,7 @@ int libbpf_attach_type_by_name(const char *name,
> for (i = 0; i < ARRAY_SIZE(section_names); i++) {
> if (strncmp(name, section_names[i].sec, section_names[i].len))
> continue;
> - if (section_names[i].attach_type == -EINVAL)
> + if (!section_names[i].is_attachable)
> return -EINVAL;
> *attach_type = section_names[i].attach_type;
> return 0;
> --
> 2.17.1
^ 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