* Build error for samples/bpf/ due to commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
From: Jesper Dangaard Brouer @ 2018-04-13 13:22 UTC (permalink / raw)
To: Peter Zijlstra, Daniel Borkmann, Alexei Starovoitov
Cc: brouer, netdev@vger.kernel.org, LKML, Björn Töpel
Hi Peter,
Your commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS") broke build
for several samples/bpf programs. I'm unsure what the best way forward
is to unbreak these...
The issue is that these samples are build with LLVM/clang (which
doesn't like 'asm goto' constructs). And they end up including
arch/x86/include/asm/cpufeature.h via a long include path, see build
examples below (through different path to include/linux/thread_info.h).
Maybe Alexei or Daniel have an idea how to work around this?
As tools/testing/selftests/bpf/ does not seem to fail!?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
Build error#1:
--------------
clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -Isamples/bpf \
-I./tools/testing/selftests/bpf/ \
-D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
-D__TARGET_ARCH_x86 -Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c samples/bpf/sockex2_kern.c -o -| llc -march=bpf -filetype=obj -o samples/bpf/sockex2_kern.o
In file included from samples/bpf/sockex2_kern.c:3:
In file included from ./include/uapi/linux/in.h:24:
In file included from ./include/linux/socket.h:8:
In file included from ./include/linux/uio.h:13:
In file included from ./include/linux/thread_info.h:38:
In file included from ./arch/x86/include/asm/thread_info.h:53:
./arch/x86/include/asm/cpufeature.h:150:2: error: 'asm goto' constructs are not supported yet
asm_volatile_goto("1: jmp 6f\n"
^
./include/linux/compiler-gcc.h:290:42: note: expanded from macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
Build error#2:
--------------
clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -Isamples/bpf \
-I./tools/testing/selftests/bpf/ \
-D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
-D__TARGET_ARCH_x86 -Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c samples/bpf/tracex1_kern.c -o -| llc -march=bpf -filetype=obj -o samples/bpf/tracex1_kern.o
In file included from samples/bpf/tracex1_kern.c:7:
In file included from ./include/linux/skbuff.h:19:
In file included from ./include/linux/time.h:6:
In file included from ./include/linux/seqlock.h:36:
In file included from ./include/linux/spinlock.h:51:
In file included from ./include/linux/preempt.h:81:
In file included from ./arch/x86/include/asm/preempt.h:7:
In file included from ./include/linux/thread_info.h:38:
In file included from ./arch/x86/include/asm/thread_info.h:53:
./arch/x86/include/asm/cpufeature.h:150:2: error: 'asm goto' constructs are not supported yet
asm_volatile_goto("1: jmp 6f\n"
^
./include/linux/compiler-gcc.h:290:42: note: expanded from macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
Build error#3:
--------------
clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86
/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -Isamples/bpf \
-I./tools/testing/selftests/bpf/ \
-D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
-D__TARGET_ARCH_x86 -Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c samples/bpf/xdp1_kern.c -o -| llc -march=bpf -filetype=obj -o samples/bpf/xdp1_kern.o
In file included from samples/bpf/xdp1_kern.c:9:
In file included from ./include/linux/in.h:23:
In file included from ./include/uapi/linux/in.h:24:
In file included from ./include/linux/socket.h:8:
In file included from ./include/linux/uio.h:13:
In file included from ./include/linux/thread_info.h:38:
In file included from ./arch/x86/include/asm/thread_info.h:53:
./arch/x86/include/asm/cpufeature.h:150:2: error: 'asm goto' constructs are not supported yet
asm_volatile_goto("1: jmp 6f\n"
^
./include/linux/compiler-gcc.h:290:42: note: expanded from macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^ permalink raw reply
* Re: [PATCH] netfilter: fix CONFIG_NF_REJECT_IPV6=m link error
From: Pablo Neira Ayuso @ 2018-04-13 13:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
netfilter-devel, coreteam, Networking, Linux Kernel Mailing List
In-Reply-To: <CAK8P3a1GH5OSu62TBh46S0OdiXTJODsvV3To5=Jp2nL+fz1Puw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]
On Mon, Apr 09, 2018 at 04:43:40PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 9, 2018 at 4:37 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Hi Arnd,
> >
> > On Mon, Apr 09, 2018 at 12:53:12PM +0200, Arnd Bergmann wrote:
> >> We get a new link error with CONFIG_NFT_REJECT_INET=y and CONFIG_NF_REJECT_IPV6=m
> >
> > I think we can update NFT_REJECT_INET so it depends on NFT_REJECT_IPV4
> > and NFT_REJECT_IPV6. This doesn't allow here CONFIG_NFT_REJECT_INET=y
> > and CONFIG_NF_REJECT_IPV6=m.
> >
> > I mean, just like we do with NFT_FIB_INET.
>
> That can only work if NFT_REJECT_INET can be made a 'tristate' symbol
> again, so that code gets built as a loadable module if
> CONFIG_NF_REJECT_IPV6=m.
>
> > BTW, I think this problem has been is not related to the recent patch,
> > but something older that kbuild robot has triggered more easily for
> > some reason?
>
> 02c7b25e5f54 is the one that turned NF_TABLES_INET into a 'bool'
> symbol. NFT_REJECT depends on NF_TABLES_INET, so it used to
> restricted to a loadable module with IPV6=m, but can now be
> built-in, which causes that link error.
Still one more spin on this, I would like to see if we have a way to
fix this by simplifing things a bit.
Would this one I'm attaching would work?
Thanks for you patience.
[-- Attachment #2: 0001-netfilter-CONFIG_NF_REJECT_IPV-4-6-becomes-bool-togg.patch --]
[-- Type: text/x-diff, Size: 2586 bytes --]
>From af07bc7ff5d34ce54e7913233912c058e6699e3c Mon Sep 17 00:00:00 2001
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 13 Apr 2018 10:48:40 +0200
Subject: [PATCH] netfilter: CONFIG_NF_REJECT_IPV{4,6} becomes bool toggle
Arnd reports that we get a new link error with CONFIG_NFT_REJECT_INET=y
and CONFIG_NF_REJECT_IPV6=m after larger parts of the nftables modules
are linked together:
net/netfilter/nft_reject_inet.o: In function `nft_reject_inet_eval':
nft_reject_inet.c:(.text+0x17c): undefined reference to `nf_send_unreach6'
nft_reject_inet.c:(.text+0x190): undefined reference to `nf_send_reset6'
The problem is that with NF_TABLES_INET set, we implicitly try to use
the ipv6 version as well for NFT_REJECT, but when CONFIG_IPV6 is set to
a loadable module, it's impossible to reach that.
This patch fixes this problem by building-in nf_reject_ipv{4,6}.c, IPv6
symbol dependencies for the IPv6 reject infrastructure are located in
exthdrs_core.c, ip6_checksum.c and ip6_icmp.c which are also built-in,
so let's do the same to simplify this.
Fixes: 02c7b25e5f54 ("netfilter: nf_tables: build-in filter chain type")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/Kconfig | 3 +--
net/ipv6/netfilter/Kconfig | 3 +--
net/netfilter/Kconfig | 2 ++
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
index 280048e1e395..3e4e0ae2a9a1 100644
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -104,8 +104,7 @@ config NF_LOG_IPV4
select NF_LOG_COMMON
config NF_REJECT_IPV4
- tristate "IPv4 packet rejection"
- default m if NETFILTER_ADVANCED=n
+ bool "IPv4 packet rejection"
config NF_NAT_IPV4
tristate "IPv4 NAT"
diff --git a/net/ipv6/netfilter/Kconfig b/net/ipv6/netfilter/Kconfig
index ccbfa83e4bb0..1e5d040a60b8 100644
--- a/net/ipv6/netfilter/Kconfig
+++ b/net/ipv6/netfilter/Kconfig
@@ -87,8 +87,7 @@ config NF_DUP_IPV6
packet to be rerouted to another destination.
config NF_REJECT_IPV6
- tristate "IPv6 packet rejection"
- default m if NETFILTER_ADVANCED=n
+ bool "IPv6 packet rejection"
config NF_LOG_IPV6
tristate "IPv6 packet logging"
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 4189f574f5ec..d7b3272fe821 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -609,6 +609,8 @@ config NFT_REJECT
config NFT_REJECT_INET
depends on NF_TABLES_INET
+ select NF_REJECT_IPV4
+ select NF_REJECT_IPV6
default NFT_REJECT
tristate
--
2.11.0
^ permalink raw reply related
* Re: net: hang in unregister_netdevice: waiting for lo to become free
From: Dan Streetman @ 2018-04-13 12:43 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Tommi Rantala, Neil Horman, Xin Long, David Ahern,
Daniel Borkmann, Cong Wang, David Miller, Eric Dumazet,
Willem de Bruijn, Jakub Kicinski, Rasmus Villemoes, netdev, LKML,
Alexey Kuznetsov, Hideaki YOSHIFUJI, syzkaller, Dan Streetman,
Eric W. Biederman, Alexey Kodanev
In-Reply-To: <CACT4Y+Z2kdjsYUs-H9aSTcNW-FSKqm1__fg3eOq16H-E=X8oZg@mail.gmail.com>
On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
> <tommi.t.rantala@nokia.com> wrote:
>> On 20.02.2018 18:26, Neil Horman wrote:
>>>
>>> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
>>>>
>>>> On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
>>>> <tommi.t.rantala@nokia.com> wrote:
>>>>>
>>>>> On 19.02.2018 20:59, Dmitry Vyukov wrote:
>>>>>>
>>>>>> Is this meant to be fixed already? I am still seeing this on the
>>>>>> latest upstream tree.
>>>>>>
>>>>>
>>>>> These two commits are in v4.16-rc1:
>>>>>
>>>>> commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
>>>>> Author: Tommi Rantala <tommi.t.rantala@nokia.com>
>>>>> Date: Mon Feb 5 21:48:14 2018 +0200
>>>>>
>>>>> sctp: fix dst refcnt leak in sctp_v4_get_dst
>>>>> ...
>>>>> Fixes: 410f03831 ("sctp: add routing output fallback")
>>>>> Fixes: 0ca50d12f ("sctp: fix src address selection if using
>>>>> secondary
>>>>> addresses")
>>>>>
>>>>>
>>>>> commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2
>>>>> Author: Alexey Kodanev <alexey.kodanev@oracle.com>
>>>>> Date: Mon Feb 5 15:10:35 2018 +0300
>>>>>
>>>>> sctp: fix dst refcnt leak in sctp_v6_get_dst()
>>>>> ...
>>>>> Fixes: dbc2b5e9a09e ("sctp: fix src address selection if using
>>>>> secondary
>>>>> addresses for ipv6")
>>>>>
>>>>>
>>>>> I guess we missed something if it's still reproducible.
>>>>>
>>>>> I can check it later this week, unless someone else beat me to it.
>>>>
>>>>
>>>> Hi Tommi,
>>>>
>>>> Hmmm, I can't claim that it's exactly the same bug. Perhaps it's
>>>> another one then. But I am still seeing these:
>>>>
>>>> [ 58.799130] unregister_netdevice: waiting for lo to become free.
>>>> Usage count = 4
>>>> [ 60.847138] unregister_netdevice: waiting for lo to become free.
>>>> Usage count = 4
>>>> [ 62.895093] unregister_netdevice: waiting for lo to become free.
>>>> Usage count = 4
>>>> [ 64.943103] unregister_netdevice: waiting for lo to become free.
>>>> Usage count = 4
>>>>
>>>> on upstream tree pulled ~12 hours ago.
>>>>
>>> Can you write a systemtap script to probe dev_hold, and dev_put, printing
>>> out a
>>> backtrace if the device name matches "lo". That should tell us
>>> definitively if
>>> the problem is in the same location or not
>>
>>
>> Hi Dmitry, I tested with the reproducer and the kernel .config file that you
>> sent in the first email in this thread:
>>
>> With 4.16-rc2 unable to reproduce.
>>
>> With 4.15-rc9 bug reproducible, and I get "unregister_netdevice: waiting for
>> lo to become free. Usage count = 3"
>>
>> With 4.15-rc9 and Alexey's "sctp: fix dst refcnt leak in sctp_v6_get_dst()"
>> cherry-picked on top, unable to reproduce.
>>
>>
>> Is syzkaller doing something else now to trigger the bug...?
>> Can you still trigger the bug with the same reproducer?
>
> Hi Neil, Tommi,
>
> Reviving this old thread about "unregister_netdevice: waiting for lo
> to become free. Usage count = 3" hangs.
> I still did not have time to deep dive into what happens there (too
> many bugs coming from syzbot). But this still actively happens and I
> suspect accounts to a significant portion of various hang reports,
> which are quite unpleasant.
>
> One idea that could make it all simpler:
>
> Is this wait loop in netdev_wait_allrefs() supposed to wait for any
> prolonged periods of time under any non-buggy conditions? E.g. more
> than 1-2 minutes?
> If it only supposed to wait briefly for things that already supposed
> to be shutting down, and we add a WARNING there after some timeout,
> then syzbot will report all info how/when it happens, hopefully
> extracting reproducers, and all the nice things.
> But this WARNING should not have any false positives under any
> realistic conditions (e.g. waiting for arrival of remote packets with
> large timeouts).
>
> Looking at some task hung reports, it seems that this code holds some
> mutexes, takes workqueue thread and prevents any progress with
> destruction of other devices (and net namespace creation/destruction),
> so I guess it should not wait for any indefinite periods of time?
I'm working on this currently:
https://bugs.launchpad.net/ubuntu/zesty/+source/linux/+bug/1711407
I added a summary of what I've found to be the cause (or at least, one
possible cause) of this:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/72
I'm working on a patch to work around the main side-effect of this,
which is hanging while holding the global net mutex. Hangs will still
happen (e.g. if a dst leaks) but should not affect anything else,
other than a leak of the dst and its net namespace.
Fixing the dst leaks is important too, of course, but a dst leak (or
other cause) shouldn't break the entire system.
^ permalink raw reply
* Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel
From: Edward Cree @ 2018-04-13 12:36 UTC (permalink / raw)
To: David Miller; +Cc: linux-net-drivers, netdev
In-Reply-To: <20180412.113300.475644883265871487.davem@davemloft.net>
It turns out this may all be moot anyway: I figured out why I was seeing
ARFS storms and it wasn't the configuration issue I originally blamed.
My current ndo_rx_flow_steer() implementation, efx_filter_rfs(), returns
0 for success, but the caller expects a filter ID to be returned (which
we can't give it because we don't know what the filter ID will be until
we start mucking around in the software state that's now protected by a
sleepable lock).
As a result, when we call rps_may_expire_flow(), and pass it the _actual_
filter ID, this doesn't match the one set_rps_cpu() recorded, so the
function returns true and we immediately expire the filter. Then the
next packet to come along isn't steered, so ARFS asks us to insert a
steering filter again.
As a quick fix I've simply tried making the rps_may_expire_flow() calls
also pass a filter ID of 0, which prevents the ARFS storms. This is
safe; it may cause us to delay expiring a filter when flow_ids collide,
but that can happen anyway with other drivers' implementations (e.g.
mlx4 and mlx5 can potentially reuse filter IDs) so I presume it is OK.
I'll post a v2 with that fix in place of this Patch #2 shortly, then try
to follow up with a counter-generated ID (similar to what mlx have).
-Ed
^ permalink raw reply
* Atlantic driver 4.16 stable request
From: Igor Russkikh @ 2018-04-13 12:03 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Nadezhda Krupnina, Simon Edelhaus
Hi David,
Could you please consider queuing to v4.16:
9a11aff net: aquantia: oops when shutdown on already stopped device
cce96d1 net: aquantia: Regression on reset with 1.x firmware
These are both critical and well tested by our team.
Thanks in advance!
^ permalink raw reply
* [PATCH net] team: avoid adding twice the same option to the event list
From: Paolo Abeni @ 2018-04-13 11:59 UTC (permalink / raw)
To: netdev; +Cc: Jiri Pirko, David S. Miller
When parsing the options provided by the user space,
team_nl_cmd_options_set() insert them in a temporary list to send
multiple events with a single message.
While each option's attribute is correctly validated, the code does
not check for duplicate entries before inserting into the event
list.
Exploiting the above, the syzbot was able to trigger the following
splat:
kernel BUG at lib/list_debug.c:31!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 4466 Comm: syzkaller556835 Not tainted 4.16.0+ #17
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__list_add_valid+0xaa/0xb0 lib/list_debug.c:29
RSP: 0018:ffff8801b04bf248 EFLAGS: 00010286
RAX: 0000000000000058 RBX: ffff8801c8fc7a90 RCX: 0000000000000000
RDX: 0000000000000058 RSI: ffffffff815fbf41 RDI: ffffed0036097e3f
RBP: ffff8801b04bf260 R08: ffff8801b0b2a700 R09: ffffed003b604f90
R10: ffffed003b604f90 R11: ffff8801db027c87 R12: ffff8801c8fc7a90
R13: ffff8801c8fc7a90 R14: dffffc0000000000 R15: 0000000000000000
FS: 0000000000b98880(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000043fc30 CR3: 00000001afe8e000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__list_add include/linux/list.h:60 [inline]
list_add include/linux/list.h:79 [inline]
team_nl_cmd_options_set+0x9ff/0x12b0 drivers/net/team/team.c:2571
genl_family_rcv_msg+0x889/0x1120 net/netlink/genetlink.c:599
genl_rcv_msg+0xc6/0x170 net/netlink/genetlink.c:624
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x58b/0x740 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:639
___sys_sendmsg+0x805/0x940 net/socket.c:2117
__sys_sendmsg+0x115/0x270 net/socket.c:2155
SYSC_sendmsg net/socket.c:2164 [inline]
SyS_sendmsg+0x29/0x30 net/socket.c:2162
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x4458b9
RSP: 002b:00007ffd1d4a7278 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 000000000000001b RCX: 00000000004458b9
RDX: 0000000000000010 RSI: 0000000020000d00 RDI: 0000000000000004
RBP: 00000000004a74ed R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000213 R12: 00007ffd1d4a7348
R13: 0000000000402a60 R14: 0000000000000000 R15: 0000000000000000
Code: 75 e8 eb a9 48 89 f7 48 89 75 e8 e8 d1 85 7b fe 48 8b 75 e8 eb bb 48
89 f2 48 89 d9 4c 89 e6 48 c7 c7 a0 84 d8 87 e8 ea 67 28 fe <0f> 0b 0f 1f
40 00 48 b8 00 00 00 00 00 fc ff df 55 48 89 e5 41
RIP: __list_add_valid+0xaa/0xb0 lib/list_debug.c:29 RSP: ffff8801b04bf248
This changeset addresses the avoiding list_add() if the current
option is already present in the event list.
Reported-and-tested-by: syzbot+4d4af685432dc0e56c91@syzkaller.appspotmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Fixes: 2fcdb2c9e659 ("team: allow to send multiple set events in one message")
---
drivers/net/team/team.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index a6c6ce19eeee..acbe84967834 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -261,6 +261,17 @@ static void __team_option_inst_mark_removed_port(struct team *team,
}
}
+static bool __team_option_inst_tmp_find(const struct list_head *opts,
+ const struct team_option_inst *needle)
+{
+ struct team_option_inst *opt_inst;
+
+ list_for_each_entry(opt_inst, opts, tmp_list)
+ if (opt_inst == needle)
+ return true;
+ return false;
+}
+
static int __team_options_register(struct team *team,
const struct team_option *option,
size_t option_count)
@@ -2568,6 +2579,14 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
if (err)
goto team_put;
opt_inst->changed = true;
+
+ /* dumb/evil user-space can send us duplicate opt,
+ * keep only the last one
+ */
+ if (__team_option_inst_tmp_find(&opt_inst_list,
+ opt_inst))
+ continue;
+
list_add(&opt_inst->tmp_list, &opt_inst_list);
}
if (!opt_found) {
--
2.14.3
^ permalink raw reply related
* Re: net: hang in unregister_netdevice: waiting for lo to become free
From: Neil Horman @ 2018-04-13 11:37 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Tommi Rantala, Xin Long, David Ahern, Daniel Borkmann, Cong Wang,
David Miller, Eric Dumazet, Willem de Bruijn, Jakub Kicinski,
Rasmus Villemoes, netdev, LKML, Alexey Kuznetsov,
Hideaki YOSHIFUJI, syzkaller, Dan Streetman, Eric W. Biederman,
Alexey Kodanev, Marcelo Ricardo Leitner <marcelo.leit
In-Reply-To: <CACT4Y+Z2kdjsYUs-H9aSTcNW-FSKqm1__fg3eOq16H-E=X8oZg@mail.gmail.com>
On Thu, Apr 12, 2018 at 02:15:30PM +0200, Dmitry Vyukov wrote:
> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
> <tommi.t.rantala@nokia.com> wrote:
> > On 20.02.2018 18:26, Neil Horman wrote:
> >>
> >> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
> >>>
> >>> On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
> >>> <tommi.t.rantala@nokia.com> wrote:
> >>>>
> >>>> On 19.02.2018 20:59, Dmitry Vyukov wrote:
> >>>>>
> >>>>> Is this meant to be fixed already? I am still seeing this on the
> >>>>> latest upstream tree.
> >>>>>
> >>>>
> >>>> These two commits are in v4.16-rc1:
> >>>>
> >>>> commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
> >>>> Author: Tommi Rantala <tommi.t.rantala@nokia.com>
> >>>> Date: Mon Feb 5 21:48:14 2018 +0200
> >>>>
> >>>> sctp: fix dst refcnt leak in sctp_v4_get_dst
> >>>> ...
> >>>> Fixes: 410f03831 ("sctp: add routing output fallback")
> >>>> Fixes: 0ca50d12f ("sctp: fix src address selection if using
> >>>> secondary
> >>>> addresses")
> >>>>
> >>>>
> >>>> commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2
> >>>> Author: Alexey Kodanev <alexey.kodanev@oracle.com>
> >>>> Date: Mon Feb 5 15:10:35 2018 +0300
> >>>>
> >>>> sctp: fix dst refcnt leak in sctp_v6_get_dst()
> >>>> ...
> >>>> Fixes: dbc2b5e9a09e ("sctp: fix src address selection if using
> >>>> secondary
> >>>> addresses for ipv6")
> >>>>
> >>>>
> >>>> I guess we missed something if it's still reproducible.
> >>>>
> >>>> I can check it later this week, unless someone else beat me to it.
> >>>
> >>>
> >>> Hi Tommi,
> >>>
> >>> Hmmm, I can't claim that it's exactly the same bug. Perhaps it's
> >>> another one then. But I am still seeing these:
> >>>
> >>> [ 58.799130] unregister_netdevice: waiting for lo to become free.
> >>> Usage count = 4
> >>> [ 60.847138] unregister_netdevice: waiting for lo to become free.
> >>> Usage count = 4
> >>> [ 62.895093] unregister_netdevice: waiting for lo to become free.
> >>> Usage count = 4
> >>> [ 64.943103] unregister_netdevice: waiting for lo to become free.
> >>> Usage count = 4
> >>>
> >>> on upstream tree pulled ~12 hours ago.
> >>>
> >> Can you write a systemtap script to probe dev_hold, and dev_put, printing
> >> out a
> >> backtrace if the device name matches "lo". That should tell us
> >> definitively if
> >> the problem is in the same location or not
> >
> >
> > Hi Dmitry, I tested with the reproducer and the kernel .config file that you
> > sent in the first email in this thread:
> >
> > With 4.16-rc2 unable to reproduce.
> >
> > With 4.15-rc9 bug reproducible, and I get "unregister_netdevice: waiting for
> > lo to become free. Usage count = 3"
> >
> > With 4.15-rc9 and Alexey's "sctp: fix dst refcnt leak in sctp_v6_get_dst()"
> > cherry-picked on top, unable to reproduce.
> >
> >
> > Is syzkaller doing something else now to trigger the bug...?
> > Can you still trigger the bug with the same reproducer?
>
> Hi Neil, Tommi,
>
> Reviving this old thread about "unregister_netdevice: waiting for lo
> to become free. Usage count = 3" hangs.
> I still did not have time to deep dive into what happens there (too
> many bugs coming from syzbot). But this still actively happens and I
> suspect accounts to a significant portion of various hang reports,
> which are quite unpleasant.
>
> One idea that could make it all simpler:
>
> Is this wait loop in netdev_wait_allrefs() supposed to wait for any
> prolonged periods of time under any non-buggy conditions? E.g. more
> than 1-2 minutes?
As the name implies, its supposed to wait for the reference count to be zero
indefinately, but yes, under normal operation, its intended to not have to wait
very long at all. The issuance of the NETDEV_UNREGISTER_FINAL notification is
meant to be a subscribable signal to any code path holding a reference that it
needs to be dropped so that the progress can be made.
Note that the "waiting for %s to become free" message is triggered after 10
seconds of waiting, and is likely the trigger you want, Its just an emergency
level log message rather a WARN. I don't think we want to change that
permanently, but you could certainly alter it in the code to cause syzbot to
catch it (i.e. WARN_ON(time_after(jiffies, warning_time + 10 * HZ)) )
> If it only supposed to wait briefly for things that already supposed
> to be shutting down, and we add a WARNING there after some timeout,
> then syzbot will report all info how/when it happens, hopefully
> extracting reproducers, and all the nice things.
> But this WARNING should not have any false positives under any
> realistic conditions (e.g. waiting for arrival of remote packets with
> large timeouts).
>
> Looking at some task hung reports, it seems that this code holds some
> mutexes, takes workqueue thread and prevents any progress with
> destruction of other devices (and net namespace creation/destruction),
> so I guess it should not wait for any indefinite periods of time?
Well, it drops everything and sleeps periodically, so its safe in and of itself.
The problem is its waiting for the reference count of a device to drop to zero,
and some other execution context isn't taking the appropriate action to do that.
Neil
>
^ permalink raw reply
* Re: [net] xfrm: cover crypto status in xfrm_input
From: Steffen Klassert @ 2018-04-13 11:09 UTC (permalink / raw)
To: Jacek Kalwas; +Cc: davem, netdev, intel-wired-lan
In-Reply-To: <20180412190315.3102-3-jacek.kalwas@intel.com>
On Thu, Apr 12, 2018 at 12:03:15PM -0700, Jacek Kalwas wrote:
> Status checking in xfrm_input doesn't cover CRYPTO_GENERIC_ERROR and
> CRYPTO_INVALID_PACKET_SYNTAX.
>
> Given patch adds additional check for CRYPTO_INVALID_PACKET_SYNTAX and
> treats CRYPTO_GENERIC_ERROR as status matching LINUX_MIB_XFRMINERROR.
>
> Signed-off-by: Jacek Kalwas <jacek.kalwas@intel.com>
> ---
> net/xfrm/xfrm_input.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> index 352abca2605f..08d70ea774f9 100644
> --- a/net/xfrm/xfrm_input.c
> +++ b/net/xfrm/xfrm_input.c
> @@ -285,7 +285,12 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
> goto drop;
> }
>
> - XFRM_INC_STATS(net, LINUX_MIB_XFRMINBUFFERERROR);
> + if (xo->status & CRYPTO_INVALID_PACKET_SYNTAX) {
> + XFRM_INC_STATS(net, LINUX_MIB_XFRMINBUFFERERROR);
> + goto drop;
> + }
Please consider adding separate statistic counters for offloading.
Reusing some other counter does not make it more usfull as it is now.
Some time ago, each statistic counter was bumped at a unique place,
so it was easy to identify where the packet was dropped. Unfortunately
this changed over the years. This was one of the concerns the userspace
IPsec developers had during the IPsec workshop we held recently. So I
think it is better to add new counters insted of reusing old ones here.
^ permalink raw reply
* Re: tcp hang when socket fills up ?
From: Dominique Martinet @ 2018-04-13 9:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <20180406090720.GA31845@nautica>
Note this is mostly me talking to myself, but in case anyone else hits
the same issues I might as well post my meagre progress.
Dominique Martinet wrote on Fri, Apr 06, 2018:
> (current kernel: vanilla 4.14.29)
reproduced in a fedora VM on that host with a 4.16.1-300.fc28.x86_64
kernel, since this one has DEBUG_INFO=y and I was lazy (but haven't seen
any patch about that kind of stuff recently so probably still valid)
Other main difference is the qdisc, VM is using fq_codel, host is
directly on wireless so mq with 4 pfifo_fast queues - it is harder to
reproduce on the VM (even on another VM with the same kernel) so I'd
put the difference down to the qdisc, but I was able to reproduce with
both ultimately.
(update: it actually was still fairly easy to reproduce until it got
later (coworkers left?), going from ~5-15s to reproduce to multiple
minutes, so this likely depends on net quality a lot. I couldn't
reproduce by fiddling with netem on a local network though...)
> [please find previous email for setup/tcpdump output]
So I have a crash dump with a socket / inet_sock that are blocked, since
this is a VM I even get gdb in bonus..
With the crash dump, I can confirm that the socket is not available for
writing (sk->sk_sndbuf - sk->sk_wmem_queued < sk->sk_wmem_queued >> 1),
but that doesn't help much if I can't tell why we're not taking acks in
With gdb, I set a breakpoint to tcp_ack (net/ipv4/tcp_input.c) as I
think that's the function that should handle my ack, and that gets the
replay.
First, abusing next, the flow seems to be something like
(I folded if/else not taken)
static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
struct tcp_sacktag_state sack_state;
struct rate_sample rs = { .prior_delivered = 0 };
u32 prior_snd_una = tp->snd_una;
bool is_sack_reneg = tp->is_sack_reneg;
u32 ack_seq = TCP_SKB_CB(skb)->seq;
u32 ack = TCP_SKB_CB(skb)->ack_seq;
bool is_dupack = false;
int prior_packets = tp->packets_out;
u32 delivered = tp->delivered;
u32 lost = tp->lost;
int rexmit = REXMIT_NONE; /* Flag to (re)transmit to recover
losses */
u32 prior_fack;
sack_state.first_sackt = 0;
sack_state.rate = &rs;
/* We very likely will need to access rtx queue. */
prefetch(sk->tcp_rtx_queue.rb_node);
/* If the ack is older than previous acks
* then we can probably ignore it.
*/
if (before(ack, prior_snd_una)) {
}
/* If the ack includes data we haven't sent yet, discard
* this segment (RFC793 Section 3.9).
*/
if (after(ack, tp->snd_nxt))
if (after(ack, prior_snd_una)) {
}
prior_fack = tcp_is_sack(tp) ? tcp_highest_sack_seq(tp) :
tp->snd_una;
rs.prior_in_flight = tcp_packets_in_flight(tp);
/* ts_recent update must be made after we are sure that the
packet
* is in window.
*/
if (flag & FLAG_UPDATE_TS_RECENT)
if (!(flag & FLAG_SLOWPATH) && after(ack, prior_snd_una)) {
} else {
u32 ack_ev_flags = CA_ACK_SLOWPATH;
if (ack_seq != TCP_SKB_CB(skb)->end_seq)
else
NET_INC_STATS(sock_net(sk),
LINUX_MIB_TCPPUREACKS);
flag |= tcp_ack_update_window(sk, skb, ack, ack_seq);
if (TCP_SKB_CB(skb)->sacked)
if (tcp_ecn_rcv_ecn_echo(tp, tcp_hdr(skb))) {
}
if (flag & FLAG_WIN_UPDATE)
tcp_in_ack_event(sk, ack_ev_flags);
}
/* We passed data and got it acked, remove any soft error
* log. Something worked...
*/
sk->sk_err_soft = 0;
icsk->icsk_probes_out = 0;
tp->rcv_tstamp = tcp_jiffies32;
if (!prior_packets)
goto no_queue;
no_queue:
/* If data was DSACKed, see if we can undo a cwnd reduction. */
if (flag & FLAG_DSACKING_ACK)
tcp_fastretrans_alert(sk, prior_snd_una, is_dupack,
&flag,
&rexmit);
/* If this ack opens up a zero window, clear backoff. It was
* being used to time the probes, and is probably far higher
than
* it needs to be for normal retransmission.
*/
tcp_ack_probe(sk);
if (tp->tlp_high_seq)
tcp_process_tlp_ack(sk, ack, flag);
return 1;
And here is 'info local' towards the end of the function:
icsk = 0xffff88001740b800
tp = 0xffff88001740b800
sack_state = {reord = 84, first_sackt = 0, last_sackt = 0, rate = 0xffff88003fc83ae0, flag = 0, mss_now = 0}
rs = {prior_mstamp = 0, prior_delivered = 0, delivered = 0, interval_us = 0, rtt_us = 0, losses = 0, acked_sacked = 0, prior_in_flight = 0, is_app_limited = false, is_retrans = false, is_ack_delayed = false}
prior_snd_una = 2896339291
is_sack_reneg = false
ack_seq = 2651638615
ack = 2896339291
is_dupack = false
prior_packets = 0
delivered = 172
lost = 0
rexmit = 0
prior_fack = 2896339291
__vpp_verify = <optimized out>
pao_ID__ = <optimized out>
pao_tmp__ = <optimized out>
pao_ID__ = <optimized out>
pao_tmp__ = <optimized out>
pao_ID__ = <optimized out>
pao_tmp__ = <optimized out>
So as I was seeing, we have ack = prior_fack = prior_snd_una (which is > ack_seq)
We're in the !prior_packets goto to no_queue though so we don't pass
tcp_clean_rtx_queue - so that explains why the replays don't help. I'm
ok with that. But all these traces actually don't tell me why the first
time we saw that packed didn't take the ack and decreate sk_wmem_queued
properly.
This isn't easy enough to reproduce that I feel confident grabbing the
first call to that function that fails though, so I guess I'll actually
have to read the code I'm debugging instead of trying to just plow
through it...
Hints still welcome, if anyone has an idea.
--
Dominique Martinet | Asmadeus
^ permalink raw reply
* [PATCH v2] selftests: add headers_install to lib.mk
From: Anders Roxell @ 2018-04-13 9:03 UTC (permalink / raw)
To: shuah, yamada.masahiro, michal.lkml
Cc: linux-kselftest, linux-kbuild, linux-kernel, netdev, linux-gpio,
fathi.boudra, Anders Roxell
In-Reply-To: <20180412102302.4532-1-anders.roxell@linaro.org>
If the kernel headers aren't installed we can't build all the tests.
Add a new make target rule 'khdr' in the file lib.mk to generate the
kernel headers and that gets include for every test-dir Makefile that
includes lib.mk If the testdir in turn have its own sub-dirs the
top_srcdir needs to be set to the linux-rootdir to be able to generate
the kernel headers.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Reviewed-by: Fathi Boudra <fathi.boudra@linaro.org>
---
Makefile | 14 +-------------
scripts/subarch.include | 13 +++++++++++++
tools/testing/selftests/android/Makefile | 2 +-
tools/testing/selftests/android/ion/Makefile | 1 +
tools/testing/selftests/bpf/Makefile | 5 ++---
tools/testing/selftests/futex/functional/Makefile | 1 +
tools/testing/selftests/gpio/Makefile | 4 ----
tools/testing/selftests/kvm/Makefile | 6 +-----
tools/testing/selftests/lib.mk | 10 ++++++++++
tools/testing/selftests/vm/Makefile | 3 ---
10 files changed, 30 insertions(+), 29 deletions(-)
create mode 100644 scripts/subarch.include
diff --git a/Makefile b/Makefile
index 74567b0ec2f0..0c47935d48a2 100644
--- a/Makefile
+++ b/Makefile
@@ -286,19 +286,7 @@ KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
-# SUBARCH tells the usermode build what the underlying arch is. That is set
-# first, and if a usermode build is happening, the "ARCH=um" on the command
-# line overrides the setting of ARCH below. If a native build is happening,
-# then ARCH is assigned, getting whatever value it gets normally, and
-# SUBARCH is subsequently ignored.
-
-SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
- -e s/sun4u/sparc64/ \
- -e s/arm.*/arm/ -e s/sa110/arm/ \
- -e s/s390x/s390/ -e s/parisc64/parisc/ \
- -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
- -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
- -e s/riscv.*/riscv/)
+include scripts/subarch.include
# Cross compiling and selecting different set of gcc/bin-utils
# ---------------------------------------------------------------------------
diff --git a/scripts/subarch.include b/scripts/subarch.include
new file mode 100644
index 000000000000..650682821126
--- /dev/null
+++ b/scripts/subarch.include
@@ -0,0 +1,13 @@
+# SUBARCH tells the usermode build what the underlying arch is. That is set
+# first, and if a usermode build is happening, the "ARCH=um" on the command
+# line overrides the setting of ARCH below. If a native build is happening,
+# then ARCH is assigned, getting whatever value it gets normally, and
+# SUBARCH is subsequently ignored.
+
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+ -e s/sun4u/sparc64/ \
+ -e s/arm.*/arm/ -e s/sa110/arm/ \
+ -e s/s390x/s390/ -e s/parisc64/parisc/ \
+ -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
+ -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
+ -e s/riscv.*/riscv/)
diff --git a/tools/testing/selftests/android/Makefile b/tools/testing/selftests/android/Makefile
index f6304d2be90c..087390bbad68 100644
--- a/tools/testing/selftests/android/Makefile
+++ b/tools/testing/selftests/android/Makefile
@@ -6,7 +6,7 @@ TEST_PROGS := run.sh
include ../lib.mk
-all:
+all: khdr
@for DIR in $(SUBDIRS); do \
BUILD_TARGET=$(OUTPUT)/$$DIR; \
mkdir $$BUILD_TARGET -p; \
diff --git a/tools/testing/selftests/android/ion/Makefile b/tools/testing/selftests/android/ion/Makefile
index e03695287f76..14ecd9805748 100644
--- a/tools/testing/selftests/android/ion/Makefile
+++ b/tools/testing/selftests/android/ion/Makefile
@@ -11,6 +11,7 @@ $(TEST_GEN_FILES): ipcsocket.c ionutils.c
TEST_PROGS := ion_test.sh
include ../../lib.mk
+top_srcdir = ../../../../../
$(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
$(OUTPUT)/ionapp_import: ionapp_import.c ipcsocket.c ionutils.c
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 0a315ddabbf4..cc611a284087 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -16,9 +16,8 @@ LDLIBS += -lcap -lelf -lrt -lpthread
TEST_CUSTOM_PROGS = $(OUTPUT)/urandom_read
all: $(TEST_CUSTOM_PROGS)
-$(TEST_CUSTOM_PROGS): urandom_read
-
-urandom_read: urandom_read.c
+$(TEST_CUSTOM_PROGS):| khdr
+$(TEST_CUSTOM_PROGS): urandom_read.c
$(CC) -o $(TEST_CUSTOM_PROGS) -static $<
# Order correspond to 'make run_tests' order
diff --git a/tools/testing/selftests/futex/functional/Makefile b/tools/testing/selftests/futex/functional/Makefile
index ff8feca49746..9f602fb40241 100644
--- a/tools/testing/selftests/futex/functional/Makefile
+++ b/tools/testing/selftests/futex/functional/Makefile
@@ -19,5 +19,6 @@ TEST_GEN_FILES := \
TEST_PROGS := run.sh
include ../../lib.mk
+top_srcdir = ../../../../../
$(TEST_GEN_FILES): $(HEADERS)
diff --git a/tools/testing/selftests/gpio/Makefile b/tools/testing/selftests/gpio/Makefile
index 1bbb47565c55..768b2be010db 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -25,7 +25,3 @@ $(BINARIES): ../../../gpio/gpio-utils.o ../../../../usr/include/linux/gpio.h
../../../gpio/gpio-utils.o:
make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio
-
-../../../../usr/include/linux/gpio.h:
- make -C ../../../.. headers_install INSTALL_HDR_PATH=$(shell pwd)/../../../../usr/
-
diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index dc44de904797..ba03ce334212 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -31,9 +31,5 @@ $(LIBKVM_OBJ): $(OUTPUT)/%.o: %.c
$(OUTPUT)/libkvm.a: $(LIBKVM_OBJ)
$(AR) crs $@ $^
-$(LINUX_HDR_PATH):
- make -C $(top_srcdir) headers_install
-
-all: $(STATIC_LIBS) $(LINUX_HDR_PATH)
+all: $(STATIC_LIBS)
$(TEST_GEN_PROGS): $(STATIC_LIBS)
-$(TEST_GEN_PROGS) $(LIBKVM_OBJ): | $(LINUX_HDR_PATH)
diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 195e9d4739a9..1b1e8135715e 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -16,8 +16,18 @@ TEST_GEN_PROGS := $(patsubst %,$(OUTPUT)/%,$(TEST_GEN_PROGS))
TEST_GEN_PROGS_EXTENDED := $(patsubst %,$(OUTPUT)/%,$(TEST_GEN_PROGS_EXTENDED))
TEST_GEN_FILES := $(patsubst %,$(OUTPUT)/%,$(TEST_GEN_FILES))
+top_srcdir ?= ../../../../
+include $(top_srcdir)/scripts/subarch.include
+ARCH ?= $(SUBARCH)
+
all: $(TEST_GEN_PROGS) $(TEST_GEN_PROGS_EXTENDED) $(TEST_GEN_FILES)
+.PHONY: khdr
+khdr:
+ make ARCH=$(ARCH) -C $(top_srcdir) headers_install
+
+$(TEST_GEN_PROGS) $(TEST_GEN_PROGS_EXTENDED) $(TEST_GEN_FILES):| khdr
+
.ONESHELL:
define RUN_TESTS
@export KSFT_TAP_LEVEL=`echo 1`;
diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile
index fdefa2295ddc..1e34a40745ef 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -29,6 +29,3 @@ $(OUTPUT)/userfaultfd: ../../../../usr/include/linux/kernel.h
$(OUTPUT)/userfaultfd: LDLIBS += -lpthread
$(OUTPUT)/mlock-random-test: LDLIBS += -lcap
-
-../../../../usr/include/linux/kernel.h:
- make -C ../../../.. headers_install
--
2.16.3
^ permalink raw reply related
* Re: SRIOV switchdev mode BoF minutes
From: Or Gerlitz @ 2018-04-13 8:57 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: David Miller, Anjali Singhai Jain, Andy Gospodarek, Michael Chan,
Simon Horman, Jakub Kicinski, John Fastabend, Saeed Mahameed,
Jiri Pirko, Rony Efraim, Linux Netdev List
In-Reply-To: <CAJ3xEMj824Y-Erod3e27VO0GmntyWE8u1PQ5-Ff-iZrCn=2X9A@mail.gmail.com>
On Fri, Apr 13, 2018 at 11:56 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar
> <sridhar.samudrala@intel.com> wrote:
>> On 4/12/2018 1:20 PM, Or Gerlitz wrote:
>>>
>>> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
>>> <sridhar.samudrala@intel.com> wrote:
>>>>
>>>> On 11/12/2017 11:49 AM, Or Gerlitz wrote:
>>>>>
>>>>> Hi Dave and all,
>>>>>
>>>>> During and after the BoF on SRIOV switchdev mode, we came into a
>>>>> consensus among the developers from four different HW vendors (CC
>>>>> audience) that a correct thing to do would be to disallow any new
>>>>> extensions to the legacy mode.
>>>>>
>>>>> The idea is to put focus on the new mode and not add new UAPIs and
>>>>> kernel code which was turned to be a wrong design which does not allow
>>>>> for properly offloading a kernel switching SW model to e-switch HW.
>>>>>
>>>>> We also had a good session the day after regarding alignment for the
>>>>> representation model of the uplink (physical port) and PF/s.
>>>>>
>>>>> The VF representor netdevs exist for all drivers that support the new
>>>>> mode but the representation for the uplink and PF wasn't the same for
>>>>> all. The decision was to represent the uplink and PFs vports in the
>>>>> same manner done for VFs, using rep netdevs. This alignment would
>>>>> provide a more strict and clear view of the kernel model for e-switch
>>>>> to users and upper layer control plane SW.
>>>>>
>>>> I don't see any changes in the Mellanox/other drivers to move to this new
>>>> model to enable the uplink and PF port representors, any updates?
>>>
>>> Yeah, I am worked on that but didn't get to finalize the upstreaming
>>> so far. I have resumed
>>> the work and plan uplink rep in mlx5 to replace the PF being uplink rep
>>> for 4.18
>>>
>>>> It would be really nice to highlight the pros and cons of the old versus
>>>> the
>>>> new model.
>>>>
>>>> We are looking into adding switchdev support for our new 100Gb ice driver
>>>> and could use some feedback on the direction we should be taking.
>>>
>>> good news.
>>>
>>> The uplink rep is clear cut that needs to be a rep device representing
>>> the uplink just like vf
>>> rep represents the vport toward the vf - please just do it correct
>>> from the begining
>>>
>> Having an uplink rep will definitely help implement the slow path with
>> flat/vlan network
>> scenarios by not having to add PF to the bridge.
>>
>> But how do they help with a vxlan overlay scenario? In case of overlays, the
>> slow path has to go via vxlan -> ip stack -> pf?
>
> in overlay networks scheme, the uplink has the VTEP ip and is not connected
the uplink rep has the vtep ip
> to the bridge, e.g you use ovs you have vf reps and vxlan ports connected to ovs
> and the ip stack routes through the uplink rep
>
>>
>> What about pf-rep?
>>
^ permalink raw reply
* Re: SRIOV switchdev mode BoF minutes
From: Or Gerlitz @ 2018-04-13 8:56 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: David Miller, Anjali Singhai Jain, Andy Gospodarek, Michael Chan,
Simon Horman, Jakub Kicinski, John Fastabend, Saeed Mahameed,
Jiri Pirko, Rony Efraim, Linux Netdev List
In-Reply-To: <d1e4cfb4-513e-14d4-9007-25d1b02e8dcd@intel.com>
On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
> On 4/12/2018 1:20 PM, Or Gerlitz wrote:
>>
>> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
>> <sridhar.samudrala@intel.com> wrote:
>>>
>>> On 11/12/2017 11:49 AM, Or Gerlitz wrote:
>>>>
>>>> Hi Dave and all,
>>>>
>>>> During and after the BoF on SRIOV switchdev mode, we came into a
>>>> consensus among the developers from four different HW vendors (CC
>>>> audience) that a correct thing to do would be to disallow any new
>>>> extensions to the legacy mode.
>>>>
>>>> The idea is to put focus on the new mode and not add new UAPIs and
>>>> kernel code which was turned to be a wrong design which does not allow
>>>> for properly offloading a kernel switching SW model to e-switch HW.
>>>>
>>>> We also had a good session the day after regarding alignment for the
>>>> representation model of the uplink (physical port) and PF/s.
>>>>
>>>> The VF representor netdevs exist for all drivers that support the new
>>>> mode but the representation for the uplink and PF wasn't the same for
>>>> all. The decision was to represent the uplink and PFs vports in the
>>>> same manner done for VFs, using rep netdevs. This alignment would
>>>> provide a more strict and clear view of the kernel model for e-switch
>>>> to users and upper layer control plane SW.
>>>>
>>> I don't see any changes in the Mellanox/other drivers to move to this new
>>> model to enable the uplink and PF port representors, any updates?
>>
>> Yeah, I am worked on that but didn't get to finalize the upstreaming
>> so far. I have resumed
>> the work and plan uplink rep in mlx5 to replace the PF being uplink rep
>> for 4.18
>>
>>> It would be really nice to highlight the pros and cons of the old versus
>>> the
>>> new model.
>>>
>>> We are looking into adding switchdev support for our new 100Gb ice driver
>>> and could use some feedback on the direction we should be taking.
>>
>> good news.
>>
>> The uplink rep is clear cut that needs to be a rep device representing
>> the uplink just like vf
>> rep represents the vport toward the vf - please just do it correct
>> from the begining
>>
> Having an uplink rep will definitely help implement the slow path with
> flat/vlan network
> scenarios by not having to add PF to the bridge.
>
> But how do they help with a vxlan overlay scenario? In case of overlays, the
> slow path has to go via vxlan -> ip stack -> pf?
in overlay networks scheme, the uplink has the VTEP ip and is not connected
to the bridge, e.g you use ovs you have vf reps and vxlan ports connected to ovs
and the ip stack routes through the uplink rep
>
> What about pf-rep?
>
^ permalink raw reply
* Re: KMSAN: uninit-value in __netif_receive_skb_core
From: Dmitry Vyukov @ 2018-04-13 8:31 UTC (permalink / raw)
To: Toshiaki Makita
Cc: syzbot, bpoirier, David Miller, Eric Dumazet, Reshetova, Elena,
Hans Liljestrand, Kees Cook, LKML, Mike Maloney, netdev,
rami.rosen, syzkaller-bugs, Willem de Bruijn
In-Reply-To: <be9e24ac-c9b8-6972-f560-c9daea817d28@lab.ntt.co.jp>
On Fri, Apr 13, 2018 at 10:20 AM, Toshiaki Makita
<makita.toshiaki@lab.ntt.co.jp> wrote:
> On 2018/04/12 17:03, Dmitry Vyukov wrote:
>> On Thu, Apr 12, 2018 at 10:01 AM, syzbot
>> <syzbot+b202b7208664142954fa@syzkaller.appspotmail.com> wrote:
>>> Hello,
>>>
>>> syzbot hit the following crash on https://github.com/google/kmsan.git/master
>>> commit
>>> e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +0000)
>>> kmsan: temporarily disable visitAsmInstruction() to help syzbot
>>> syzbot dashboard link:
>>> https://syzkaller.appspot.com/bug?extid=b202b7208664142954fa
>>>
>>> Unfortunately, I don't have any reproducer for this crash yet.
>>> Raw console output:
>>> https://syzkaller.appspot.com/x/log.txt?id=5356516437655552
>>> Kernel config:
>>> https://syzkaller.appspot.com/x/.config?id=6627248707860932248
>>> compiler: clang version 7.0.0 (trunk 329391)
>>
>> +Toshiaki as this seems to be related to the recent vlan tagging changes.
>
> seems not...
> "Uninit was stored to memory at:" shows uninitialized memory was stored
> before where I modified the code (skb_reorder_vlan_header).
>
> I'm not sure what this uninit memory means.
> To me it looks like the memory is initialized by user provided data.
>
> (iov in packet sock -> skb->data -> skb->protocol)
>
> The reproducer provides 4 bytes after ethernet header, so it should be
> sufficient for a vlan tag. This will set skb->len to 4 and fill the
> 4-byte contents in packet_snd(). skb_vlan_untag() is reading the user
> provided 4-byte skb->data. It is ensured that skb_vlan_untag() does not
> read beyond skb->len since it calls pskb_may_pull(). At this point I am
> failing to find what I am missing.
Eric,
You mentioned something about assumption that the
__vlan_insert_inner_tag() helper would only be called from
__netif_receive_skb_core(). Can you elaborate?
>> This also seems to be related to
>> https://groups.google.com/d/msg/syzkaller-bugs/VRH9NnUi2k0/90GYsAeRBgAJ
>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+b202b7208664142954fa@syzkaller.appspotmail.com
>>> It will help syzbot understand when the bug is fixed. See footer for
>>> details.
>>> If you forward the report, please keep this part and the footer.
>>>
>>> ==================================================================
>>> BUG: KMSAN: uninit-value in __read_once_size include/linux/compiler.h:197
>>> [inline]
>>> BUG: KMSAN: uninit-value in deliver_ptype_list_skb net/core/dev.c:1908
>>> [inline]
>>> BUG: KMSAN: uninit-value in __netif_receive_skb_core+0x4630/0x4a80
>>> net/core/dev.c:4545
>>> CPU: 0 PID: 5999 Comm: syz-executor3 Not tainted 4.16.0+ #82
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> Call Trace:
>>> <IRQ>
>>> __dump_stack lib/dump_stack.c:17 [inline]
>>> dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>>> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>>> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
>>> __read_once_size include/linux/compiler.h:197 [inline]
>>> deliver_ptype_list_skb net/core/dev.c:1908 [inline]
>>> __netif_receive_skb_core+0x4630/0x4a80 net/core/dev.c:4545
>>> __netif_receive_skb net/core/dev.c:4627 [inline]
>>> process_backlog+0x62d/0xe20 net/core/dev.c:5307
>>> napi_poll net/core/dev.c:5705 [inline]
>>> net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
>>> __do_softirq+0x56d/0x93d kernel/softirq.c:285
>>> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040
>>> </IRQ>
>>> do_softirq kernel/softirq.c:329 [inline]
>>> __local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
>>> local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
>>> rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
>>> __dev_queue_xmit+0x2a31/0x2b60 net/core/dev.c:3584
>>> dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
>>> packet_snd net/packet/af_packet.c:2944 [inline]
>>> packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969
>>> sock_sendmsg_nosec net/socket.c:630 [inline]
>>> sock_sendmsg net/socket.c:640 [inline]
>>> sock_write_iter+0x3b9/0x470 net/socket.c:909
>>> do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
>>> do_iter_write+0x30d/0xd40 fs/read_write.c:932
>>> vfs_writev fs/read_write.c:977 [inline]
>>> do_writev+0x3c9/0x830 fs/read_write.c:1012
>>> SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
>>> SyS_writev+0x56/0x80 fs/read_write.c:1082
>>> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>>> RIP: 0033:0x455259
>>> RSP: 002b:00007fb53ede8c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
>>> RAX: ffffffffffffffda RBX: 00007fb53ede96d4 RCX: 0000000000455259
>>> RDX: 0000000000000001 RSI: 00000000200010c0 RDI: 0000000000000013
>>> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
>>> R13: 00000000000006cd R14: 00000000006fd3d8 R15: 0000000000000000
>>>
>>> Uninit was stored to memory at:
>>> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
>>> kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
>>> kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
>>> __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
>>> skb_vlan_untag+0x950/0xee0 include/linux/if_vlan.h:597
>>> __netif_receive_skb_core+0x70a/0x4a80 net/core/dev.c:4460
>>> __netif_receive_skb net/core/dev.c:4627 [inline]
>>> process_backlog+0x62d/0xe20 net/core/dev.c:5307
>>> napi_poll net/core/dev.c:5705 [inline]
>>> net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
>>> __do_softirq+0x56d/0x93d kernel/softirq.c:285
>>> Uninit was created at:
>>> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
>>> kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
>>> kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
>>> kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
>>> slab_post_alloc_hook mm/slab.h:445 [inline]
>>> slab_alloc_node mm/slub.c:2737 [inline]
>>> __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
>>> __kmalloc_reserve net/core/skbuff.c:138 [inline]
>>> __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
>>> alloc_skb include/linux/skbuff.h:984 [inline]
>>> alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
>>> sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
>>> packet_alloc_skb net/packet/af_packet.c:2803 [inline]
>>> packet_snd net/packet/af_packet.c:2894 [inline]
>>> packet_sendmsg+0x6444/0x8a10 net/packet/af_packet.c:2969
>>> sock_sendmsg_nosec net/socket.c:630 [inline]
>>> sock_sendmsg net/socket.c:640 [inline]
>>> sock_write_iter+0x3b9/0x470 net/socket.c:909
>>> do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
>>> do_iter_write+0x30d/0xd40 fs/read_write.c:932
>>> vfs_writev fs/read_write.c:977 [inline]
>>> do_writev+0x3c9/0x830 fs/read_write.c:1012
>>> SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
>>> SyS_writev+0x56/0x80 fs/read_write.c:1082
>>> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>>> ==================================================================
>>>
>>>
>>> ---
>>> This bug is generated by a dumb bot. It may contain errors.
>>> See https://goo.gl/tpsmEJ for details.
>>> Direct all questions to syzkaller@googlegroups.com.
>>>
>>> syzbot will keep track of this bug report.
>>> If you forgot to add the Reported-by tag, once the fix for this bug is
>>> merged
>>> into any tree, please reply to this email with:
>>> #syz fix: exact-commit-title
>>> To mark this as a duplicate of another syzbot report, please reply with:
>>> #syz dup: exact-subject-of-another-report
>>> If it's a one-off invalid bug report, please reply with:
>>> #syz invalid
>>> Note: if the crash happens again, it will cause creation of a new bug
>>> report.
>>> Note: all commands must start from beginning of the line in the email body.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "syzkaller-bugs" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to syzkaller-bugs+unsubscribe@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/syzkaller-bugs/94eb2c059ce01f643c0569a228ee%40google.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>
> --
> Toshiaki Makita
>
^ permalink raw reply
* Re: KMSAN: uninit-value in netif_skb_features
From: Toshiaki Makita @ 2018-04-13 8:28 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot
Cc: bpoirier, David Miller, Eric Dumazet, Reshetova, Elena, Kees Cook,
LKML, Mike Maloney, netdev, rami.rosen, syzkaller-bugs,
Willem de Bruijn
In-Reply-To: <CACT4Y+YfWyEx_amzVYkyaNzB2st6zcuDoVmJsE+=gAq2iJVLjg@mail.gmail.com>
On 2018/04/12 17:03, Dmitry Vyukov wrote:
> On Thu, Apr 12, 2018 at 10:01 AM, syzbot
> <syzbot+0bbe42c764feafa82c5a@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot hit the following crash on https://github.com/google/kmsan.git/master
>> commit
>> e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +0000)
>> kmsan: temporarily disable visitAsmInstruction() to help syzbot
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=0bbe42c764feafa82c5a
>>
>> So far this crash happened 30 times on
>> https://github.com/google/kmsan.git/master.
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4850744041668608
>> syzkaller reproducer:
>> https://syzkaller.appspot.com/x/repro.syz?id=6289386287136768
>> Raw console output:
>> https://syzkaller.appspot.com/x/log.txt?id=4577411249209344
>> Kernel config:
>> https://syzkaller.appspot.com/x/.config?id=6627248707860932248
>> compiler: clang version 7.0.0 (trunk 329391)
>
> +Toshiaki as this seems to be related to the recent vlan tagging changes.
Seems not.
Probably skb_vlan_tagged_multi() needs to call pskb_may_pull() before
accessing skb->data? I'll confirm it later.
> This also seems to be related to
> https://groups.google.com/d/msg/syzkaller-bugs/FNEavkB4QaM/efXl2AeRBgAJ
>
>
>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+0bbe42c764feafa82c5a@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> ==================================================================
>> BUG: KMSAN: uninit-value in eth_type_vlan include/linux/if_vlan.h:283
>> [inline]
>> BUG: KMSAN: uninit-value in skb_vlan_tagged_multi
>> include/linux/if_vlan.h:656 [inline]
>> BUG: KMSAN: uninit-value in vlan_features_check include/linux/if_vlan.h:672
>> [inline]
>> BUG: KMSAN: uninit-value in dflt_features_check net/core/dev.c:2949 [inline]
>> BUG: KMSAN: uninit-value in netif_skb_features+0xd1b/0xdc0
>> net/core/dev.c:3009
>> CPU: 1 PID: 3582 Comm: syzkaller435149 Not tainted 4.16.0+ #82
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:17 [inline]
>> dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
>> eth_type_vlan include/linux/if_vlan.h:283 [inline]
>> skb_vlan_tagged_multi include/linux/if_vlan.h:656 [inline]
>> vlan_features_check include/linux/if_vlan.h:672 [inline]
>> dflt_features_check net/core/dev.c:2949 [inline]
>> netif_skb_features+0xd1b/0xdc0 net/core/dev.c:3009
>> validate_xmit_skb+0x89/0x1320 net/core/dev.c:3084
>> __dev_queue_xmit+0x1cb2/0x2b60 net/core/dev.c:3549
>> dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
>> packet_snd net/packet/af_packet.c:2944 [inline]
>> packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969
>> sock_sendmsg_nosec net/socket.c:630 [inline]
>> sock_sendmsg net/socket.c:640 [inline]
>> sock_write_iter+0x3b9/0x470 net/socket.c:909
>> do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
>> do_iter_write+0x30d/0xd40 fs/read_write.c:932
>> vfs_writev fs/read_write.c:977 [inline]
>> do_writev+0x3c9/0x830 fs/read_write.c:1012
>> SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
>> SyS_writev+0x56/0x80 fs/read_write.c:1082
>> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> RIP: 0033:0x43ffa9
>> RSP: 002b:00007fff2cff3948 EFLAGS: 00000217 ORIG_RAX: 0000000000000014
>> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043ffa9
>> RDX: 0000000000000001 RSI: 0000000020000080 RDI: 0000000000000003
>> RBP: 00000000006cb018 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000217 R12: 00000000004018d0
>> R13: 0000000000401960 R14: 0000000000000000 R15: 0000000000000000
>>
>> Uninit was created at:
>> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
>> kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
>> kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
>> kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
>> slab_post_alloc_hook mm/slab.h:445 [inline]
>> slab_alloc_node mm/slub.c:2737 [inline]
>> __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
>> __kmalloc_reserve net/core/skbuff.c:138 [inline]
>> __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
>> alloc_skb include/linux/skbuff.h:984 [inline]
>> alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
>> sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
>> packet_alloc_skb net/packet/af_packet.c:2803 [inline]
>> packet_snd net/packet/af_packet.c:2894 [inline]
>> packet_sendmsg+0x6444/0x8a10 net/packet/af_packet.c:2969
>> sock_sendmsg_nosec net/socket.c:630 [inline]
>> sock_sendmsg net/socket.c:640 [inline]
>> sock_write_iter+0x3b9/0x470 net/socket.c:909
>> do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
>> do_iter_write+0x30d/0xd40 fs/read_write.c:932
>> vfs_writev fs/read_write.c:977 [inline]
>> do_writev+0x3c9/0x830 fs/read_write.c:1012
>> SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
>> SyS_writev+0x56/0x80 fs/read_write.c:1082
>> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> ==================================================================
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/089e082d0cb81b67d10569a2283f%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
--
Toshiaki Makita
^ permalink raw reply
* Re: KMSAN: uninit-value in __netif_receive_skb_core
From: Toshiaki Makita @ 2018-04-13 8:20 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot
Cc: bpoirier, David Miller, Eric Dumazet, Reshetova, Elena,
Hans Liljestrand, Kees Cook, LKML, Mike Maloney, netdev,
rami.rosen, syzkaller-bugs, Willem de Bruijn
In-Reply-To: <CACT4Y+Y+fco9rusF0ZYStBKkbyhZDOvkx50kp1-Lynu3UmgsLA@mail.gmail.com>
On 2018/04/12 17:03, Dmitry Vyukov wrote:
> On Thu, Apr 12, 2018 at 10:01 AM, syzbot
> <syzbot+b202b7208664142954fa@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot hit the following crash on https://github.com/google/kmsan.git/master
>> commit
>> e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +0000)
>> kmsan: temporarily disable visitAsmInstruction() to help syzbot
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=b202b7208664142954fa
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>> Raw console output:
>> https://syzkaller.appspot.com/x/log.txt?id=5356516437655552
>> Kernel config:
>> https://syzkaller.appspot.com/x/.config?id=6627248707860932248
>> compiler: clang version 7.0.0 (trunk 329391)
>
> +Toshiaki as this seems to be related to the recent vlan tagging changes.
seems not...
"Uninit was stored to memory at:" shows uninitialized memory was stored
before where I modified the code (skb_reorder_vlan_header).
I'm not sure what this uninit memory means.
To me it looks like the memory is initialized by user provided data.
(iov in packet sock -> skb->data -> skb->protocol)
The reproducer provides 4 bytes after ethernet header, so it should be
sufficient for a vlan tag. This will set skb->len to 4 and fill the
4-byte contents in packet_snd(). skb_vlan_untag() is reading the user
provided 4-byte skb->data. It is ensured that skb_vlan_untag() does not
read beyond skb->len since it calls pskb_may_pull(). At this point I am
failing to find what I am missing.
> This also seems to be related to
> https://groups.google.com/d/msg/syzkaller-bugs/VRH9NnUi2k0/90GYsAeRBgAJ
>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+b202b7208664142954fa@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> ==================================================================
>> BUG: KMSAN: uninit-value in __read_once_size include/linux/compiler.h:197
>> [inline]
>> BUG: KMSAN: uninit-value in deliver_ptype_list_skb net/core/dev.c:1908
>> [inline]
>> BUG: KMSAN: uninit-value in __netif_receive_skb_core+0x4630/0x4a80
>> net/core/dev.c:4545
>> CPU: 0 PID: 5999 Comm: syz-executor3 Not tainted 4.16.0+ #82
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> <IRQ>
>> __dump_stack lib/dump_stack.c:17 [inline]
>> dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
>> __read_once_size include/linux/compiler.h:197 [inline]
>> deliver_ptype_list_skb net/core/dev.c:1908 [inline]
>> __netif_receive_skb_core+0x4630/0x4a80 net/core/dev.c:4545
>> __netif_receive_skb net/core/dev.c:4627 [inline]
>> process_backlog+0x62d/0xe20 net/core/dev.c:5307
>> napi_poll net/core/dev.c:5705 [inline]
>> net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
>> __do_softirq+0x56d/0x93d kernel/softirq.c:285
>> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040
>> </IRQ>
>> do_softirq kernel/softirq.c:329 [inline]
>> __local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
>> local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
>> rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
>> __dev_queue_xmit+0x2a31/0x2b60 net/core/dev.c:3584
>> dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
>> packet_snd net/packet/af_packet.c:2944 [inline]
>> packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969
>> sock_sendmsg_nosec net/socket.c:630 [inline]
>> sock_sendmsg net/socket.c:640 [inline]
>> sock_write_iter+0x3b9/0x470 net/socket.c:909
>> do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
>> do_iter_write+0x30d/0xd40 fs/read_write.c:932
>> vfs_writev fs/read_write.c:977 [inline]
>> do_writev+0x3c9/0x830 fs/read_write.c:1012
>> SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
>> SyS_writev+0x56/0x80 fs/read_write.c:1082
>> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> RIP: 0033:0x455259
>> RSP: 002b:00007fb53ede8c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
>> RAX: ffffffffffffffda RBX: 00007fb53ede96d4 RCX: 0000000000455259
>> RDX: 0000000000000001 RSI: 00000000200010c0 RDI: 0000000000000013
>> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
>> R13: 00000000000006cd R14: 00000000006fd3d8 R15: 0000000000000000
>>
>> Uninit was stored to memory at:
>> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
>> kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
>> kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
>> __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
>> skb_vlan_untag+0x950/0xee0 include/linux/if_vlan.h:597
>> __netif_receive_skb_core+0x70a/0x4a80 net/core/dev.c:4460
>> __netif_receive_skb net/core/dev.c:4627 [inline]
>> process_backlog+0x62d/0xe20 net/core/dev.c:5307
>> napi_poll net/core/dev.c:5705 [inline]
>> net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
>> __do_softirq+0x56d/0x93d kernel/softirq.c:285
>> Uninit was created at:
>> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
>> kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
>> kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
>> kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
>> slab_post_alloc_hook mm/slab.h:445 [inline]
>> slab_alloc_node mm/slub.c:2737 [inline]
>> __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
>> __kmalloc_reserve net/core/skbuff.c:138 [inline]
>> __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
>> alloc_skb include/linux/skbuff.h:984 [inline]
>> alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
>> sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
>> packet_alloc_skb net/packet/af_packet.c:2803 [inline]
>> packet_snd net/packet/af_packet.c:2894 [inline]
>> packet_sendmsg+0x6444/0x8a10 net/packet/af_packet.c:2969
>> sock_sendmsg_nosec net/socket.c:630 [inline]
>> sock_sendmsg net/socket.c:640 [inline]
>> sock_write_iter+0x3b9/0x470 net/socket.c:909
>> do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
>> do_iter_write+0x30d/0xd40 fs/read_write.c:932
>> vfs_writev fs/read_write.c:977 [inline]
>> do_writev+0x3c9/0x830 fs/read_write.c:1012
>> SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
>> SyS_writev+0x56/0x80 fs/read_write.c:1082
>> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> ==================================================================
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/94eb2c059ce01f643c0569a228ee%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
--
Toshiaki Makita
^ permalink raw reply
* Re: [RFC v2] virtio: support packed ring
From: Tiwei Bie @ 2018-04-13 7:15 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <ebfbfc3e-9e52-9331-61b6-258e131f822d@redhat.com>
On Fri, Apr 13, 2018 at 12:30:24PM +0800, Jason Wang wrote:
> On 2018年04月01日 22:12, Tiwei Bie wrote:
> > Hello everyone,
> >
> > This RFC implements packed ring support for virtio driver.
> >
> > The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented
> > by Jens at http://dpdk.org/ml/archives/dev/2018-January/089417.html
> > Minor changes are needed for the vhost code, e.g. to kick the guest.
> >
> > TODO:
> > - Refinements and bug fixes;
> > - Split into small patches;
> > - Test indirect descriptor support;
> > - Test/fix event suppression support;
> > - Test devices other than net;
> >
> > RFC v1 -> RFC v2:
> > - Add indirect descriptor support - compile test only;
> > - Add event suppression supprt - compile test only;
> > - Move vring_packed_init() out of uapi (Jason, MST);
> > - Merge two loops into one in virtqueue_add_packed() (Jason);
> > - Split vring_unmap_one() for packed ring and split ring (Jason);
> > - Avoid using '%' operator (Jason);
> > - Rename free_head -> next_avail_idx (Jason);
> > - Add comments for virtio_wmb() in virtqueue_add_packed() (Jason);
> > - Some other refinements and bug fixes;
> >
> > Thanks!
> >
> > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> > ---
> > drivers/virtio/virtio_ring.c | 1094 +++++++++++++++++++++++++++++-------
> > include/linux/virtio_ring.h | 8 +-
> > include/uapi/linux/virtio_config.h | 12 +-
> > include/uapi/linux/virtio_ring.h | 61 ++
> > 4 files changed, 980 insertions(+), 195 deletions(-)
[...]
> > +static struct vring_packed_desc *alloc_indirect_packed(struct virtqueue *_vq,
> > + unsigned int total_sg,
> > + gfp_t gfp)
> > +{
> > + struct vring_packed_desc *desc;
> > +
> > + /*
> > + * We require lowmem mappings for the descriptors because
> > + * otherwise virt_to_phys will give us bogus addresses in the
> > + * virtqueue.
> > + */
> > + gfp &= ~__GFP_HIGHMEM;
> > +
> > + desc = kmalloc(total_sg * sizeof(struct vring_packed_desc), gfp);
>
> Can we simply check vq->packed here to avoid duplicating helpers?
Then it would be something like this:
static void *alloc_indirect(struct virtqueue *_vq, unsigned int total_sg,
gfp_t gfp)
{
struct vring_virtqueue *vq = to_vvq(_vq);
void *data;
/*
* We require lowmem mappings for the descriptors because
* otherwise virt_to_phys will give us bogus addresses in the
* virtqueue.
*/
gfp &= ~__GFP_HIGHMEM;
if (vq->packed) {
data = kmalloc(total_sg * sizeof(struct vring_packed_desc),
gfp);
if (!data)
return NULL;
} else {
struct vring_desc *desc;
unsigned int i;
desc = kmalloc(total_sg * sizeof(struct vring_desc), gfp);
if (!desc)
return NULL;
for (i = 0; i < total_sg; i++)
desc[i].next = cpu_to_virtio16(_vq->vdev, i + 1);
data = desc;
}
return data;
}
I would prefer to have two simpler helpers (and to the callers,
it's already very clear about which one they should call), i.e.
the current implementation:
static struct vring_packed_desc *alloc_indirect_packed(struct virtqueue *_vq,
unsigned int total_sg,
gfp_t gfp)
{
struct vring_packed_desc *desc;
/*
* We require lowmem mappings for the descriptors because
* otherwise virt_to_phys will give us bogus addresses in the
* virtqueue.
*/
gfp &= ~__GFP_HIGHMEM;
desc = kmalloc(total_sg * sizeof(struct vring_packed_desc), gfp);
return desc;
}
static struct vring_desc *alloc_indirect_split(struct virtqueue *_vq,
unsigned int total_sg,
gfp_t gfp)
{
struct vring_desc *desc;
unsigned int i;
/*
* We require lowmem mappings for the descriptors because
* otherwise virt_to_phys will give us bogus addresses in the
* virtqueue.
*/
gfp &= ~__GFP_HIGHMEM;
desc = kmalloc(total_sg * sizeof(struct vring_desc), gfp);
if (!desc)
return NULL;
for (i = 0; i < total_sg; i++)
desc[i].next = cpu_to_virtio16(_vq->vdev, i + 1);
return desc;
}
>
> > +
> > + return desc;
> > +}
[...]
> > +static inline int virtqueue_add_packed(struct virtqueue *_vq,
> > + struct scatterlist *sgs[],
> > + unsigned int total_sg,
> > + unsigned int out_sgs,
> > + unsigned int in_sgs,
> > + void *data,
> > + void *ctx,
> > + gfp_t gfp)
> > +{
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > + struct vring_packed_desc *desc;
> > + struct scatterlist *sg;
> > + unsigned int i, n, descs_used, uninitialized_var(prev), err_idx;
> > + __virtio16 uninitialized_var(head_flags), flags;
> > + int head, wrap_counter;
> > + bool indirect;
> > +
> > + START_USE(vq);
> > +
> > + BUG_ON(data == NULL);
> > + BUG_ON(ctx && vq->indirect);
> > +
> > + if (unlikely(vq->broken)) {
> > + END_USE(vq);
> > + return -EIO;
> > + }
> > +
> > +#ifdef DEBUG
> > + {
> > + ktime_t now = ktime_get();
> > +
> > + /* No kick or get, with .1 second between? Warn. */
> > + if (vq->last_add_time_valid)
> > + WARN_ON(ktime_to_ms(ktime_sub(now, vq->last_add_time))
> > + > 100);
> > + vq->last_add_time = now;
> > + vq->last_add_time_valid = true;
> > + }
> > +#endif
> > +
> > + BUG_ON(total_sg == 0);
> > +
> > + head = vq->next_avail_idx;
> > + wrap_counter = vq->wrap_counter;
> > +
> > + /* If the host supports indirect descriptor tables, and we have multiple
> > + * buffers, then go indirect. FIXME: tune this threshold */
> > + if (vq->indirect && total_sg > 1 && vq->vq.num_free)
>
> Let's introduce a helper like virtqueue_need_indirect() to avoid duplicating
> codes and FIXME.
Okay.
>
> > + desc = alloc_indirect_packed(_vq, total_sg, gfp);
> > + else {
> > + desc = NULL;
> > + WARN_ON_ONCE(total_sg > vq->vring_packed.num && !vq->indirect);
> > + }
> > +
> > + if (desc) {
> > + /* Use a single buffer which doesn't continue */
> > + indirect = true;
> > + /* Set up rest to use this indirect table. */
> > + i = 0;
> > + descs_used = 1;
> > + } else {
> > + indirect = false;
> > + desc = vq->vring_packed.desc;
> > + i = head;
> > + descs_used = total_sg;
> > + }
> > +
> > + if (vq->vq.num_free < descs_used) {
> > + pr_debug("Can't add buf len %i - avail = %i\n",
> > + descs_used, vq->vq.num_free);
> > + /* FIXME: for historical reasons, we force a notify here if
> > + * there are outgoing parts to the buffer. Presumably the
> > + * host should service the ring ASAP. */
> > + if (out_sgs)
> > + vq->notify(&vq->vq);
> > + if (indirect)
> > + kfree(desc);
> > + END_USE(vq);
> > + return -ENOSPC;
> > + }
> > +
> > + for (n = 0; n < out_sgs + in_sgs; n++) {
> > + for (sg = sgs[n]; sg; sg = sg_next(sg)) {
> > + dma_addr_t addr = vring_map_one_sg(vq, sg, n < out_sgs ?
> > + DMA_TO_DEVICE : DMA_FROM_DEVICE);
> > + if (vring_mapping_error(vq, addr))
> > + goto unmap_release;
> > +
> > + flags = cpu_to_virtio16(_vq->vdev, VRING_DESC_F_NEXT |
> > + (n < out_sgs ? 0 : VRING_DESC_F_WRITE) |
> > + VRING_DESC_F_AVAIL(vq->wrap_counter) |
> > + VRING_DESC_F_USED(!vq->wrap_counter));
> > + if (!indirect && i == head)
> > + head_flags = flags;
> > + else
> > + desc[i].flags = flags;
> > +
> > + desc[i].addr = cpu_to_virtio64(_vq->vdev, addr);
> > + desc[i].len = cpu_to_virtio32(_vq->vdev, sg->length);
> > + desc[i].id = cpu_to_virtio32(_vq->vdev, head);
>
> Similar to V1, we only need this for the last descriptor.
Okay, will just set it for the last desc.
>
> > + prev = i;
>
> It looks to me there's no need to track prev inside the loop here.
>
> > + i++;
> > + if (!indirect && i >= vq->vring_packed.num) {
> > + i = 0;
> > + vq->wrap_counter ^= 1;
> > + }
> > + }
> > + }
> > + /* Last one doesn't continue. */
> > + if (total_sg == 1)
> > + head_flags &= cpu_to_virtio16(_vq->vdev, ~VRING_DESC_F_NEXT);
> > + else
> > + desc[prev].flags &= cpu_to_virtio16(_vq->vdev, ~VRING_DESC_F_NEXT);
>
> The only case when prev != i - 1 is i == 0, we can add a if here.
It's just a mirror of the existing implementation in split ring.
It seems that split ring implementation needs this just because
it's much harder for it to find the prev, which is not true for
packed ring. So I'll take your suggestion. Thanks!
>
[...]
> > +static bool virtqueue_kick_prepare_packed(struct virtqueue *_vq)
> > +{
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > + u16 new, old, off_wrap;
> > + bool needs_kick;
> > +
> > + START_USE(vq);
> > + /* We need to expose the new flags value before checking notification
> > + * suppressions. */
> > + virtio_mb(vq->weak_barriers);
> > +
> > + old = vq->next_avail_idx - vq->num_added;
> > + new = vq->next_avail_idx;
> > + vq->num_added = 0;
> > +
> > +#ifdef DEBUG
> > + if (vq->last_add_time_valid) {
> > + WARN_ON(ktime_to_ms(ktime_sub(ktime_get(),
> > + vq->last_add_time)) > 100);
> > + }
> > + vq->last_add_time_valid = false;
> > +#endif
> > +
> > + off_wrap = virtio16_to_cpu(_vq->vdev, vq->vring_packed.device->off_wrap);
> > +
> > + if (vq->event) {
>
> It looks to me we should examine RING_EVENT_FLAGS_DESC in desc_event_flags
> instead of vq->event here. Spec does not forces to use evenf_off and
> event_wrap if event index is enabled.
>
> > + // FIXME: fix this!
> > + needs_kick = ((off_wrap >> 15) == vq->wrap_counter) &&
> > + vring_need_event(off_wrap & ~(1<<15), new, old);
>
> Why need a & here?
Because wrap_counter (the most significant bit in off_wrap)
isn't part of the index.
>
> > + } else {
>
> Need a smp_rmb() to make sure desc_event_flags was checked before flags.
I don't get your point, if my understanding is correct,
desc_event_flags is vq->vring_packed.device->flags. So
what's the "flags"?
>
> > + needs_kick = (vq->vring_packed.device->flags !=
> > + cpu_to_virtio16(_vq->vdev, VRING_EVENT_F_DISABLE));
> > + }
> > + END_USE(vq);
> > + return needs_kick;
> > +}
[...]
> > +static int detach_buf_packed(struct vring_virtqueue *vq, unsigned int head,
> > + void **ctx)
> > +{
> > + struct vring_packed_desc *desc;
> > + unsigned int i, j;
> > +
> > + /* Clear data ptr. */
> > + vq->desc_state[head].data = NULL;
> > +
> > + i = head;
> > +
> > + for (j = 0; j < vq->desc_state[head].num; j++) {
> > + desc = &vq->vring_packed.desc[i];
> > + vring_unmap_one_packed(vq, desc);
> > + desc->flags = 0x0;
>
> Looks like this is unnecessary.
It's safer to zero it. If we don't zero it, after we
call virtqueue_detach_unused_buf_packed() which calls
this function, the desc is still available to the
device.
>
> > + i++;
> > + if (i >= vq->vring_packed.num)
> > + i = 0;
> > + }
[...]
> > +static unsigned virtqueue_enable_cb_prepare_packed(struct virtqueue *_vq)
> > +{
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > + u16 last_used_idx, wrap_counter, off_wrap;
> > +
> > + START_USE(vq);
> > +
> > + last_used_idx = vq->last_used_idx;
> > + wrap_counter = vq->wrap_counter;
> > +
> > + if (last_used_idx > vq->next_avail_idx)
> > + wrap_counter ^= 1;
> > +
> > + off_wrap = last_used_idx | (wrap_counter << 15);
> > +
> > + /* We optimistically turn back on interrupts, then check if there was
> > + * more to do. */
> > + /* Depending on the VIRTIO_RING_F_EVENT_IDX feature, we need to
> > + * either clear the flags bit or point the event index at the next
> > + * entry. Always do both to keep code simple. */
> > + if (vq->event_flags_shadow == VRING_EVENT_F_DISABLE) {
> > + vq->event_flags_shadow = vq->event ? VRING_EVENT_F_DESC:
> > + VRING_EVENT_F_ENABLE;
> > + vq->vring_packed.driver->flags = cpu_to_virtio16(_vq->vdev,
> > + vq->event_flags_shadow);
> > + }
>
> A smp_wmb() is missed here?
>
> > + vq->vring_packed.driver->off_wrap = cpu_to_virtio16(_vq->vdev, off_wrap);
>
> And according to the spec, it looks to me write a VRING_EVENT_F_ENABLE is
> sufficient here.
I didn't think much when implementing the event suppression
for packed ring previously. After I saw your comments, I found
something new. Indeed, unlike the split ring, for the packed
ring, spec doesn't say we must use VRING_EVENT_F_DESC when
EVENT_IDX is negotiated. So do you think below thought is
right or makes sense?
- For virtqueue_enable_cb_prepare(), we just need to enable
the ring by setting flags to VRING_EVENT_F_ENABLE in any
case.
- We will try to use VRING_EVENT_F_DESC (if EVENT_IDX is
negotiated) only when we want to delay the interrupts
virtqueue_enable_cb_delayed().
>
> > + END_USE(vq);
> > + return last_used_idx;
> > +}
> > +
[...]
> > @@ -1157,14 +1852,18 @@ void vring_transport_features(struct virtio_device *vdev)
> > for (i = VIRTIO_TRANSPORT_F_START; i < VIRTIO_TRANSPORT_F_END; i++) {
> > switch (i) {
> > - case VIRTIO_RING_F_INDIRECT_DESC:
> > +#if 0
> > + case VIRTIO_RING_F_INDIRECT_DESC: // FIXME not tested yet.
> > break;
> > - case VIRTIO_RING_F_EVENT_IDX:
> > + case VIRTIO_RING_F_EVENT_IDX: // FIXME probably not work.
> > break;
> > +#endif
>
> It would be better if you can split EVENT_IDX and INDIRECT_DESC into
> separate patches too.
Sure. Will do it in the next version.
Thanks for the review!
>
> Thanks
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH] net: stmmac: fix missing support for 802.1AD tag on reception
From: Elad Nachman @ 2018-04-13 7:03 UTC (permalink / raw)
To: netdev, davem
stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before
calling napi_gro_receive().
The function assumes VLAN tagged frames are always tagged with 802.1Q
protocol,
and assigns ETH_P_8021Q to the skb by hard-coding the parameter on call
to __vlan_hwaccel_put_tag() .
This causes packets not to be passed to the VLAN slave if it was created
with 802.1AD protocol
(ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100).
This fix passes the protocol from the VLAN header into
__vlan_hwaccel_put_tag()
instead of using the hard-coded value of ETH_P_8021Q.
Signed-off-by: Elad Nachman <eladn@gilat.com>
---
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 2018-04-11
17:04:00.586057300 +0300
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 2018-04-11
17:05:33.601992400 +0300
@@ -3293,17 +3293,19 @@ dma_map_err:
static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
{
- struct ethhdr *ehdr;
+ struct vlan_ethhdr *veth;
u16 vlanid;
+ __be16 vlan_proto;
if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
NETIF_F_HW_VLAN_CTAG_RX &&
!__vlan_get_tag(skb, &vlanid)) {
/* pop the vlan tag */
- ehdr = (struct ethhdr *)skb->data;
- memmove(skb->data + VLAN_HLEN, ehdr, ETH_ALEN * 2);
+ veth = (struct vlan_ethhdr *)skb->data;
+ vlan_proto = veth->h_vlan_proto;
+ memmove(skb->data + VLAN_HLEN, veth, ETH_ALEN * 2);
skb_pull(skb, VLAN_HLEN);
- __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
+ __vlan_hwaccel_put_tag(skb, vlan_proto, vlanid);
}
}
^ permalink raw reply
* [PATCH net] virtio-net: add missing virtqueue kick when flushing packets
From: Jason Wang @ 2018-04-13 6:58 UTC (permalink / raw)
To: mst, jasowang, virtualization, netdev, linux-kernel
Cc: ktaka, Daniel Borkmann
We tends to batch submitting packets during XDP_TX. This requires to
kick virtqueue after a batch, we tried to do it through
xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So
explicitly kick the virtqueue in this case.
Reported-by: Kimitoshi Takahashi <ktaka@nii.ac.jp>
Tested-by: Kimitoshi Takahashi <ktaka@nii.ac.jp>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Fixes: 186b3c998c50 ("virtio-net: support XDP_REDIRECT")
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 2337460..d8e1aea 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1269,7 +1269,9 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
{
struct receive_queue *rq =
container_of(napi, struct receive_queue, napi);
- unsigned int received;
+ struct virtnet_info *vi = rq->vq->vdev->priv;
+ struct send_queue *sq;
+ unsigned int received, qp;
bool xdp_xmit = false;
virtnet_poll_cleantx(rq);
@@ -1280,8 +1282,13 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
if (received < budget)
virtqueue_napi_complete(napi, rq->vq, received);
- if (xdp_xmit)
+ if (xdp_xmit) {
+ qp = vi->curr_queue_pairs - vi->xdp_queue_pairs +
+ smp_processor_id();
+ sq = &vi->sq[qp];
+ virtqueue_kick(sq->vq);
xdp_do_flush_map();
+ }
return received;
}
--
2.7.4
^ permalink raw reply related
* [PATCH] net: stmmac: fix missing support for 802.1AD tag on reception
From: Elad Nachman @ 2018-04-13 6:45 UTC (permalink / raw)
To: netdev, davem
stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before
calling napi_gro_receive().
The function assumes VLAN tagged frames are always tagged with 802.1Q
protocol,
and assigns ETH_P_8021Q to the skb by hard-coding the parameter on call
to __vlan_hwaccel_put_tag() .
This causes packets not to be passed to the VLAN slave if it was created
with 802.1AD protocol
(ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100).
This fix passes the protocol from the VLAN header into
__vlan_hwaccel_put_tag()
instead of using the hard-coded value of ETH_P_8021Q.
Signed-off-by: Elad Nachman <eladn@gilat.com>
---
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 2018-04-11
17:04:00.586057300 +0300
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 2018-04-11
17:05:33.601992400 +0300
@@ -3293,17 +3293,19 @@ dma_map_err:
static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
{
- struct ethhdr *ehdr;
+ struct vlan_ethhdr *veth;
u16 vlanid;
+ __be16 vlan_proto;
if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
NETIF_F_HW_VLAN_CTAG_RX &&
!__vlan_get_tag(skb, &vlanid)) {
/* pop the vlan tag */
- ehdr = (struct ethhdr *)skb->data;
- memmove(skb->data + VLAN_HLEN, ehdr, ETH_ALEN * 2);
+ veth = (struct vlan_ethhdr *)skb->data;
+ vlan_proto = veth->h_vlan_proto;
+ memmove(skb->data + VLAN_HLEN, veth, ETH_ALEN * 2);
skb_pull(skb, VLAN_HLEN);
- __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
+ __vlan_hwaccel_put_tag(skb, vlan_proto, vlanid);
}
}
^ permalink raw reply
* Re: INFO: task hung in do_ip_vs_set_ctl (2)
From: syzbot @ 2018-04-13 6:23 UTC (permalink / raw)
To: coreteam, davem, fw, horms, ja, kadlec, linux-kernel, lvs-devel,
netdev, netfilter-devel, pablo, syzkaller-bugs, wensong
In-Reply-To: <94eb2c059ce0bca273056940d77d@google.com>
syzbot has found reproducer for the following crash on net-next commit
17dec0a949153d9ac00760ba2f5b78cb583e995f (Wed Apr 4 02:15:32 2018 +0000)
Merge branch 'userns-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=7810ed2e0cb359580c17
So far this crash happened 2 times on net-next, upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5922062967242752
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5359824032235520
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6352399027404800
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-2735707888269579554
compiler: gcc (GCC) 8.0.1 20180301 (experimental)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7810ed2e0cb359580c17@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.
INFO: task syzkaller402106:4498 blocked for more than 120 seconds.
Not tainted 4.16.0+ #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syzkaller402106 D22184 4498 4494 0x00000000
Call Trace:
context_switch kernel/sched/core.c:2848 [inline]
__schedule+0x807/0x1e40 kernel/sched/core.c:3490
schedule+0xef/0x430 kernel/sched/core.c:3549
schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3607
__mutex_lock_common kernel/locking/mutex.c:833 [inline]
__mutex_lock+0xe38/0x17f0 kernel/locking/mutex.c:893
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x7d/0xd0 net/netfilter/nf_sockopt.c:115
ip_setsockopt+0xd8/0xf0 net/ipv4/ip_sockglue.c:1253
tcp_setsockopt+0x93/0xe0 net/ipv4/tcp.c:2888
sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3039
smc_setsockopt+0xc7/0x120 net/smc/af_smc.c:1289
__sys_setsockopt+0x1bd/0x390 net/socket.c:1903
SYSC_setsockopt net/socket.c:1914 [inline]
SyS_setsockopt+0x34/0x50 net/socket.c:1911
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x445959
RSP: 002b:00007f2770618db8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 0000000000445959
RDX: 000000000000048c RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00000000006dac20 R08: 0000000000000018 R09: 0000000000000000
R10: 0000000020000140 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffd81ae8f6f R14: 00007f27706199c0 R15: 0000000000000001
Showing all locks held in the system:
3 locks held by kworker/0:0/4:
#0: 000000007346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
__write_once_size include/linux/compiler.h:215 [inline]
#0: 000000007346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 000000007346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic64_set include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 000000007346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic_long_set include/asm-generic/atomic-long.h:57 [inline]
#0: 000000007346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_data kernel/workqueue.c:617 [inline]
#0: 000000007346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 000000007346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
process_one_work+0xaef/0x1b50 kernel/workqueue.c:2116
#1: 00000000894403a3 ((addr_chk_work).work){+.+.}, at:
process_one_work+0xb46/0x1b50 kernel/workqueue.c:2120
#2: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
2 locks held by khungtaskd/877:
#0: 00000000706bfe1c (rcu_read_lock){....}, at:
check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
#0: 00000000706bfe1c (rcu_read_lock){....}, at: watchdog+0x1ff/0xf60
kernel/hung_task.c:249
#1: 00000000761e40d2 (tasklist_lock){.+.+}, at:
debug_show_all_locks+0xde/0x34a kernel/locking/lockdep.c:4470
2 locks held by getty/4464:
#0: 00000000f90a9320 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 000000005dd151b8 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4465:
#0: 00000000737b5b26 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 0000000017bb1ae5 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4466:
#0: 00000000badd071e (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 00000000a46de9fa (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4467:
#0: 00000000112731eb (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 00000000166cdec3 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4468:
#0: 00000000d9915e26 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 00000000abf02ab1 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4469:
#0: 0000000041b9a2d2 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 000000003dbb7393 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4470:
#0: 00000000dd811911 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 00000000c9586a34 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
1 lock held by syzkaller402106/4498:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4517:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4523:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4535:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4537:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4548:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4553:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4564:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4571:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4581:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4588:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4598:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4603:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4615:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4620:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4631:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4511:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4514:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4526:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4530:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4542:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4546:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4558:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4562:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4574:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4578:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4590:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4594:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4606:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4610:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4622:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4626:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4501:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4518:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4522:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4533:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4539:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4550:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4556:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4567:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4572:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4582:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4586:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4597:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4602:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4612:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4617:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4628:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4506:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4515:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4527:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4531:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4543:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4547:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4559:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4563:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4575:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4579:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4591:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4595:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4607:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4611:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4623:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4627:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4503:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4519:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4524:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4534:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4538:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4549:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4554:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4566:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4569:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4580:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4585:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4596:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4601:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4613:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4619:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4630:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
2 locks held by syzkaller402106/4508:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
#1: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x562/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2388
1 lock held by syzkaller402106/4513:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4525:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4529:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4541:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4545:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4557:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4561:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4573:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4577:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4589:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4593:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4605:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4609:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4621:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4625:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4507:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4516:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4521:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4532:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4540:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4551:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4555:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4565:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4570:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4583:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4587:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4599:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4604:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4614:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4618:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4629:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4509:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4512:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4520:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4528:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4536:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4544:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4552:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4560:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4568:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4576:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4584:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4592:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4600:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4608:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by syzkaller402106/4616:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syzkaller402106/4624:
#0: 00000000bfa7d99e (ipvs->sync_mutex){+.+.}, at:
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
1 lock held by ipvs-b:0:0/4510:
#0: 00000000ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
=============================================
NMI backtrace for cpu 1
CPU: 1 PID: 877 Comm: khungtaskd Not tainted 4.16.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x1b9/0x29f lib/dump_stack.c:53
nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace include/linux/nmi.h:138 [inline]
check_hung_task kernel/hung_task.c:132 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:190 [inline]
watchdog+0xc10/0xf60 kernel/hung_task.c:249
kthread+0x345/0x410 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:411
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.16.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:timekeeping_delta_to_ns kernel/time/timekeeping.c:351 [inline]
RIP: 0010:timekeeping_get_ns kernel/time/timekeeping.c:362 [inline]
RIP: 0010:ktime_get+0x308/0x430 kernel/time/timekeeping.c:764
RSP: 0018:ffff8801db007b98 EFLAGS: 00000002
RAX: 000000002930e468 RBX: 0000023e54000000 RCX: 0000000000000017
RDX: ffffed003b600f79 RSI: ffffffff8166cd99 RDI: 0000000000000004
RBP: ffff8801db007c90 R08: ffffffff88a752c0 R09: 0000000000000000
R10: ffffed0043fff001 R11: ffff88021fff8017 R12: dffffc0000000000
R13: 000000000006509e R14: ffff8801db007c68 R15: ffffffff88b172a0
FS: 0000000000000000(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000090e000 CR3: 00000001b130f000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
tick_nohz_irq_enter kernel/time/tick-sched.c:1124 [inline]
tick_irq_enter+0xbc/0x3f0 kernel/time/tick-sched.c:1145
irq_enter+0xb6/0xd0 kernel/softirq.c:346
scheduler_ipi+0x39b/0xa30 kernel/sched/core.c:1768
smp_reschedule_interrupt+0xed/0x660 arch/x86/kernel/smp.c:277
reschedule_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:886
</IRQ>
RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
RSP: 0018:ffffffff88a07c38 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff02
RAX: dffffc0000000000 RBX: 1ffffffff1140f8a RCX: 0000000000000000
RDX: 1ffffffff1162e58 RSI: 0000000000000001 RDI: ffffffff88b172c0
RBP: ffffffff88a07c38 R08: ffffffff88a752c0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffffffff88a07cf0 R14: ffffffff88b172b0 R15: 0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0xc2/0x440 arch/x86/kernel/process.c:354
arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:345
default_idle_call+0x6d/0x90 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:151 [inline]
do_idle+0x2f4/0x3c0 kernel/sched/idle.c:241
cpu_startup_entry+0x104/0x120 kernel/sched/idle.c:346
rest_init+0xe1/0xe4 init/main.c:437
start_kernel+0x887/0x8ae init/main.c:717
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:443
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:424
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
Code: ff ff 0f b6 8d 18 ff ff ff 48 ba 00 00 00 00 00 fc ff df 48 03 95 08
ff ff ff 48 0f af d8 48 8b 85 10 ff ff ff 48 01 d8 48 d3 e8 <48> 03 85 20
ff ff ff 48 c7 02 00 00 00 00 48 c7 42 08 00 00 00
^ permalink raw reply
* [RFC PATCH] net: stmmac: dwmac-sun8i: single_reg_field can be static
From: kbuild test robot @ 2018-04-13 6:03 UTC (permalink / raw)
To: Icenowy Zheng
Cc: kbuild-all-JC7UmRfGjtg, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Giuseppe Cavallaro, Corentin Labbe, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20180411141641.14675-4-icenowy-h8G6r0blFSE@public.gmane.org>
Fixes: 529123418105 ("net: stmmac: dwmac-sun8i: Allow getting syscon regmap from device")
Signed-off-by: Fengguang Wu <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
dwmac-sun8i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index b61210c..842315a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -86,7 +86,7 @@ const struct reg_field old_syscon_reg_field = {
};
/* Specially exported regmap which contains only EMAC register */
-const struct reg_field single_reg_field = {
+static const struct reg_field single_reg_field = {
.reg = 0,
.lsb = 0,
.msb = 31,
^ permalink raw reply related
* Re: [PATCH 3/5] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from device
From: kbuild test robot @ 2018-04-13 6:03 UTC (permalink / raw)
To: Icenowy Zheng
Cc: kbuild-all-JC7UmRfGjtg, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Giuseppe Cavallaro, Corentin Labbe, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20180411141641.14675-4-icenowy-h8G6r0blFSE@public.gmane.org>
Hi Chen-Yu,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.16 next-20180412]
[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/Icenowy-Zheng/Add-support-in-dwmac-sun8i-for-accessing-EMAC-clock/20180413-004816
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:82:24: sparse: symbol 'old_syscon_reg_field' was not declared. Should it be static?
>> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:89:24: sparse: symbol 'single_reg_field' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: KMSAN: uninit-value in __netif_receive_skb_core
From: syzbot @ 2018-04-13 5:10 UTC (permalink / raw)
To: bpoirier, davem, dvyukov, edumazet, elena.reshetova, ishkamiel,
keescook, linux-kernel, makita.toshiaki, maloney, netdev,
rami.rosen, syzkaller-bugs, willemb
In-Reply-To: <94eb2c059ce01f643c0569a228ee@google.com>
syzbot has found reproducer for the following crash on
https://github.com/google/kmsan.git/master commit
35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +0000)
Merge pull request #11 from parkerduckworth/readme
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=b202b7208664142954fa
So far this crash happened 3 times on
https://github.com/google/kmsan.git/master.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4559916236800000
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=4590273065648128
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=4631921027973120
Kernel config:
https://syzkaller.appspot.com/x/.config?id=6627248707860932248
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b202b7208664142954fa@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.
==================================================================
BUG: KMSAN: uninit-value in __read_once_size include/linux/compiler.h:197
[inline]
BUG: KMSAN: uninit-value in deliver_ptype_list_skb net/core/dev.c:1908
[inline]
BUG: KMSAN: uninit-value in __netif_receive_skb_core+0x4630/0x4a80
net/core/dev.c:4545
CPU: 0 PID: 3514 Comm: syzkaller031167 Not tainted 4.16.0+ #83
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
__read_once_size include/linux/compiler.h:197 [inline]
deliver_ptype_list_skb net/core/dev.c:1908 [inline]
__netif_receive_skb_core+0x4630/0x4a80 net/core/dev.c:4545
__netif_receive_skb net/core/dev.c:4627 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5307
napi_poll net/core/dev.c:5705 [inline]
net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
__do_softirq+0x56d/0x93d kernel/softirq.c:285
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040
</IRQ>
do_softirq kernel/softirq.c:329 [inline]
__local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
__dev_queue_xmit+0x2a31/0x2b60 net/core/dev.c:3584
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
packet_snd net/packet/af_packet.c:2944 [inline]
packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
sock_write_iter+0x3b9/0x470 net/socket.c:909
do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
do_iter_write+0x30d/0xd40 fs/read_write.c:932
vfs_writev fs/read_write.c:977 [inline]
do_writev+0x3c9/0x830 fs/read_write.c:1012
SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
SyS_writev+0x56/0x80 fs/read_write.c:1082
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43ffb9
RSP: 002b:00007ffd42187708 EFLAGS: 00000217 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043ffb9
RDX: 0000000000000001 RSI: 00000000200010c0 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000217 R12: 00000000004018e0
R13: 0000000000401970 R14: 0000000000000000 R15: 0000000000000000
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
__msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
skb_vlan_untag+0x950/0xee0 include/linux/if_vlan.h:597
__netif_receive_skb_core+0x70a/0x4a80 net/core/dev.c:4460
__netif_receive_skb net/core/dev.c:4627 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5307
napi_poll net/core/dev.c:5705 [inline]
net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
__do_softirq+0x56d/0x93d kernel/softirq.c:285
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
slab_post_alloc_hook mm/slab.h:445 [inline]
slab_alloc_node mm/slub.c:2737 [inline]
__kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:984 [inline]
alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
packet_alloc_skb net/packet/af_packet.c:2803 [inline]
packet_snd net/packet/af_packet.c:2894 [inline]
packet_sendmsg+0x6444/0x8a10 net/packet/af_packet.c:2969
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
sock_write_iter+0x3b9/0x470 net/socket.c:909
do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
do_iter_write+0x30d/0xd40 fs/read_write.c:932
vfs_writev fs/read_write.c:977 [inline]
do_writev+0x3c9/0x830 fs/read_write.c:1012
SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
SyS_writev+0x56/0x80 fs/read_write.c:1082
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
==================================================================
^ permalink raw reply
* Re: iproute2-4.16.0 no longer accepts routes via fe80::1
From: David Ahern @ 2018-04-13 4:39 UTC (permalink / raw)
To: Thomas Deutschmann, netdev; +Cc: serhe.popovych
In-Reply-To: <9d8beae3-ff87-6e89-c4ac-941e3c890d71@gentoo.org>
On 4/12/18 6:41 AM, Thomas Deutschmann wrote:
> Hi,
>
> well, it isn't just "fe80::1", it is any IPv6 address which
> will be rejected if not called with "-6". I run bisect:
>
>> git bisect start
>> # good: [50b8a842e8c098cddb213f5b3076526df88826e8] v4.15.0
>> git bisect good 50b8a842e8c098cddb213f5b3076526df88826e8
>> # bad: [4b6c4177ee66421770f0bbcc765c29135e44d921] v4.16.0
>> git bisect bad 4b6c4177ee66421770f0bbcc765c29135e44d921
>> # bad: [5f4892e2c8d4fb22118713e0c83290b352fe0e34] rdma: Make visible the number of arguments
>> git bisect bad 5f4892e2c8d4fb22118713e0c83290b352fe0e34
>> # good: [8c75f69411bc8c3affe5d173afcf981d15f5da15] Merge branch 'master' into net-next
>> git bisect good 8c75f69411bc8c3affe5d173afcf981d15f5da15
>> # bad: [27c523e209ab956ff269afec68c6e744e7f5edb6] utils: Introduce get_addr_rta() and inet_addr_match_rta()
>> git bisect bad 27c523e209ab956ff269afec68c6e744e7f5edb6
>> # bad: [d0bcedd549566a87354aa804df3be6be80681ee9] tc: introduce tc_qdisc_block_exists helper
>> git bisect bad d0bcedd549566a87354aa804df3be6be80681ee9
>> # bad: [6c4b672738acf680ee98c10e79a52a8dede5f9a6] iplink_geneve: Get rid of inet_get_addr()
>> git bisect bad 6c4b672738acf680ee98c10e79a52a8dede5f9a6
>> # bad: [93fa12418dc6f5943692250244be303bb162175b] utils: Always specify family and ->bytelen in get_prefix_1()
>> git bisect bad 93fa12418dc6f5943692250244be303bb162175b
>> # good: [f2522007d8fee924cb098b4afc8af16f2b25829f] utils: Always specify family for address in get_addr_1()
>> git bisect good f2522007d8fee924cb098b4afc8af16f2b25829f
>> # first bad commit: [93fa12418dc6f5943692250244be303bb162175b] utils: Always specify family and ->bytelen in get_prefix_1()
>
>> From 93fa12418dc6f5943692250244be303bb162175b Mon Sep 17 00:00:00 2001
>> From: Serhey Popovych
>> Date: Thu, 18 Jan 2018 20:13:43 +0200
>> Subject: utils: Always specify family and ->bytelen in get_prefix_1()
>>
>> Handle default/all/any special case in get_addr_1() to setup
>> ->family and ->bytelen correctly.
>>
>> Make get_addr_1() return ->bitlen == -2 instead of -1 to
>> distinguish default/all/any special case from the rest:
>> it is safe because all callers check ->bitlen < 0, not
>> explicit value -1.
>>
>> Reduce intendation by one level and get rid of goto/label
>> to make code more readable.
>>
>> Signed-off-by: Serhey Popovych
>> Signed-off-by: David Ahern
>
> https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=93fa12418dc6f5943692250244be303bb162175b
>
> So was this an intended behavior change? I.e. this will require
> updates for various user space tools/network configuration scripts
> which are relying on ip utilities feature to auto-detect inet family
> which was "supported" (at least working) until 4.16.0...
>
>
Not intentional. Serhey please take a look
^ permalink raw reply
* Re: [PATCH v5 05/14] PCI: Add pcie_print_link_status() to log link speed and whether it's limited
From: Jakub Kicinski @ 2018-04-13 4:32 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tal Gilboa, Tariq Toukan, Jacob Keller, Ariel Elior,
Ganesh Goudar, Jeff Kirsher, everest-linux-l2, intel-wired-lan,
netdev, linux-kernel, linux-pci
In-Reply-To: <152244391852.135666.14903825998610307052.stgit@bhelgaas-glaptop.roam.corp.google.com>
On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote:
> + if (bw_avail >= bw_cap)
> + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n",
> + bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);
> + else
> + pci_info(dev, "%d Mb/s available bandwidth, limited by %s x%d link at %s (capable of %d Mb/s with %s x%d link)\n",
> + bw_avail, PCIE_SPEED2STR(speed), width,
> + limiting_dev ? pci_name(limiting_dev) : "<unknown>",
> + bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);
I was just looking at using this new function to print PCIe BW for a
NIC, but I'm slightly worried that there is nothing in the message that
says PCIe... For a NIC some people may interpret the bandwidth as NIC
bandwidth:
[ 39.839989] nfp 0000:04:00.0: Netronome Flow Processor NFP4000/NFP6000 PCIe Card Probe
[ 39.848943] nfp 0000:04:00.0: 63.008 Gb/s available bandwidth (8 GT/s x8 link)
[ 39.857146] nfp 0000:04:00.0: RESERVED BARs: 0.0: General/MSI-X SRAM, 0.1: PCIe XPB/MSI-X PBA, 0.4: Explicit0, 0.5: Explicit1, fre4
It's not a 63Gbps NIC... I'm sorry if this was discussed before and I
didn't find it. Would it make sense to add the "PCIe: " prefix to the
message like bnx2x used to do? Like:
nfp 0000:04:00.0: PCIe: 63.008 Gb/s available bandwidth (8 GT/s x8 link)
Sorry for a very late comment.
^ 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