* Re: [PATCH net-next v10] openvswitch: enable NSH support
From: Jiri Benc @ 2017-09-26 11:05 UTC (permalink / raw)
To: Yi Yang
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA, e,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1506401236-5716-1-git-send-email-yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Tue, 26 Sep 2017 12:47:16 +0800, Yi Yang wrote:
> + return ((ret != 0) ? false : true);
I'm not going to review this version but this caught my eye - I pointed
out this silly construct in my review of v9. I can understand that
working late in the night and rewriting the code back and forth, one
could end up with such construct and overlook it at the final
self-review before submission. Happens to everyone.
But leaving this after a review pointed it out means you're not paying
enough attention to your work. Even the fact that you sent v10 so
shortly after v9 means you did not spend the needed time on reflecting
on the review and that you did not properly test the new version. And
I told you exactly this before.
Honestly, I'm starting to be tired with reviewing your patch again and
again and pointing out silly mistakes like this one and repeating basic
things to you again and again.
Jiri
^ permalink raw reply
* [PATCH] lib: fix multiple strlcpy definition
From: Baruch Siach @ 2017-09-26 11:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Baruch Siach, Phil Sutter
Some C libraries, like uClibc and musl, provide BSD compatible
strlcpy(). Add check_strlcpy() to configure, and avoid defining strlcpy
and strlcat when the C library provides them.
This fixes the following static link error with uClibc-ng:
.../sysroot/usr/lib/libc.a(strlcpy.os): In function `strlcpy':
strlcpy.c:(.text+0x0): multiple definition of `strlcpy'
../lib/libutil.a(utils.o):utils.c:(.text+0x1ddc): first defined here
collect2: error: ld returned 1 exit status
Cc: Phil Sutter <phil@nwl.cc>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
configure | 24 ++++++++++++++++++++++++
lib/Makefile | 4 ++++
lib/utils.c | 2 ++
3 files changed, 30 insertions(+)
diff --git a/configure b/configure
index 7be8fb113cc9..787b2e061af9 100755
--- a/configure
+++ b/configure
@@ -326,6 +326,27 @@ EOF
rm -f $TMPDIR/dbtest.c $TMPDIR/dbtest
}
+check_strlcpy()
+{
+ cat >$TMPDIR/strtest.c <<EOF
+#include <string.h>
+int main(int argc, char **argv) {
+ char dst[10];
+ strlcpy("test", dst, sizeof(dst));
+ return 0;
+}
+EOF
+ $CC -I$INCLUDE -o $TMPDIR/strtest $TMPDIR/strtest.c >/dev/null 2>&1
+ if [ $? -eq 0 ]
+ then
+ echo "no"
+ else
+ echo "NEED_STRLCPY:=y" >>$CONFIG
+ echo "yes"
+ fi
+ rm -f $TMPDIR/strtest.c $TMPDIR/strtest
+}
+
quiet_config()
{
cat <<EOF
@@ -397,6 +418,9 @@ check_mnl
echo -n "Berkeley DB: "
check_berkeley_db
+echo -n "need for strlcpy: "
+check_strlcpy
+
echo
echo -n "docs:"
check_docs
diff --git a/lib/Makefile b/lib/Makefile
index 0fbdf4c31f50..132ad00c3335 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -1,5 +1,9 @@
include ../config.mk
+ifeq ($(NEED_STRLCPY),y)
+ CFLAGS += -DNEED_STRLCPY
+endif
+
CFLAGS += -fPIC
UTILOBJ = utils.o rt_names.o ll_types.o ll_proto.o ll_addr.o \
diff --git a/lib/utils.c b/lib/utils.c
index bbd3cbc46a0e..240e7426a810 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -1231,6 +1231,7 @@ int get_real_family(int rtm_type, int rtm_family)
return rtm_family;
}
+#ifdef NEED_STRLCPY
size_t strlcpy(char *dst, const char *src, size_t size)
{
size_t srclen = strlen(src);
@@ -1253,3 +1254,4 @@ size_t strlcat(char *dst, const char *src, size_t size)
return dlen + strlcpy(dst + dlen, src, size - dlen);
}
+#endif
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v2 net-next 0/7] net: speedup netns create/delete time
From: Tariq Toukan @ 2017-09-26 11:21 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller
Cc: netdev, Eric W . Biederman, Eric Dumazet, Majd Dibbiny,
Yonatan Cohen, Eran Ben Elisha
In-Reply-To: <20170919232709.14690-1-edumazet@google.com>
On 20/09/2017 2:27 AM, Eric Dumazet wrote:
> When rate of netns creation/deletion is high enough,
> we observe softlockups in cleanup_net() caused by huge list
> of netns and way too many rcu_barrier() calls.
>
> This patch series does some optimizations in kobject,
> and add batching to tunnels so that netns dismantles are
> less costly.
>
> IPv6 addrlabels also get a per netns list, and tcp_metrics
> also benefit from batch flushing.
>
> This gives me one order of magnitude gain.
> (~50 ms -> ~5 ms for one netns create/delete pair)
>
...
>
> Eric Dumazet (7):
> kobject: add kobject_uevent_net_broadcast()
> kobject: copy env blob in one go
> kobject: factorize skb setup in kobject_uevent_net_broadcast()
> ipv6: addrlabel: per netns list
> tcp: batch tcp_net_metrics_exit
> ipv6: speedup ipv6 tunnels dismantle
> ipv4: speedup ipv6 tunnels dismantle
>
> include/net/ip_tunnels.h | 3 +-
> include/net/netns/ipv6.h | 5 +++
> lib/kobject_uevent.c | 94 ++++++++++++++++++++++++++----------------------
> net/ipv4/ip_gre.c | 22 +++++-------
> net/ipv4/ip_tunnel.c | 12 +++++--
> net/ipv4/ip_vti.c | 7 ++--
> net/ipv4/ipip.c | 7 ++--
> net/ipv4/tcp_metrics.c | 14 +++++---
> net/ipv6/addrlabel.c | 81 ++++++++++++++++-------------------------
> net/ipv6/ip6_gre.c | 8 +++--
> net/ipv6/ip6_tunnel.c | 20 ++++++-----
> net/ipv6/ip6_vti.c | 23 +++++++-----
> net/ipv6/sit.c | 9 +++--
> 13 files changed, 157 insertions(+), 148 deletions(-)
>
Hi Eric,
We see a regression introduced in this series, specifically in the
patches touching lib/kobject_uevent.c.
We tried to figure out what is wrong there, but couldn't point it out.
Bug is that mlx4 driver restart fails, because mlx4_core is still in use.
According to module dependencies, both mlx4_en and mlx4_ib should have
been unloaded at this point
Please see log below.
This looks to be some kind of a race, as the repro is not deterministic.
Probably the en/ib modules are now mistakenly reloaded.
Any idea what could this be?
Regards,
Tariq
[root@reg-l-vrt-41016-009 ~]# /etc/init.d/openibd stop
Unloading HCA driver: [ OK ]
[root@reg-l-vrt-41016-009 ~]# /etc/init.d/openibd start
Loading HCA driver and Access Layer: [ OK ]
[root@reg-l-vrt-41016-009 ~]# /etc/init.d/openibd stop
Unloading mlx4_core [FAILED]
rmmod: ERROR: Module mlx4_core is in use
^ permalink raw reply
* [PATCH net-next v4 0/4] rtnetlink: preparation patches for further rtnl lock pushdown/removal
From: Florian Westphal @ 2017-09-26 11:58 UTC (permalink / raw)
To: netdev
Patches split large rtnl_fill_ifinfo into smaller chunks
to better see which parts
1. require rtnl
2. do not require it at all
3. rely on rtnl locking now but could be converted
Changes since v3:
I dropped the 'ifalias' patch, I have a change to decouple ifalias and
rtnl mutex, I will send it once this series has been merged.
^ permalink raw reply
* [PATCH net-next v4 1/4] rtnetlink: add helper to put master and link ifindexes
From: Florian Westphal @ 2017-09-26 11:58 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170926115843.12013-1-fw@strlen.de>
rtnl_fill_ifinfo currently requires caller to hold the rtnl mutex.
Unfortunately the function is quite large which makes it harder to see
which spots require the lock, which spots assume it and which ones could
do without.
Add helpers to factor out the ifindex dumping, one can use rcu to avoid
rtnl dependency.
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
No changes in v4.
net/core/rtnetlink.c | 32 +++++++++++++++++++++++++++-----
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a78fd61da0ec..c801212ee40e 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1307,6 +1307,31 @@ static u32 rtnl_get_event(unsigned long event)
return rtnl_event_type;
}
+static int put_master_ifindex(struct sk_buff *skb, struct net_device *dev)
+{
+ const struct net_device *upper_dev;
+ int ret = 0;
+
+ rcu_read_lock();
+
+ upper_dev = netdev_master_upper_dev_get_rcu(dev);
+ if (upper_dev)
+ ret = nla_put_u32(skb, IFLA_MASTER, upper_dev->ifindex);
+
+ rcu_read_unlock();
+ return ret;
+}
+
+static int nla_put_iflink(struct sk_buff *skb, const struct net_device *dev)
+{
+ int ifindex = dev_get_iflink(dev);
+
+ if (dev->ifindex == ifindex)
+ return 0;
+
+ return nla_put_u32(skb, IFLA_LINK, ifindex);
+}
+
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,
@@ -1316,7 +1341,6 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
struct nlmsghdr *nlh;
struct nlattr *af_spec;
struct rtnl_af_ops *af_ops;
- struct net_device *upper_dev = netdev_master_upper_dev_get(dev);
ASSERT_RTNL();
nlh = nlmsg_put(skb, pid, seq, type, sizeof(*ifm), flags);
@@ -1345,10 +1369,8 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
#ifdef CONFIG_RPS
nla_put_u32(skb, IFLA_NUM_RX_QUEUES, dev->num_rx_queues) ||
#endif
- (dev->ifindex != dev_get_iflink(dev) &&
- nla_put_u32(skb, IFLA_LINK, dev_get_iflink(dev))) ||
- (upper_dev &&
- nla_put_u32(skb, IFLA_MASTER, upper_dev->ifindex)) ||
+ nla_put_iflink(skb, dev) ||
+ put_master_ifindex(skb, dev) ||
nla_put_u8(skb, IFLA_CARRIER, netif_carrier_ok(dev)) ||
(dev->qdisc &&
nla_put_string(skb, IFLA_QDISC, dev->qdisc->ops->id)) ||
--
2.13.5
^ permalink raw reply related
* [PATCH net-next v4 2/4] rtnetlink: add helpers to dump vf information
From: Florian Westphal @ 2017-09-26 11:58 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170926115843.12013-1-fw@strlen.de>
similar to earlier patches, split out more parts of this function to
better see what is happening and where we assume rtnl is locked.
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
No changes in v4.
net/core/rtnetlink.c | 50 +++++++++++++++++++++++++++++++-------------------
1 file changed, 31 insertions(+), 19 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index c801212ee40e..d504e78cd01f 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1211,6 +1211,36 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
return -EMSGSIZE;
}
+static noinline_for_stack int rtnl_fill_vf(struct sk_buff *skb,
+ struct net_device *dev,
+ u32 ext_filter_mask)
+{
+ struct nlattr *vfinfo;
+ int i, num_vfs;
+
+ if (!dev->dev.parent || ((ext_filter_mask & RTEXT_FILTER_VF) == 0))
+ return 0;
+
+ num_vfs = dev_num_vf(dev->dev.parent);
+ if (nla_put_u32(skb, IFLA_NUM_VF, num_vfs))
+ return -EMSGSIZE;
+
+ if (!dev->netdev_ops->ndo_get_vf_config)
+ return 0;
+
+ vfinfo = nla_nest_start(skb, IFLA_VFINFO_LIST);
+ if (!vfinfo)
+ return -EMSGSIZE;
+
+ for (i = 0; i < num_vfs; i++) {
+ if (rtnl_fill_vfinfo(skb, dev, i, vfinfo))
+ return -EMSGSIZE;
+ }
+
+ nla_nest_end(skb, vfinfo);
+ return 0;
+}
+
static int rtnl_fill_link_ifmap(struct sk_buff *skb, struct net_device *dev)
{
struct rtnl_link_ifmap map;
@@ -1407,27 +1437,9 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
if (rtnl_fill_stats(skb, dev))
goto nla_put_failure;
- if (dev->dev.parent && (ext_filter_mask & RTEXT_FILTER_VF) &&
- nla_put_u32(skb, IFLA_NUM_VF, dev_num_vf(dev->dev.parent)))
+ if (rtnl_fill_vf(skb, dev, ext_filter_mask))
goto nla_put_failure;
- if (dev->netdev_ops->ndo_get_vf_config && dev->dev.parent &&
- ext_filter_mask & RTEXT_FILTER_VF) {
- int i;
- struct nlattr *vfinfo;
- int num_vfs = dev_num_vf(dev->dev.parent);
-
- vfinfo = nla_nest_start(skb, IFLA_VFINFO_LIST);
- if (!vfinfo)
- goto nla_put_failure;
- for (i = 0; i < num_vfs; i++) {
- if (rtnl_fill_vfinfo(skb, dev, i, vfinfo))
- goto nla_put_failure;
- }
-
- nla_nest_end(skb, vfinfo);
- }
-
if (rtnl_port_fill(skb, dev, ext_filter_mask))
goto nla_put_failure;
--
2.13.5
^ permalink raw reply related
* [PATCH net-next v4 3/4] rtnetlink: add helpers to dump netnsid information
From: Florian Westphal @ 2017-09-26 11:58 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170926115843.12013-1-fw@strlen.de>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
No changes in v4.
net/core/rtnetlink.c | 30 +++++++++++++++++++-----------
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index d504e78cd01f..d524609c587c 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1362,6 +1362,23 @@ static int nla_put_iflink(struct sk_buff *skb, const struct net_device *dev)
return nla_put_u32(skb, IFLA_LINK, ifindex);
}
+static int rtnl_fill_link_netnsid(struct sk_buff *skb,
+ const struct net_device *dev)
+{
+ if (dev->rtnl_link_ops && dev->rtnl_link_ops->get_link_net) {
+ struct net *link_net = dev->rtnl_link_ops->get_link_net(dev);
+
+ if (!net_eq(dev_net(dev), link_net)) {
+ int id = peernet2id_alloc(dev_net(dev), link_net);
+
+ if (nla_put_s32(skb, IFLA_LINK_NETNSID, id))
+ return -EMSGSIZE;
+ }
+ }
+
+ return 0;
+}
+
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,
@@ -1451,17 +1468,8 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
goto nla_put_failure;
}
- if (dev->rtnl_link_ops &&
- dev->rtnl_link_ops->get_link_net) {
- struct net *link_net = dev->rtnl_link_ops->get_link_net(dev);
-
- if (!net_eq(dev_net(dev), link_net)) {
- int id = peernet2id_alloc(dev_net(dev), link_net);
-
- if (nla_put_s32(skb, IFLA_LINK_NETNSID, id))
- goto nla_put_failure;
- }
- }
+ if (rtnl_fill_link_netnsid(skb, dev))
+ goto nla_put_failure;
if (!(af_spec = nla_nest_start(skb, IFLA_AF_SPEC)))
goto nla_put_failure;
--
2.13.5
^ permalink raw reply related
* [PATCH net-next v4 4/4] rtnetlink: rtnl_have_link_slave_info doesn't need rtnl
From: Florian Westphal @ 2017-09-26 11:58 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170926115843.12013-1-fw@strlen.de>
it can be switched to rcu.
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
No changes in v4.
net/core/rtnetlink.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index d524609c587c..e6955da0d58d 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -522,11 +522,15 @@ static size_t rtnl_link_get_af_size(const struct net_device *dev,
static bool rtnl_have_link_slave_info(const struct net_device *dev)
{
struct net_device *master_dev;
+ bool ret = false;
- master_dev = netdev_master_upper_dev_get((struct net_device *) dev);
+ rcu_read_lock();
+
+ master_dev = netdev_master_upper_dev_get_rcu((struct net_device *)dev);
if (master_dev && master_dev->rtnl_link_ops)
- return true;
- return false;
+ ret = true;
+ rcu_read_unlock();
+ return ret;
}
static int rtnl_link_slave_info_fill(struct sk_buff *skb,
--
2.13.5
^ permalink raw reply related
* Latest kernel net-next - 4.14-rc1+ / WARNING: CPU: 16 PID: 0 at net/sched/sch_hfsc.c:1385 hfsc_dequeue+0x241/0x269
From: Paweł Staszewski @ 2017-09-26 12:00 UTC (permalink / raw)
To: Linux Kernel Network Developers
[50102.787542] ------------[ cut here ]------------
[50102.787545] WARNING: CPU: 16 PID: 0 at net/sched/sch_hfsc.c:1385
hfsc_dequeue+0x241/0x269
[50102.787545] Modules linked in: ipmi_si x86_pkg_temp_thermal
[50102.787547] CPU: 16 PID: 0 Comm: swapper/16 Tainted: G W
4.14.0-rc1+ #10
[50102.787548] task: ffff88046d440000 task.stack: ffffc900032e0000
[50102.787549] RIP: 0010:hfsc_dequeue+0x241/0x269
[50102.787550] RSP: 0018:ffff88046fc83eb0 EFLAGS: 00010246
[50102.787551] RAX: 0000000000000000 RBX: ffff880456309948 RCX:
0000000000000018
[50102.787551] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffff880456309c40
[50102.787552] RBP: ffff88046fc83ed8 R08: 000000000001c000 R09:
0000000000000100
[50102.787553] R10: ffff88046fc83e98 R11: 0000000000000003 R12:
ffff880456309800
[50102.787553] R13: 000000b6459156dd R14: 0000000000000001 R15:
ffff880456309c40
[50102.787554] FS: 0000000000000000(0000) GS:ffff88046fc80000(0000)
knlGS:0000000000000000
[50102.787555] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[50102.787556] CR2: 00007fc764f21090 CR3: 000000085844a000 CR4:
00000000001606e0
[50102.787556] Call Trace:
[50102.787557] <IRQ>
[50102.787558] __qdisc_run+0xed/0x293
[50102.787560] net_tx_action+0xeb/0x18b
[50102.787562] __do_softirq+0xe4/0x23a
[50102.787564] irq_exit+0x4d/0x5b
[50102.787565] smp_apic_timer_interrupt+0xc0/0xfa
[50102.787566] apic_timer_interrupt+0x90/0xa0
[50102.787566] </IRQ>
[50102.787568] RIP: 0010:cpuidle_enter_state+0x134/0x189
[50102.787569] RSP: 0018:ffffc900032e3ea0 EFLAGS: 00000246 ORIG_RAX:
ffffffffffffff10
[50102.787570] RAX: 00002d9176d7d9f4 RBX: 0000000000000002 RCX:
000000000000001f
[50102.787570] RDX: 0000000000000000 RSI: 0000000000000010 RDI:
0000000000000000
[50102.787571] RBP: ffffc900032e3ed0 R08: 00000000ffffffd8 R09:
0000000000000003
[50102.787572] R10: ffffc900032e3e70 R11: ffff88046fc98e50 R12:
ffff88046c234400
[50102.787572] R13: 00002d9176d7d9f4 R14: 0000000000000002 R15:
00002d9176d6e845
[50102.787575] cpuidle_enter+0x12/0x14
[50102.787576] do_idle+0x113/0x16b
[50102.787578] cpu_startup_entry+0x1a/0x1f
[50102.787580] start_secondary+0xea/0xed
[50102.787581] secondary_startup_64+0xa5/0xa5
[50102.787582] Code: f6 48 3d 90 00 00 00 74 04 48 8b 70 70 49 8b 84 24
68 02 00 00 48 85 c0 74 0c 48 39 f0 72 24 48 85 f6 75 09 eb 1d 48 85 f6
75 02 <0f> ff 49 8d bc 24 48 04 00 00 48 c1 e6 06 e8 a9 62 ff ff e9 eb
[50102.787602] ---[ end trace 8558fb6f1ca3beb2 ]---
^ permalink raw reply
* usb/net/lan78xx: use-after-free in lan78xx_write_reg
From: Andrey Konovalov @ 2017-09-26 12:04 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, netdev, USB list,
LKML
Cc: Dmitry Vyukov, Kostya Serebryany, syzkaller
Hi!
I've got the following report while fuzzing the kernel with syzkaller.
On commit e19b205be43d11bff638cad4487008c48d21c103 (4.14-rc2).
==================================================================
BUG: KASAN: use-after-free in lan78xx_write_reg.isra.21+0x1a8/0x1b0
Read of size 8 at addr ffff8800683e2c40 by task kworker/0:3/2551
CPU: 0 PID: 2551 Comm: kworker/0:3 Not tainted
4.14.0-rc2-42613-g1488251d1a98 #256
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events lan78xx_deferred_multicast_write
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x292/0x395 lib/dump_stack.c:52
print_address_description+0x78/0x280 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351
kasan_report+0x23d/0x350 mm/kasan/report.c:409
__asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
lan78xx_write_reg.isra.21+0x1a8/0x1b0 drivers/net/usb/lan78xx.c:458
lan78xx_deferred_multicast_write+0x10d/0x1a0 drivers/net/usb/lan78xx.c:1042
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
worker_thread+0x221/0x1850 kernel/workqueue.c:2253
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Allocated by task 24:
save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459
kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
__kmalloc_node+0x192/0x480 mm/slub.c:3827
kmalloc_node ./include/linux/slab.h:535
kvmalloc_node+0x69/0xd0 mm/util.c:397
kvmalloc ./include/linux/mm.h:529
kvzalloc ./include/linux/mm.h:537
alloc_netdev_mqs+0x173/0xea0 net/core/dev.c:8023
alloc_etherdev_mqs+0x38/0x40 net/ethernet/eth.c:391
lan78xx_probe+0x13a/0x2f10 drivers/net/usb/lan78xx.c:3542
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
hub_port_connect drivers/usb/core/hub.c:4903
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
worker_thread+0x221/0x1850 kernel/workqueue.c:2253
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Freed by task 24:
save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459
kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
slab_free_hook mm/slub.c:1390
slab_free_freelist_hook mm/slub.c:1412
slab_free mm/slub.c:2988
kfree+0xf6/0x2f0 mm/slub.c:3919
kvfree+0x3b/0x60 mm/util.c:416
netdev_freemem net/core/dev.c:7975
free_netdev+0x304/0x3c0 net/core/dev.c:8137
lan78xx_probe+0x20cc/0x2f10 drivers/net/usb/lan78xx.c:3645
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
hub_port_connect drivers/usb/core/hub.c:4903
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
worker_thread+0x221/0x1850 kernel/workqueue.c:2253
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
The buggy address belongs to the object at ffff8800683e2100
which belongs to the cache kmalloc-8192 of size 8192
The buggy address is located 2880 bytes inside of
8192-byte region [ffff8800683e2100, ffff8800683e4100)
The buggy address belongs to the page:
page:ffffea0001a0f800 count:1 mapcount:0 mapping: (null)
index:0x0 compound_mapcount: 0
flags: 0x100000000008100(slab|head)
raw: 0100000000008100 0000000000000000 0000000000000000 0000000100030003
raw: ffffea00018fe800 0000000200000002 ffff88006c402a80 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8800683e2b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8800683e2b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8800683e2c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8800683e2c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8800683e2d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ permalink raw reply
* [PATCH] vti: fix use after free in vti_tunnel_xmit/vti6_tnl_xmit
From: Alexey Kodanev @ 2017-09-26 12:14 UTC (permalink / raw)
To: netdev; +Cc: Steffen Klassert, Herbert Xu, David Miller, Alexey Kodanev
When running LTP IPsec tests, KASan might report:
BUG: KASAN: use-after-free in vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
Read of size 4 at addr ffff880dc6ad1980 by task swapper/0/0
...
Call Trace:
<IRQ>
dump_stack+0x63/0x89
print_address_description+0x7c/0x290
kasan_report+0x28d/0x370
? vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
__asan_report_load4_noabort+0x19/0x20
vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
? vti_init_net+0x190/0x190 [ip_vti]
? save_stack_trace+0x1b/0x20
? save_stack+0x46/0xd0
dev_hard_start_xmit+0x147/0x510
? icmp_echo.part.24+0x1f0/0x210
__dev_queue_xmit+0x1394/0x1c60
...
Freed by task 0:
save_stack_trace+0x1b/0x20
save_stack+0x46/0xd0
kasan_slab_free+0x70/0xc0
kmem_cache_free+0x81/0x1e0
kfree_skbmem+0xb1/0xe0
kfree_skb+0x75/0x170
kfree_skb_list+0x3e/0x60
__dev_queue_xmit+0x1298/0x1c60
dev_queue_xmit+0x10/0x20
neigh_resolve_output+0x3a8/0x740
ip_finish_output2+0x5c0/0xe70
ip_finish_output+0x4ba/0x680
ip_output+0x1c1/0x3a0
xfrm_output_resume+0xc65/0x13d0
xfrm_output+0x1e4/0x380
xfrm4_output_finish+0x5c/0x70
Can be fixed if we get skb->len before dst_output().
Fixes: b9959fd3b0fa ("vti: switch to new ip tunnel code")
Fixes: 22e1b23dafa8 ("vti6: Support inter address family tunneling.")
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
---
net/ipv4/ip_vti.c | 3 ++-
net/ipv6/ip6_vti.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 5ed63d2..89453cf 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -168,6 +168,7 @@ static netdev_tx_t vti_xmit(struct sk_buff *skb, struct net_device *dev,
struct ip_tunnel_parm *parms = &tunnel->parms;
struct dst_entry *dst = skb_dst(skb);
struct net_device *tdev; /* Device to other host */
+ int pkt_len = skb->len;
int err;
int mtu;
@@ -229,7 +230,7 @@ static netdev_tx_t vti_xmit(struct sk_buff *skb, struct net_device *dev,
err = dst_output(tunnel->net, skb->sk, skb);
if (net_xmit_eval(err) == 0)
- err = skb->len;
+ err = pkt_len;
iptunnel_xmit_stats(dev, err);
return NETDEV_TX_OK;
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 79444a4..bcdc2d5 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -445,6 +445,7 @@ static bool vti6_state_check(const struct xfrm_state *x,
struct dst_entry *dst = skb_dst(skb);
struct net_device *tdev;
struct xfrm_state *x;
+ int pkt_len = skb->len;
int err = -1;
int mtu;
@@ -502,7 +503,7 @@ static bool vti6_state_check(const struct xfrm_state *x,
struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats);
u64_stats_update_begin(&tstats->syncp);
- tstats->tx_bytes += skb->len;
+ tstats->tx_bytes += pkt_len;
tstats->tx_packets++;
u64_stats_update_end(&tstats->syncp);
} else {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Implement full-functionality option for ECN encapsulation in tunnel
From: Pablo Neira Ayuso @ 2017-09-26 12:07 UTC (permalink / raw)
To: Vadim Fedorenko
Cc: Julian Anastasov, Wensong Zhang, Simon Horman, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller, netdev@vger.kernel.org,
lvs-devel@vger.kernel.org
In-Reply-To: <392771506413394@webcorp01h.yandex-team.ru>
On Tue, Sep 26, 2017 at 11:09:54AM +0300, Vadim Fedorenko wrote:
> Hello,
> this patch seems to be lost somewhere in upstream. Please, merge it
Applied to nf.git.
Thanks.
^ permalink raw reply
* Re: Latest kernel net-next - 4.14-rc1+ / WARNING: CPU: 16 PID: 0 at net/sched/sch_hfsc.c:1385 hfsc_dequeue+0x241/0x269
From: Paweł Staszewski @ 2017-09-26 12:11 UTC (permalink / raw)
To: Paweł Staszewski, Linux Kernel Network Developers
In-Reply-To: <00115c1c-6296-bc76-8ac2-5160aa870596@itcare.pl>
A little more in trace:
[49519.600903] ------------[ cut here ]------------
[49519.600908] WARNING: CPU: 7 PID: 31426 at net/sched/sch_hfsc.c:1385
hfsc_dequeue+0x241/0x269
[49519.600909] Modules linked in: ipmi_si x86_pkg_temp_thermal
[49519.600914] CPU: 7 PID: 31426 Comm: syslog-ng Tainted: G W
4.14.0-rc1+ #10
[49519.600915] task: ffff88086d07c100 task.stack: ffffc90006d54000
[49519.600917] RIP: 0010:hfsc_dequeue+0x241/0x269
[49519.600918] RSP: 0018:ffff88087fa439f8 EFLAGS: 00010246
[49519.600919] RAX: 0000000000000000 RBX: ffff88085b8af148 RCX:
0000000000000018
[49519.600920] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffff88085b8af440
[49519.600922] RBP: ffff88087fa43a20 R08: 0000160000000000 R09:
0000000000000000
[49519.600923] R10: ffff88087fa43960 R11: ffff880859d50a00 R12:
ffff88085b8af000
[49519.600924] R13: 000000b4266fab9b R14: 0000000000000001 R15:
ffff88085b8af440
[49519.600925] FS: 00007fad63a35700(0000) GS:ffff88087fa40000(0000)
knlGS:0000000000000000
[49519.600926] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[49519.600927] CR2: 00007f10d4a90098 CR3: 000000046bb1c005 CR4:
00000000001606e0
[49519.600928] Call Trace:
[49519.600929] <IRQ>
[49519.600932] __qdisc_run+0xed/0x293
[49519.600935] __dev_queue_xmit+0x2d2/0x4b3
[49519.600936] ? eth_header+0x27/0xab
[49519.600938] dev_queue_xmit+0xb/0xd
[49519.600939] ? dev_queue_xmit+0xb/0xd
[49519.600943] neigh_connected_output+0x9b/0xb2
[49519.600948] ip_finish_output2+0x24b/0x28f
[49519.600952] ? statistic_mt+0x30/0x72
[49519.600954] ip_finish_output+0x101/0x10d
[49519.600957] ip_output+0x56/0xa9
[49519.600959] ip_forward_finish+0x53/0x58
[49519.600961] ip_forward+0x2b2/0x308
[49519.600962] ? ip_frag_mem+0xf/0xf
[49519.600964] ip_rcv_finish+0x27c/0x287
[49519.600965] ip_rcv+0x2b0/0x300
[49519.600968] ? vlan_do_receive+0x49/0x294
[49519.600970] __netif_receive_skb_core+0x312/0x496
[49519.600972] ? tk_clock_read+0xc/0xe
[49519.600973] __netif_receive_skb+0x18/0x57
[49519.600974] ? __netif_receive_skb+0x18/0x57
[49519.600975] netif_receive_skb_internal+0x4b/0xa1
[49519.600977] napi_gro_complete+0x7a/0x7d
[49519.600977] napi_gro_flush+0x3b/0x66
[49519.600979] napi_complete_done+0x4b/0xa8
[49519.600983] ixgbe_poll+0x90c/0xeaa
[49519.600985] net_rx_action+0xd3/0x22d
[49519.600988] __do_softirq+0xe4/0x23a
[49519.600991] irq_exit+0x4d/0x5b
[49519.600992] do_IRQ+0x96/0xae
[49519.600996] common_interrupt+0x90/0x90
[49519.600997] </IRQ>
[49519.601001] RIP: 0010:do_con_write+0x2d0/0x1b13
[49519.601002] RSP: 0018:ffffc90006d57bc0 EFLAGS: 00000282 ORIG_RAX:
ffffffffffffffa2
[49519.601004] RAX: 000000000000004b RBX: 000000000000004b RCX:
000000000000fffd
[49519.601005] RDX: 00000000ffff004d RSI: 0000000000000003 RDI:
ffffffff81e751b8
[49519.601006] RBP: ffffc90006d57c68 R08: 0000000000000000 R09:
0000000000000000
[49519.601007] R10: ffff88086b64f807 R11: ffff88086d07c100 R12:
000000000000fffd
[49519.601008] R13: ffff88046c7bd400 R14: ffff88086b64f800 R15:
000000000000004b
[49519.601011] ? _raw_spin_lock+0x9/0xb
[49519.601013] con_write+0xe/0x20
[49519.601018] n_tty_write+0x101/0x3f5
[49519.601021] ? init_wait_entry+0x29/0x29
[49519.601024] tty_write+0x1a9/0x228
[49519.601026] ? n_tty_flush_buffer+0x4c/0x4c
[49519.601029] do_loop_readv_writev+0x6f/0xa1
[49519.601031] do_iter_write+0x8e/0xb8
[49519.601032] vfs_writev+0x77/0xad
[49519.601034] ? __vfs_write+0x21/0xa0
[49519.601037] ? __fget+0x25/0x56
[49519.601038] ? __fget_light+0x3b/0x46
[49519.601039] ? __fdget+0xe/0x10
[49519.601040] do_writev+0x4f/0xa1
[49519.601041] ? do_writev+0x4f/0xa1
[49519.601043] SyS_writev+0xb/0xd
[49519.601044] entry_SYSCALL_64_fastpath+0x13/0x94
[49519.601046] RIP: 0033:0x7fad66233da9
[49519.601046] RSP: 002b:00007fad63a32ac0 EFLAGS: 00000293 ORIG_RAX:
0000000000000014
[49519.601047] RAX: ffffffffffffffda RBX: 0000000001eddd08 RCX:
00007fad66233da9
[49519.601048] RDX: 0000000000000001 RSI: 0000000001edeab0 RDI:
0000000000000011
[49519.601049] RBP: 0000000001eddd08 R08: 0000000000000000 R09:
00007fad662842d0
[49519.601049] R10: 0000000000000000 R11: 0000000000000293 R12:
00007fad63a326f0
[49519.601050] R13: 00007fad4c0045c0 R14: 00007fad4c0045c0 R15:
0000000001eddcb0
[49519.601051] Code: f6 48 3d 90 00 00 00 74 04 48 8b 70 70 49 8b 84 24
68 02 00 00 48 85 c0 74 0c 48 39 f0 72 24 48 85 f6 75 09 eb 1d 48 85 f6
75 02 <0f> ff 49 8d bc 24 48 04 00 00 48 c1 e6 06 e8 a9 62 ff ff e9 eb
[49519.601065] ---[ end trace 8558fb6f1ca3beb0 ]---
W dniu 2017-09-26 o 14:00, Paweł Staszewski pisze:
> [50102.787542] ------------[ cut here ]------------
> [50102.787545] WARNING: CPU: 16 PID: 0 at net/sched/sch_hfsc.c:1385
> hfsc_dequeue+0x241/0x269
> [50102.787545] Modules linked in: ipmi_si x86_pkg_temp_thermal
> [50102.787547] CPU: 16 PID: 0 Comm: swapper/16 Tainted: G W
> 4.14.0-rc1+ #10
> [50102.787548] task: ffff88046d440000 task.stack: ffffc900032e0000
> [50102.787549] RIP: 0010:hfsc_dequeue+0x241/0x269
> [50102.787550] RSP: 0018:ffff88046fc83eb0 EFLAGS: 00010246
> [50102.787551] RAX: 0000000000000000 RBX: ffff880456309948 RCX:
> 0000000000000018
> [50102.787551] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> ffff880456309c40
> [50102.787552] RBP: ffff88046fc83ed8 R08: 000000000001c000 R09:
> 0000000000000100
> [50102.787553] R10: ffff88046fc83e98 R11: 0000000000000003 R12:
> ffff880456309800
> [50102.787553] R13: 000000b6459156dd R14: 0000000000000001 R15:
> ffff880456309c40
> [50102.787554] FS: 0000000000000000(0000) GS:ffff88046fc80000(0000)
> knlGS:0000000000000000
> [50102.787555] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [50102.787556] CR2: 00007fc764f21090 CR3: 000000085844a000 CR4:
> 00000000001606e0
> [50102.787556] Call Trace:
> [50102.787557] <IRQ>
> [50102.787558] __qdisc_run+0xed/0x293
> [50102.787560] net_tx_action+0xeb/0x18b
> [50102.787562] __do_softirq+0xe4/0x23a
> [50102.787564] irq_exit+0x4d/0x5b
> [50102.787565] smp_apic_timer_interrupt+0xc0/0xfa
> [50102.787566] apic_timer_interrupt+0x90/0xa0
> [50102.787566] </IRQ>
> [50102.787568] RIP: 0010:cpuidle_enter_state+0x134/0x189
> [50102.787569] RSP: 0018:ffffc900032e3ea0 EFLAGS: 00000246 ORIG_RAX:
> ffffffffffffff10
> [50102.787570] RAX: 00002d9176d7d9f4 RBX: 0000000000000002 RCX:
> 000000000000001f
> [50102.787570] RDX: 0000000000000000 RSI: 0000000000000010 RDI:
> 0000000000000000
> [50102.787571] RBP: ffffc900032e3ed0 R08: 00000000ffffffd8 R09:
> 0000000000000003
> [50102.787572] R10: ffffc900032e3e70 R11: ffff88046fc98e50 R12:
> ffff88046c234400
> [50102.787572] R13: 00002d9176d7d9f4 R14: 0000000000000002 R15:
> 00002d9176d6e845
> [50102.787575] cpuidle_enter+0x12/0x14
> [50102.787576] do_idle+0x113/0x16b
> [50102.787578] cpu_startup_entry+0x1a/0x1f
> [50102.787580] start_secondary+0xea/0xed
> [50102.787581] secondary_startup_64+0xa5/0xa5
> [50102.787582] Code: f6 48 3d 90 00 00 00 74 04 48 8b 70 70 49 8b 84
> 24 68 02 00 00 48 85 c0 74 0c 48 39 f0 72 24 48 85 f6 75 09 eb 1d 48
> 85 f6 75 02 <0f> ff 49 8d bc 24 48 04 00 00 48 c1 e6 06 e8 a9 62 ff ff
> e9 eb
> [50102.787602] ---[ end trace 8558fb6f1ca3beb2 ]---
>
>
^ permalink raw reply
* RE: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when interacting with network stack
From: Yuval Mintz @ 2017-09-26 12:29 UTC (permalink / raw)
To: Yunsheng Lin
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net
In-Reply-To: <3fe662df-a216-4966-863c-d98555ef3ed2@huawei.com>
> Hi, Yuval
>
> On 2017/9/26 14:43, Yuval Mintz wrote:
> >> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc
> >> is used to tell hclge_dcb module to do the setup.
> >
> > While this might be a step in the right direction, this causes an inconsistency
> > in user experience - Some [well, most] vendors didn't allow the mqprio
> > priority mapping to affect DCB, instead relying on the dcbnl functionality
> > to control that configuration.
> >
> > A couple of options to consider:
> > - Perhaps said logic shouldn't be contained inside the driver but rather
> > in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from
> > within mqprio and try changing the configuration.
>
> In net/dcb/dcbnl.c
> dcbnl_ieee_set already call dcbnl_ieee_notify to notify the user space
> configuration has changed, does this dcbnl_ieee_notify function do the
> job for us? I am not sure if lldpad has registered for this notifition.
Not that familiar with the dcbnl calls; Shouldn't dcbnl_setall be called to
make the configuration apply [or is that only for ieee]?
Regardless, don't know if it makes sense to assume user-application would
fix the qdisc configuration by notification while dcbnl logic in kernel could have
done that instead.
> As you suggested below, can we add a new TC_MQPRIO_HW_OFFLOAD_
> value to
> reflect that the configuration is needed to be changed by dcbnl_ieee_set
> (perhaps some other function) in dcbnl?
> Do you think it is feasible?
Either I'm miseading your answer or we think of it from 2 opposite end.
I was thinking that the new offloaded flag would indicate to the underlying
driver that it's expected to offload the prio mapping [as part of DCB].
If the driver would be incapable of that it would refuse the offload.
User would then have to explicitly request that the qdisc offload.
>
>
> > - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user
> > request to allow this configuration to affect DCB.
> >
> >> When using lldptool to configure DCB parameter, hclge_dcb module
> >> call the client_ops->setup_tc to tell network stack which queue
> >> and priority is using for specific tc.
> >
> > You're basically bypassing the mqprio logic.
> > Since you're configuring the prio->queue mapping from DCB flow,
> > you'll get an mqprio-like behavior [meaning a transmitted packet
> > would reach a transmission queue associated with its priority] even
> > if device wasn't grated with an mqprio qdisc.
> > Why should your user even use mqprio? What benefit does he get from it?
> >
> > ...
> >
> >> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)
> >> +{
> >> + struct hns3_nic_priv *priv = netdev_priv(netdev);
> >> + struct hnae3_handle *h = priv->ae_handle;
> >> + struct hnae3_knic_private_info *kinfo = &h->kinfo;
> >> + unsigned int queue_size = kinfo->rss_size * kinfo->num_tc;
> >> + int ret;
> >> +
> >> + ret = netif_set_real_num_tx_queues(netdev, queue_size);
> >> + if (ret) {
> >> + netdev_err(netdev,
> >> + "netif_set_real_num_tx_queues fail, ret=%d!\n",
> >> + ret);
> >> + return ret;
> >> + }
> >> +
> >> + ret = netif_set_real_num_rx_queues(netdev, queue_size);
> >
> > I don't think you're changing the driver behavior, but why are you setting
> > the real number of rx queues based on the number of TCs?
> > Do you actually open (TC x RSS) Rx queues?
> >
> > .
> >
^ permalink raw reply
* [PATCH] ebtables: fix race condition in frame_filter_net_init()
From: Artem Savkov @ 2017-09-26 12:29 UTC (permalink / raw)
To: Florian Westphal
Cc: Pablo Neira Ayuso, netdev, linux-kernel, netfilter-devel,
Artem Savkov
It is possible for ebt_in_hook to be triggered before ebt_table is assigned
resulting in a NULL-pointer dereference. Make sure hooks are
registered as the last step.
Fixes: aee12a0a3727 ebtables: remove nf_hook_register usage
Signed-off-by: Artem Savkov <asavkov@redhat.com>
---
include/linux/netfilter_bridge/ebtables.h | 5 +++--
net/bridge/netfilter/ebtable_broute.c | 2 +-
net/bridge/netfilter/ebtable_filter.c | 8 ++++++--
net/bridge/netfilter/ebtable_nat.c | 8 ++++++--
net/bridge/netfilter/ebtables.c | 24 +++++++++++++-----------
5 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/include/linux/netfilter_bridge/ebtables.h b/include/linux/netfilter_bridge/ebtables.h
index 2c2a5514b0df..7d68f5ba6ded 100644
--- a/include/linux/netfilter_bridge/ebtables.h
+++ b/include/linux/netfilter_bridge/ebtables.h
@@ -109,8 +109,9 @@ struct ebt_table {
#define EBT_ALIGN(s) (((s) + (__alignof__(struct _xt_align)-1)) & \
~(__alignof__(struct _xt_align)-1))
extern struct ebt_table *ebt_register_table(struct net *net,
- const struct ebt_table *table,
- const struct nf_hook_ops *);
+ const struct ebt_table *table);
+extern int ebt_register_hooks(struct net *net, struct ebt_table *table,
+ const struct nf_hook_ops *ops);
extern void ebt_unregister_table(struct net *net, struct ebt_table *table,
const struct nf_hook_ops *);
extern unsigned int ebt_do_table(struct sk_buff *skb,
diff --git a/net/bridge/netfilter/ebtable_broute.c b/net/bridge/netfilter/ebtable_broute.c
index 2585b100ebbb..b41017409aa5 100644
--- a/net/bridge/netfilter/ebtable_broute.c
+++ b/net/bridge/netfilter/ebtable_broute.c
@@ -65,7 +65,7 @@ static int ebt_broute(struct sk_buff *skb)
static int __net_init broute_net_init(struct net *net)
{
- net->xt.broute_table = ebt_register_table(net, &broute_table, NULL);
+ net->xt.broute_table = ebt_register_table(net, &broute_table);
return PTR_ERR_OR_ZERO(net->xt.broute_table);
}
diff --git a/net/bridge/netfilter/ebtable_filter.c b/net/bridge/netfilter/ebtable_filter.c
index 45a00dbdbcad..ca04582b374e 100644
--- a/net/bridge/netfilter/ebtable_filter.c
+++ b/net/bridge/netfilter/ebtable_filter.c
@@ -93,8 +93,12 @@ static const struct nf_hook_ops ebt_ops_filter[] = {
static int __net_init frame_filter_net_init(struct net *net)
{
- net->xt.frame_filter = ebt_register_table(net, &frame_filter, ebt_ops_filter);
- return PTR_ERR_OR_ZERO(net->xt.frame_filter);
+ net->xt.frame_filter = ebt_register_table(net, &frame_filter);
+
+ if (IS_ERR(net->xt.frame_filter))
+ return PTR_ERR(net->xt.frame_filter);
+
+ return ebt_register_hooks(net, net->xt.frame_filter, ebt_ops_filter);
}
static void __net_exit frame_filter_net_exit(struct net *net)
diff --git a/net/bridge/netfilter/ebtable_nat.c b/net/bridge/netfilter/ebtable_nat.c
index 57cd5bb154e7..f4a2ff93be34 100644
--- a/net/bridge/netfilter/ebtable_nat.c
+++ b/net/bridge/netfilter/ebtable_nat.c
@@ -93,8 +93,12 @@ static const struct nf_hook_ops ebt_ops_nat[] = {
static int __net_init frame_nat_net_init(struct net *net)
{
- net->xt.frame_nat = ebt_register_table(net, &frame_nat, ebt_ops_nat);
- return PTR_ERR_OR_ZERO(net->xt.frame_nat);
+ net->xt.frame_nat = ebt_register_table(net, &frame_nat);
+
+ if (IS_ERR(net->xt.frame_nat))
+ return PTR_ERR(net->xt.frame_nat);
+
+ return ebt_register_hooks(net, net->xt.frame_nat, ebt_ops_nat);
}
static void __net_exit frame_nat_net_exit(struct net *net)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 83951f978445..e72120ac426e 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1169,9 +1169,19 @@ static void __ebt_unregister_table(struct net *net, struct ebt_table *table)
kfree(table);
}
+int ebt_register_hooks(struct net *net, struct ebt_table *table,
+ const struct nf_hook_ops *ops)
+{
+ int ret = nf_register_net_hooks(net, ops, hweight32(table->valid_hooks));
+
+ if (ret)
+ __ebt_unregister_table(net, table);
+
+ return ret;
+}
+
struct ebt_table *
-ebt_register_table(struct net *net, const struct ebt_table *input_table,
- const struct nf_hook_ops *ops)
+ebt_register_table(struct net *net, const struct ebt_table *input_table)
{
struct ebt_table_info *newinfo;
struct ebt_table *t, *table;
@@ -1252,15 +1262,6 @@ ebt_register_table(struct net *net, const struct ebt_table *input_table,
list_add(&table->list, &net->xt.tables[NFPROTO_BRIDGE]);
mutex_unlock(&ebt_mutex);
- if (!ops)
- return table;
-
- ret = nf_register_net_hooks(net, ops, hweight32(table->valid_hooks));
- if (ret) {
- __ebt_unregister_table(net, table);
- return ERR_PTR(ret);
- }
-
return table;
free_unlock:
mutex_unlock(&ebt_mutex);
@@ -2456,6 +2457,7 @@ static void __exit ebtables_fini(void)
printk(KERN_INFO "Ebtables v2.0 unregistered\n");
}
+EXPORT_SYMBOL(ebt_register_hooks);
EXPORT_SYMBOL(ebt_register_table);
EXPORT_SYMBOL(ebt_unregister_table);
EXPORT_SYMBOL(ebt_do_table);
--
2.13.5
^ permalink raw reply related
* Re: [PATCH net-next 0/7] nfp: flower vxlan tunnel offload
From: Or Gerlitz @ 2017-09-26 12:41 UTC (permalink / raw)
To: Jiri Benc
Cc: Simon Horman, David Miller, Jakub Kicinski, Linux Netdev List,
oss-drivers, John Hurley, Paolo Abeni, Paul Blakey, Jiri Pirko,
Roi Dayan
In-Reply-To: <20170926121509.50a32571@griffin>
On Tue, Sep 26, 2017 at 1:15 PM, Jiri Benc <jbenc@redhat.com> wrote:
> On Mon, 25 Sep 2017 19:04:53 +0200, Simon Horman wrote:
>> The MAC addresses are extracted from the netdevs already loaded in the
>> kernel and are monitored for any changes. The IP addresses are slightly
>> different in that they are extracted from the rules themselves. We make the
>> assumption that, if a packet is decapsulated at the end point and a match
>> is attempted on the IP address,
>
> You lost me here, I'm afraid. What do you mean by "match"?
>
>> that this IP address should be recognised
>> in the kernel. That being the case, the same traffic pattern should be
>> witnessed if the skip_hw flag is applied.
>
> Just to be really sure that this works correctly, can you confirm that
> this will match the packet:
>
> ip link add vxlan0 type vxlan dstport 4789 dev eth0 external
> ip link set dev vxlan0 up
> tc qdisc add dev vxlan0 ingress
> ethtool -K eth0 hw-tc-offload on
> tc filter add dev vxlan0 protocol ip parent ffff: flower enc_key_id 102 \
> enc_dst_port 4789 src_ip 3.4.5.6 skip_sw action [...]
>
> while this one will NOT match:
what do you exactly mean by "will not match"
> ip link add vxlan0 type vxlan dstport 4789 dev eth0 external
> ip link set dev vxlan0 up
> tc qdisc add dev eth0 ingress
> ethtool -K eth0 hw-tc-offload on
> tc filter add dev eth0 protocol ip parent ffff: flower enc_key_id 102 \
> enc_dst_port 4789 src_ip 3.4.5.6 skip_sw action [...]
Please note that the way the rule is being set to the HW driver is by delegation
done in flower, see these commits (specifically "Add offload support
using egress Hardware device")
a6e1693 net/sched: cls_flower: Set the filter Hardware device for all use-cases
7091d8c net/sched: cls_flower: Add offload support using egress Hardware device
255cb30 net/sched: act_mirred: Add new tc_action_ops get_dev()
Since the egress port is not HW port netdev but rather SW virtual tunnel netdev
we have some logic in the kernel to delegate the rule programming to
HW via the HW netdev
OKay? if not, please elaborate
> We found that with mlx5, the second one actually matches, too. Which is
> a very serious bug. (Adding Paolo who found this. And adding a few more
> Mellanox guys to be aware of the bug.)
What is the bug in your view?
Or.
^ permalink raw reply
* Re: [PATCH] ebtables: fix race condition in frame_filter_net_init()
From: Florian Westphal @ 2017-09-26 12:42 UTC (permalink / raw)
To: Artem Savkov
Cc: Florian Westphal, Pablo Neira Ayuso, netdev, linux-kernel,
netfilter-devel
In-Reply-To: <20170926122938.11603-1-asavkov@redhat.com>
Artem Savkov <asavkov@redhat.com> wrote:
> It is possible for ebt_in_hook to be triggered before ebt_table is assigned
> resulting in a NULL-pointer dereference. Make sure hooks are
> registered as the last step.
Right, thanks for the patch.
> --- a/net/bridge/netfilter/ebtable_broute.c
> +++ b/net/bridge/netfilter/ebtable_broute.c
> @@ -65,7 +65,7 @@ static int ebt_broute(struct sk_buff *skb)
>
> static int __net_init broute_net_init(struct net *net)
> {
> - net->xt.broute_table = ebt_register_table(net, &broute_table, NULL);
> + net->xt.broute_table = ebt_register_table(net, &broute_table);
I wonder if it makes more sense to model this like the iptables version,
i.e. pass net->xt.table_name as last arg to ebt_register_table ...
> +int ebt_register_hooks(struct net *net, struct ebt_table *table,
> + const struct nf_hook_ops *ops)
> +{
> + int ret = nf_register_net_hooks(net, ops, hweight32(table->valid_hooks));
> +
> + if (ret)
> + __ebt_unregister_table(net, table);
> +
> + return ret;
> +}
... because this looks strange (unregister of table/not-so-obvious error
unwinding ...)
> @@ -1252,15 +1262,6 @@ ebt_register_table(struct net *net, const struct ebt_table *input_table,
> list_add(&table->list, &net->xt.tables[NFPROTO_BRIDGE]);
> mutex_unlock(&ebt_mutex);
... here one could then assign the net->xt.table_X pointer, and then do
the hook registration right after.
However i have no strong opinion here.
^ permalink raw reply
* Re: [PATCH net-next 7/7] nfp: flower vxlan neighbour keep-alive
From: Or Gerlitz @ 2017-09-26 12:44 UTC (permalink / raw)
To: John Hurley
Cc: Simon Horman, David Miller, Jakub Kicinski, Linux Netdev List,
oss-drivers
In-Reply-To: <CAK+XE=nfndmKbgz174CEKzfBHbf7nTBX9CUb47MPBnDssJJ0fA@mail.gmail.com>
On Tue, Sep 26, 2017 at 12:37 PM, John Hurley <john.hurley@netronome.com> wrote:
> [ Reposting in plantext only]
> On Mon, Sep 25, 2017 at 7:32 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>
>> On Mon, Sep 25, 2017 at 1:23 PM, Simon Horman
>> <simon.horman@netronome.com> wrote:
>> > From: John Hurley <john.hurley@netronome.com>
>> >
>> > Periodically receive messages containing the destination IPs of tunnels
>> > that have recently forwarded traffic. Update the neighbour entries 'used'
>> > value for these IPs next hop.
>>
>> Are you proactively sending keep alive messages from the driver or the
>> fw? what's wrong with the probes sent by the kernel NUD subsystem?
> The messages are sent from the FW to the driver. They indicate which
> offloaded tunnels are currently active.
Do you support flow counters for offloaded TC rules? do you support last-use?
If Y && Y and you cache someone the prev counter value, you can use
this for the "used" feedback. I don't see why add keep-alive and not piggy back
on the flow counters logic.
>> In our driver we also update the used value for neighs of offloaded
>> tunnels, we do it based on flow counters for the offloaded tunnels
>> which is an evidence for activity. Any reason for you not to apply a
>> similar practice?
> Yes, this would provide the same outcome. Because our firmware already
> offered these messages, we chose to support this approach.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: speedup netns create/delete time
From: Eric Dumazet @ 2017-09-26 12:51 UTC (permalink / raw)
To: Tariq Toukan
Cc: David S . Miller, netdev, Eric W . Biederman, Eric Dumazet,
Majd Dibbiny, Yonatan Cohen, Eran Ben Elisha
In-Reply-To: <8edb310a-562d-bff1-0482-64314833e722@mellanox.com>
On Tue, Sep 26, 2017 at 4:21 AM, Tariq Toukan <tariqt@mellanox.com> wrote:
>
>
> Hi Eric,
>
> We see a regression introduced in this series, specifically in the patches
> touching lib/kobject_uevent.c.
> We tried to figure out what is wrong there, but couldn't point it out.
>
> Bug is that mlx4 driver restart fails, because mlx4_core is still in use.
> According to module dependencies, both mlx4_en and mlx4_ib should have been
> unloaded at this point
> Please see log below.
>
> This looks to be some kind of a race, as the repro is not deterministic.
> Probably the en/ib modules are now mistakenly reloaded.
>
> Any idea what could this be?
>
> Regards,
> Tariq
>
>
> [root@reg-l-vrt-41016-009 ~]# /etc/init.d/openibd stop
> Unloading HCA driver: [ OK ]
> [root@reg-l-vrt-41016-009 ~]# /etc/init.d/openibd start
> Loading HCA driver and Access Layer: [ OK ]
> [root@reg-l-vrt-41016-009 ~]# /etc/init.d/openibd stop
> Unloading mlx4_core [FAILED]
> rmmod: ERROR: Module mlx4_core is in use
I have absolutely no idea. Please bisect.
Are you really using netns in the first place ?
^ permalink raw reply
* Re: [PATCH net-next 0/7] nfp: flower vxlan tunnel offload
From: Jiri Benc @ 2017-09-26 12:51 UTC (permalink / raw)
To: Or Gerlitz
Cc: Simon Horman, David Miller, Jakub Kicinski, Linux Netdev List,
oss-drivers, John Hurley, Paolo Abeni, Paul Blakey, Jiri Pirko,
Roi Dayan
In-Reply-To: <CAJ3xEMjEAhzC5=S7-dx8RiS=E7gYBBrtWY=9Cvqj-K3kyT9o3A@mail.gmail.com>
On Tue, 26 Sep 2017 15:41:37 +0300, Or Gerlitz wrote:
> Please note that the way the rule is being set to the HW driver is by delegation
> done in flower, see these commits (specifically "Add offload support
> using egress Hardware device")
It's very well possible the bug is somewhere in net/sched.
> What is the bug in your view?
If you replace skip_sw with skip_hw, the rules have to work
identically. In software, decapsulated packets appear on the vxlan0
interface, not on the eth0 interface. As the consequence, the second
example must not match on such packets. Those packets do not appear on
eth0 with software only path. eth0 sees encapsulated packets only. It's
vxlan0 that sees decapsulated packets with attached dst_metadata and
that's the only interface where the flower filter in the example can
match.
Hardware offloaded path must behave identically to the software path.
Jiri
^ permalink raw reply
* Re: [REGRESSION] Warning in tcp_fastretrans_alert() of net/ipv4/tcp_input.c
From: Roman Gushchin @ 2017-09-26 13:10 UTC (permalink / raw)
To: Yuchung Cheng
Cc: Oleksandr Natalenko, Hideaki YOSHIFUJI, Alexey Kuznetsov, netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <CAK6E8=cGF+xKiixRVvA=3PVPA7OQta9hVLTgCbKgvYf3e9Eu-A@mail.gmail.com>
> On Wed, Sep 20, 2017 at 6:46 PM, Roman Gushchin <guro@fb.com> wrote:
> >
> > > Hello.
> > >
> > > Since, IIRC, v4.11, there is some regression in TCP stack resulting in the
> > > warning shown below. Most of the time it is harmless, but rarely it just
> > > causes either freeze or (I believe, this is related too) panic in
> > > tcp_sacktag_walk() (because sk_buff passed to this function is NULL).
> > > Unfortunately, I still do not have proper stacktrace from panic, but will try
> > > to capture it if possible.
> > >
> > > Also, I have custom settings regarding TCP stack, shown below as well. ifb is
> > > used to shape traffic with tc.
> > >
> > > Please note this regression was already reported as BZ [1] and as a letter to
> > > ML [2], but got neither attention nor resolution. It is reproducible for (not
> > > only) me on my home router since v4.11 till v4.13.1 incl.
> > >
> > > Please advise on how to deal with it. I'll provide any additional info if
> > > necessary, also ready to test patches if any.
> > >
> > > Thanks.
> > >
> > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=195835
> > > [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_netdev_msg436158.html&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=MDDRfLG5DvdOeniMpaZDJI8ulKQ6PQ6OX_1YtRsiTMA&s=-n3dGZw-pQ95kMBUfq5G9nYZFcuWtbTDlYFkcvQPoKc&e=
> >
> > We're experiencing the same problems on some machines in our fleet.
> > Exactly the same symptoms: tcp_fastretrans_alert() warnings and
> > sometimes panics in tcp_sacktag_walk().
> >
> > Here is an example of a backtrace with the panic log:
Hi Yuchung!
> do you still see the panics if you disable RACK?
> sysctl net.ipv4.tcp_recovery=0?
No, we haven't seen any crash since that.
>
> also have you experience any sack reneg? could you post the output of
> ' nstat |grep -i TCP' thanks
hostname TcpActiveOpens 2289680 0.0
hostname TcpPassiveOpens 3592758 0.0
hostname TcpAttemptFails 746910 0.0
hostname TcpEstabResets 154988 0.0
hostname TcpInSegs 16258678255 0.0
hostname TcpOutSegs 46967011611 0.0
hostname TcpRetransSegs 13724310 0.0
hostname TcpInErrs 2 0.0
hostname TcpOutRsts 9418798 0.0
hostname TcpExtEmbryonicRsts 2303 0.0
hostname TcpExtPruneCalled 90192 0.0
hostname TcpExtOfoPruned 57274 0.0
hostname TcpExtOutOfWindowIcmps 3 0.0
hostname TcpExtTW 1164705 0.0
hostname TcpExtTWRecycled 2 0.0
hostname TcpExtPAWSEstab 159 0.0
hostname TcpExtDelayedACKs 209207209 0.0
hostname TcpExtDelayedACKLocked 508571 0.0
hostname TcpExtDelayedACKLost 1713248 0.0
hostname TcpExtListenOverflows 625 0.0
hostname TcpExtListenDrops 625 0.0
hostname TcpExtTCPHPHits 9341188489 0.0
hostname TcpExtTCPPureAcks 1434646465 0.0
hostname TcpExtTCPHPAcks 5733614672 0.0
hostname TcpExtTCPSackRecovery 3261698 0.0
hostname TcpExtTCPSACKReneging 12203 0.0
hostname TcpExtTCPSACKReorder 433189 0.0
hostname TcpExtTCPTSReorder 22694 0.0
hostname TcpExtTCPFullUndo 45092 0.0
hostname TcpExtTCPPartialUndo 22016 0.0
hostname TcpExtTCPLossUndo 2150040 0.0
hostname TcpExtTCPLostRetransmit 60119 0.0
hostname TcpExtTCPSackFailures 2626782 0.0
hostname TcpExtTCPLossFailures 182999 0.0
hostname TcpExtTCPFastRetrans 4334275 0.0
hostname TcpExtTCPSlowStartRetrans 3453348 0.0
hostname TcpExtTCPTimeouts 1070997 0.0
hostname TcpExtTCPLossProbes 2633545 0.0
hostname TcpExtTCPLossProbeRecovery 941647 0.0
hostname TcpExtTCPSackRecoveryFail 336302 0.0
hostname TcpExtTCPRcvCollapsed 461354 0.0
hostname TcpExtTCPAbortOnData 349196 0.0
hostname TcpExtTCPAbortOnClose 3395 0.0
hostname TcpExtTCPAbortOnTimeout 51201 0.0
hostname TcpExtTCPMemoryPressures 2 0.0
hostname TcpExtTCPSpuriousRTOs 2120503 0.0
hostname TcpExtTCPSackShifted 2613736 0.0
hostname TcpExtTCPSackMerged 21358743 0.0
hostname TcpExtTCPSackShiftFallback 8769387 0.0
hostname TcpExtTCPBacklogDrop 5 0.0
hostname TcpExtTCPRetransFail 843 0.0
hostname TcpExtTCPRcvCoalesce 949068035 0.0
hostname TcpExtTCPOFOQueue 470118 0.0
hostname TcpExtTCPOFODrop 9915 0.0
hostname TcpExtTCPOFOMerge 9 0.0
hostname TcpExtTCPChallengeACK 90 0.0
hostname TcpExtTCPSYNChallenge 3 0.0
hostname TcpExtTCPFastOpenActive 2089 0.0
hostname TcpExtTCPSpuriousRtxHostQueues 896596 0.0
hostname TcpExtTCPAutoCorking 547386735 0.0
hostname TcpExtTCPFromZeroWindowAdv 28757 0.0
hostname TcpExtTCPToZeroWindowAdv 28761 0.0
hostname TcpExtTCPWantZeroWindowAdv 322431 0.0
hostname TcpExtTCPSynRetrans 3026 0.0
hostname TcpExtTCPOrigDataSent 40976870977 0.0
hostname TcpExtTCPHystartTrainDetect 453920 0.0
hostname TcpExtTCPHystartTrainCwnd 11586273 0.0
hostname TcpExtTCPHystartDelayDetect 10943 0.0
hostname TcpExtTCPHystartDelayCwnd 763554 0.0
hostname TcpExtTCPACKSkippedPAWS 30 0.0
hostname TcpExtTCPACKSkippedSeq 218 0.0
hostname TcpExtTCPWinProbe 2408 0.0
hostname TcpExtTCPKeepAlive 213768 0.0
hostname TcpExtTCPMTUPFail 69 0.0
hostname TcpExtTCPMTUPSuccess 8811 0.0
Thanks!
^ permalink raw reply
* Re: [PATCH 0/2] 9p: Fixes for hard-to-hit bugs
From: Tuomas Tynkkynen @ 2017-09-26 13:10 UTC (permalink / raw)
To: Al Viro
Cc: v9fs-developer, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, David S. Miller, linux-kernel, netdev,
linux-fsdevel
In-Reply-To: <20170906145908.8082-1-tuomas@tuxera.com>
Hi Al,
On Wed, 2017-09-06 at 17:59 +0300, Tuomas Tynkkynen wrote:
> These two patches fix two hard-to-hit (but really annoying) bugs in
> 9p.
> The first one was posted earlier in February (with one R-b), the
> second
> is a new one.
>
> Both of these have had soaking in NixOS distribution kernels for
> a couple of months with no ill effects.
>
> Tuomas Tynkkynen (2):
> fs/9p: Compare qid.path in v9fs_test_inode
> net/9p: Switch to wait_event_killable()
>
> fs/9p/vfs_inode.c | 3 +++
> fs/9p/vfs_inode_dotl.c | 3 +++
> net/9p/client.c | 3 +--
> net/9p/trans_virtio.c | 13 ++++++-------
> net/9p/trans_xen.c | 4 ++--
> 5 files changed, 15 insertions(+), 11 deletions(-)
>
Could you apply these? Thanks!
- Tuomas
^ permalink raw reply
* [PATCH net-next] bnxt_en: Remove redundant unlikely()
From: Tobias Klauser @ 2017-09-26 13:12 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev
IS_ERR() already implies unlikely(), so it can be omitted.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index c25f5b555adf..5ba49938ba55 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -1491,7 +1491,7 @@ static int bnxt_rx_pkt(struct bnxt *bp, struct bnxt_napi *bnapi, u32 *raw_cons,
(struct rx_tpa_end_cmp *)rxcmp,
(struct rx_tpa_end_cmp_ext *)rxcmp1, event);
- if (unlikely(IS_ERR(skb)))
+ if (IS_ERR(skb))
return -EBUSY;
rc = -ENOMEM;
--
2.13.0
^ permalink raw reply related
* [PATCH net-next] net/mlx5: Remove redundant unlikely()
From: Tobias Klauser @ 2017-09-26 13:13 UTC (permalink / raw)
To: Saeed Mahameed, Matan Barak, Leon Romanovsky
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
IS_ERR() already implies unlikely(), so it can be omitted.
Signed-off-by: Tobias Klauser <tklauser-93Khv+1bN0NyDzI6CaY1VQ@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
index 4614ddfa91eb..6a7c8b04447e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
@@ -256,7 +256,7 @@ struct sk_buff *mlx5e_ipsec_handle_tx_skb(struct net_device *netdev,
goto drop;
}
mdata = mlx5e_ipsec_add_metadata(skb);
- if (unlikely(IS_ERR(mdata))) {
+ if (IS_ERR(mdata)) {
atomic64_inc(&priv->ipsec->sw_stats.ipsec_tx_drop_metadata);
goto drop;
}
--
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 related
* [PATCH net-next] ldmvsw: Remove redundant unlikely()
From: Tobias Klauser @ 2017-09-26 13:14 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Shannon Nelson
IS_ERR() already implies unlikely(), so it can be omitted.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/sun/ldmvsw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sun/ldmvsw.c b/drivers/net/ethernet/sun/ldmvsw.c
index 5b56c24b6ed2..5feeaa9f0a9e 100644
--- a/drivers/net/ethernet/sun/ldmvsw.c
+++ b/drivers/net/ethernet/sun/ldmvsw.c
@@ -307,7 +307,7 @@ static int vsw_port_probe(struct vio_dev *vdev, const struct vio_device_id *id)
/* Get (or create) the vnet associated with this port */
vp = vsw_get_vnet(hp, vdev->mp, &handle);
- if (unlikely(IS_ERR(vp))) {
+ if (IS_ERR(vp)) {
err = PTR_ERR(vp);
pr_err("Failed to get vnet for vsw-port\n");
mdesc_release(hp);
--
2.13.0
^ permalink raw reply related
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