* Re: [PATCH net] bpf, doc: update bpf maintainers entry
From: David Miller @ 2017-04-21 19:25 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <509f15e49a4546260785ab72cab8dcc153251e66.1492701796.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu, 20 Apr 2017 17:27:58 +0200
> Add various related files that have been missing under
> BPF entry covering essential parts of its infrastructure
> and also add myself as co-maintainer.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied, thanks Daniel.
^ permalink raw reply
* Re: [PATCH RFC] sparc64: eBPF JIT
From: Alexei Starovoitov @ 2017-04-21 19:26 UTC (permalink / raw)
To: David Miller; +Cc: daniel, sparclinux, netdev, ast
In-Reply-To: <20170421.150226.825217448288272000.davem@davemloft.net>
On Fri, Apr 21, 2017 at 03:02:26PM -0400, David Miller wrote:
> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Date: Fri, 21 Apr 2017 11:49:37 -0700
>
> > On Fri, Apr 21, 2017 at 12:46:40PM -0400, David Miller wrote:
> >> From: Daniel Borkmann <daniel@iogearbox.net>
> >> Date: Mon, 17 Apr 2017 20:44:35 +0200
> >>
> >> > There is samples/bpf/sockex3_kern.c, which exercises it. To
> >> > run it, it would be (clang/llvm needed due to BPF backend not
> >> > available in gcc):
> >> >
> >> > # cd samples/bpf
> >> > # make
> >> > # ./sockex3
> >> > IP src.port -> dst.port bytes packets
> >> > 127.0.0.1.12865 -> 127.0.0.1.49711 148 2
> >> > 127.0.0.1.49711 -> 127.0.0.1.12865 108 2
> >> > [...]
> >> >
> >> > Inside parse_eth_proto(), it will do tail calls based on the
> >> > eth protocol. Over time, we'll move such C based tests over to
> >> > tools/testing/selftests/bpf/.
> >>
> >> Ok, after a lot of work setting up an LLVM/CLANG environment and other
> >> things,
> >
> > was it painful because of sparc environment?
>
> Yes, primarily this was the reason.
>
> It wasn't just a matter of building llvm/clang, I had to install a
> whole new version of gcc because of llvm/clang build requirements.
>
> Also, it isn't clear what is supposed to happen when the system
> include files are older than the one in the kernel tree. I thought it
> should just work and the selftests and samples would pick up the ones
> in the tree properly.
interesting...
It should pick up local headers without touching /usr/include.
In the past I used to do 'make headers_install' before doing a build
in samples/bpf or selftests, but then suddenly it started working
without that step, so I figured something got fixed in the build system.
May be it's arch specific somehow.
> > redhat folks have been back and forth on adding bpf support to gcc.
> > The backend itself was fully functional before it was abandoned.
> > Last time we discussed it the lack of integrated asm in gcc was the main blocker.
> > Can we bend gcc rules and let bpf backend emit custom binary and/or elf?
>
> I don't see why you can't just do a proper GNU as/ld port.
>
> Frankly I would love to write foo.s BFD assembler files just like for
> any other target and them feed them to binutils.
>
> And then once you have BFD support for BPF ELF you get lots of tooling
> and you can start going for gdb support.
of course I agree :) That would be ideal. Just so far no one hacked BFD.
^ permalink raw reply
* Re: net: cleanup_net is slow
From: Florian Westphal @ 2017-04-21 19:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrey Konovalov, Cong Wang, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, syzkaller
In-Reply-To: <CANn89i+iYtPLGDZpt3qk_cA-dq+004B=1qjP0ZygY3oREskQYA@mail.gmail.com>
Eric Dumazet <edumazet@google.com> wrote:
> On Fri, Apr 21, 2017 at 10:50 AM, Andrey Konovalov
> <andreyknvl@google.com> wrote:
> > Hi!
> >
> > We're investigating some approaches to improve isolation of syzkaller
> > programs. One of the ideas is run each program in it's own user/net
> > namespace. However, while I was experimenting with this, I stumbled
> > upon a problem.
> >
> > It seems that cleanup_net() might take a very long time to execute.
> >
> > I've attached the reproducer and kernel .config that I used. Run as
> > "./a.out 1". The reproducer just forks and does unshare(CLONE_NEWNET)
> > in a loop. Note, that I have a lot of network-related configs enabled,
> > which causes a few interfaces to be set up by default.
> >
> > What I see with this reproducer is that at first a huge number
> > (~200-300) net namespaces are created without any contention. But then
> > (probably when one of these namespaces gets destroyed) the program
> > hangs for a considerable amount of time (~100 seconds in my vm).
> > Nothing locks up inside the kernel and the CPU is mostly idle.
> >
> > Adding debug printfs showed that the part that takes almost all of
> > that time is the lines between synchronize_rcu() and
> > mutex_unlock(&net_mutex) in cleanup_net. Running perf showed that the
> > cause of this might be a lot of calls to synchronize_net that happen
> > while executing those lines.
> >
> > Is there any change that can be done to speed up the
> > creation/destruction of a huge number of net namespaces?
> >
>
> We have batches, but fundamentally this is a hard problem to solve.
>
> Every time we try, we add bugs :/
>
> RTNL is the new BKL (Big Kernel Lock of early linux) of today.
>
> Even the synchronize_rcu_expedited() done from synchronize_net() is a
> serious issue on some platforms.
Indeed. Setting net.netfilter.nf_conntrack_default_on=0 cuts time
cleanup time by 2/3 ...
nf unregister is way too happy to issue synchronize_net(), I'll work on
a fix.
^ permalink raw reply
* [Patch net] ip6mr: avoid double unregister of pim6reg device
From: Cong Wang @ 2017-04-21 19:27 UTC (permalink / raw)
To: netdev; +Cc: andreyknvl, Cong Wang, Linus Torvalds
If we unregister the pim6reg device via default_device_exit_batch(),
we will receive a notification and ip6mr_device_event() will
unregister it again. This causes a kernel BUG at net/core/dev.c:6813.
Like commit 7dc00c82cbb0 ("ipv4: Fix ipmr unregister device oops")
we should avoid double-unregister in netdevice notifier.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/ipv6/ip6mr.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 6ba6c90..72bee6d 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -774,7 +774,8 @@ static struct net_device *ip6mr_reg_vif(struct net *net, struct mr6_table *mrt)
* Delete a VIF entry
*/
-static int mif6_delete(struct mr6_table *mrt, int vifi, struct list_head *head)
+static int mif6_delete(struct mr6_table *mrt, int vifi, struct list_head *head,
+ bool unreg)
{
struct mif_device *v;
struct net_device *dev;
@@ -820,7 +821,7 @@ static int mif6_delete(struct mr6_table *mrt, int vifi, struct list_head *head)
dev->ifindex, &in6_dev->cnf);
}
- if (v->flags & MIFF_REGISTER)
+ if ((v->flags & MIFF_REGISTER) && unreg)
unregister_netdevice_queue(dev, head);
dev_put(dev);
@@ -1340,7 +1341,7 @@ static int ip6mr_device_event(struct notifier_block *this,
v = &mrt->vif6_table[0];
for (ct = 0; ct < mrt->maxvif; ct++, v++) {
if (v->dev == dev)
- mif6_delete(mrt, ct, &list);
+ mif6_delete(mrt, ct, &list, false);
}
}
unregister_netdevice_many(&list);
@@ -1552,7 +1553,7 @@ static void mroute_clean_tables(struct mr6_table *mrt, bool all)
for (i = 0; i < mrt->maxvif; i++) {
if (!all && (mrt->vif6_table[i].flags & VIFF_STATIC))
continue;
- mif6_delete(mrt, i, &list);
+ mif6_delete(mrt, i, &list, true);
}
unregister_netdevice_many(&list);
@@ -1707,7 +1708,7 @@ int ip6_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, uns
if (copy_from_user(&mifi, optval, sizeof(mifi_t)))
return -EFAULT;
rtnl_lock();
- ret = mif6_delete(mrt, mifi, NULL);
+ ret = mif6_delete(mrt, mifi, NULL, true);
rtnl_unlock();
return ret;
--
2.5.5
^ permalink raw reply related
* Re: [PATCHv2 next] bonding: fix wq initialization for links created via netlink
From: David Miller @ 2017-04-21 19:29 UTC (permalink / raw)
To: mahesh; +Cc: j.vosburgh, andy, vfalico, nikolay, edumazet, joe, netdev,
maheshb
In-Reply-To: <20170420194924.20829-1-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Thu, 20 Apr 2017 12:49:24 -0700
> From: Mahesh Bandewar <maheshb@google.com>
>
> Earlier patch 4493b81bea ("bonding: initialize work-queues during
> creation of bond") moved the work-queue initialization from bond_open()
> to bond_create(). However this caused the link those are created using
> netlink 'create bond option' (ip link add bondX type bond); create the
> new trunk without initializing work-queues. Prior to the above mentioned
> change, ndo_open was in both paths and things worked correctly. The
> consequence is visible in the report shared by Joe Stringer -
>
> I've noticed that this patch breaks bonding within namespaces if
> you're not careful to perform device cleanup correctly.
>
> Here's my repro script, you can run on any net-next with this patch
> and you'll start seeing some weird behaviour:
...
> Fixes: 4493b81bea ("bonding: initialize work-queues during creation of bond")
> Reported-by: Joe Stringer <joe@ovn.org>
> Tested-by: Joe Stringer <joe@ovn.org>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Fix values type used in test_maps
From: David Miller @ 2017-04-21 19:29 UTC (permalink / raw)
To: daniel; +Cc: ast, borkmann, netdev
In-Reply-To: <58F92725.5050304@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu, 20 Apr 2017 23:24:53 +0200
> On 04/20/2017 09:20 PM, David Miller wrote:
>>
>> Maps of per-cpu type have their value element size adjusted to 8 if it
>> is specified smaller during various map operations.
>>
>> This makes test_maps as a 32-bit binary fail, in fact the kernel
>> writes past the end of the value's array on the user's stack.
>>
>> To be quite honest, I think the kernel should reject creation of a
>> per-cpu map that doesn't have a value size of at least 8 if that's
>> what the kernel is going to silently adjust to later.
>
> It's unintuitive, agree, and it's in fact a round_up(value_size, 8),
> so rejecting a value size smaller than 8 doesn't really help; commit
> 15a07b33814d ("bpf: add lookup/update support for per-cpu hash and
> array maps") explained the rationale a bit. Hmm, we should probably
> move at least the bpf_num_possible_cpus() and round_up(val_size, 8)
> calculation as a single wrapper function to be used for determining
> the array size into bpf_util.h, so that it's slightly easier to deal
> with.
>
>> If the user passed something smaller, it is a sizeof() calcualtion
>> based upon the type they will actually use (just like in this testcase
>> code) in later calls to the map operations.
>
> Fixes: df570f577231 ("samples/bpf: unit test for
> BPF_MAP_TYPE_PERCPU_ARRAY")
>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Ok, applied to net-next, thanks to you and Alexei for reviewing.
^ permalink raw reply
* Re: [GIT] [4.12] NFC update
From: David Miller @ 2017-04-21 19:30 UTC (permalink / raw)
To: sameo; +Cc: linux-wireless, netdev, linux-nfc
In-Reply-To: <20170420213707.GA25763@zurbaran.ger.intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
Date: Thu, 20 Apr 2017 23:37:07 +0200
> This is the NFC pull request for 4.12. We have:
Pulled, thanks Samuel.
^ permalink raw reply
* Re: [PATCH v3 07/29] x86: bpf_jit, use ENTRY+ENDPROC
From: Alexei Starovoitov @ 2017-04-21 19:32 UTC (permalink / raw)
To: Jiri Slaby
Cc: mingo, tglx, hpa, x86, jpoimboe, linux-kernel, David S. Miller,
netdev, Daniel Borkmann, Eric Dumazet
In-Reply-To: <20170421141305.25180-7-jslaby@suse.cz>
On Fri, Apr 21, 2017 at 04:12:43PM +0200, Jiri Slaby wrote:
> Do not use a custom macro FUNC for starts of the global functions, use
> ENTRY instead.
>
> And while at it, annotate also ends of the functions by ENDPROC.
>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: netdev@vger.kernel.org
> ---
> arch/x86/net/bpf_jit.S | 32 ++++++++++++++++++--------------
> 1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/net/bpf_jit.S b/arch/x86/net/bpf_jit.S
> index f2a7faf4706e..762c29fb8832 100644
> --- a/arch/x86/net/bpf_jit.S
> +++ b/arch/x86/net/bpf_jit.S
> @@ -23,16 +23,12 @@
> 32 /* space for rbx,r13,r14,r15 */ + \
> 8 /* space for skb_copy_bits */)
>
> -#define FUNC(name) \
> - .globl name; \
> - .type name, @function; \
> - name:
> -
> -FUNC(sk_load_word)
> +ENTRY(sk_load_word)
> test %esi,%esi
> js bpf_slow_path_word_neg
> +ENDPROC(sk_load_word)
this doens't look right.
It will add alignment nops in critical paths of these pseudo functions.
I'm also not sure whether it will still work afterwards.
Was it tested?
I'd prefer if this code kept as-is.
> -FUNC(sk_load_word_positive_offset)
> +ENTRY(sk_load_word_positive_offset)
> mov %r9d,%eax # hlen
> sub %esi,%eax # hlen - offset
> cmp $3,%eax
> @@ -40,12 +36,14 @@ FUNC(sk_load_word_positive_offset)
> mov (SKBDATA,%rsi),%eax
> bswap %eax /* ntohl() */
> ret
> +ENDPROC(sk_load_word_positive_offset)
>
> -FUNC(sk_load_half)
> +ENTRY(sk_load_half)
> test %esi,%esi
> js bpf_slow_path_half_neg
> +ENDPROC(sk_load_half)
>
> -FUNC(sk_load_half_positive_offset)
> +ENTRY(sk_load_half_positive_offset)
> mov %r9d,%eax
> sub %esi,%eax # hlen - offset
> cmp $1,%eax
> @@ -53,16 +51,19 @@ FUNC(sk_load_half_positive_offset)
> movzwl (SKBDATA,%rsi),%eax
> rol $8,%ax # ntohs()
> ret
> +ENDPROC(sk_load_half_positive_offset)
>
> -FUNC(sk_load_byte)
> +ENTRY(sk_load_byte)
> test %esi,%esi
> js bpf_slow_path_byte_neg
> +ENDPROC(sk_load_byte)
>
> -FUNC(sk_load_byte_positive_offset)
> +ENTRY(sk_load_byte_positive_offset)
> cmp %esi,%r9d /* if (offset >= hlen) goto bpf_slow_path_byte */
> jle bpf_slow_path_byte
> movzbl (SKBDATA,%rsi),%eax
> ret
> +ENDPROC(sk_load_byte_positive_offset)
>
> /* rsi contains offset and can be scratched */
> #define bpf_slow_path_common(LEN) \
> @@ -119,31 +120,34 @@ bpf_slow_path_word_neg:
> cmp SKF_MAX_NEG_OFF, %esi /* test range */
> jl bpf_error /* offset lower -> error */
>
> -FUNC(sk_load_word_negative_offset)
> +ENTRY(sk_load_word_negative_offset)
> sk_negative_common(4)
> mov (%rax), %eax
> bswap %eax
> ret
> +ENDPROC(sk_load_word_negative_offset)
>
> bpf_slow_path_half_neg:
> cmp SKF_MAX_NEG_OFF, %esi
> jl bpf_error
>
> -FUNC(sk_load_half_negative_offset)
> +ENTRY(sk_load_half_negative_offset)
> sk_negative_common(2)
> mov (%rax),%ax
> rol $8,%ax
> movzwl %ax,%eax
> ret
> +ENDPROC(sk_load_half_negative_offset)
>
> bpf_slow_path_byte_neg:
> cmp SKF_MAX_NEG_OFF, %esi
> jl bpf_error
>
> -FUNC(sk_load_byte_negative_offset)
> +ENTRY(sk_load_byte_negative_offset)
> sk_negative_common(1)
> movzbl (%rax), %eax
> ret
> +ENDPROC(sk_load_byte_negative_offset)
>
> bpf_error:
> # force a return 0 from jit handler
> --
> 2.12.2
>
^ permalink raw reply
* Re: [Patch net] ip6mr: avoid double unregister of pim6reg device
From: Nikolay Aleksandrov @ 2017-04-21 19:34 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: andreyknvl, Linus Torvalds
In-Reply-To: <1492802839-16851-1-git-send-email-xiyou.wangcong@gmail.com>
On 21/04/17 22:27, Cong Wang wrote:
> If we unregister the pim6reg device via default_device_exit_batch(),
> we will receive a notification and ip6mr_device_event() will
> unregister it again. This causes a kernel BUG at net/core/dev.c:6813.
>
> Like commit 7dc00c82cbb0 ("ipv4: Fix ipmr unregister device oops")
> we should avoid double-unregister in netdevice notifier.
>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> net/ipv6/ip6mr.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
Cong,
Please read the full thread, I've already provided a fix which is similar.
https://patchwork.ozlabs.org/patch/753531/
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: LAN9303: add I2C dependency
From: David Miller @ 2017-04-21 19:34 UTC (permalink / raw)
To: arnd
Cc: andrew, vivien.didelot, f.fainelli, robh, jbe, sean.wang, john,
netdev, linux-kernel
In-Reply-To: <20170421162259.3312997-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 21 Apr 2017 18:22:40 +0200
> With CONFIG_I2C=m and NET_DSA_SMSC_LAN9303=y, we run into a link error:
>
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_byte_reg_read':
> regmap-i2c.c:(.text.regmap_smbus_byte_reg_read+0x18): undefined reference to `i2c_smbus_read_byte_data'
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_byte_reg_write':
> regmap-i2c.c:(.text.regmap_smbus_byte_reg_write+0x18): undefined reference to `i2c_smbus_write_byte_data'
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_word_reg_read':
> regmap-i2c.c:(.text.regmap_smbus_word_reg_read+0x18): undefined reference to `i2c_smbus_read_word_data'
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_word_read_swapped':
> regmap-i2c.c:(.text.regmap_smbus_word_read_swapped+0x18): undefined reference to `i2c_smbus_read_word_data'
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_word_write_swapped':
>
> This adds a Kconfig dependency to avoid the broken configuration.
>
> Fixes: be4e119f9914 ("net: dsa: LAN9303: add I2C managed mode support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] ip6mr: fix notification device destruction
From: David Miller @ 2017-04-21 19:36 UTC (permalink / raw)
To: nikolay
Cc: netdev, yoshfuji, dvyukov, kcc, syzkaller, edumazet, roopa,
torvalds, linux-kernel
In-Reply-To: <6d7dca26-4bc6-870c-8eb9-409f6c6b8fd5@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Fri, 21 Apr 2017 21:30:42 +0300
> On 21/04/17 20:42, Nikolay Aleksandrov wrote:
>> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
>> because we call unregister_netdevice_many for a device that is already
>> being destroyed. In IPv4's ipmr that has been resolved by two commits
>> long time ago by introducing the "notify" parameter to the delete
>> function and avoiding the unregister when called from a notifier, so
>> let's do the same for ip6mr.
...
> +CC LKML and Linus
Applied, thanks Nikolay and thanks Andrey for the report and testing.
Nikolay, how far does this bug go back?
^ permalink raw reply
* Re: net/core: BUG in unregister_netdevice_many
From: David Miller @ 2017-04-21 19:37 UTC (permalink / raw)
To: torvalds
Cc: andreyknvl, edumazet, kuznet, jmorris, yoshfuji, kaber, netdev,
linux-kernel, alexander.h.duyck, dsa, daniel, me, jiri, stephen,
dvyukov, kcc, syzkaller
In-Reply-To: <CA+55aFyTFzML+_8E_kDjX=YFkaDi_ejGo15UgGtAT29244UwgA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 21 Apr 2017 10:42:48 -0700
> Over to Eric and networking people. This oops is user-triggerable, and
> leaves the machine in a bad state (the original BUG_ON() and the new
> GP fault both happen while holding the RTNL, so networking is not
> healthy afterwards.
I have the fix in my tree and will push it to shortly.
^ permalink raw reply
* Re: [PATCH net-next 1/5] nfp: make use of the DMA_ATTR_SKIP_CPU_SYNC attr
From: David Miller @ 2017-04-21 19:37 UTC (permalink / raw)
To: alexander.duyck; +Cc: jakub.kicinski, netdev, oss-drivers, kubakici
In-Reply-To: <CAKgT0UfdbLV9tdYZXVQK6U2cF1Ljzc27uuVoNaZF-rHcmLUnPQ@mail.gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Fri, 21 Apr 2017 08:07:45 -0700
> On Fri, Apr 21, 2017 at 7:20 AM, Jakub Kicinski
> <jakub.kicinski@netronome.com> wrote:
>> DMA unmap may destroy changes CPU made to the buffer. To make XDP
>> run correctly on non-x86 platforms we should use the
>> DMA_ATTR_SKIP_CPU_SYNC attribute.
>>
>> Thanks to using the attribute we can now push the sync operation to
>> the common code path from XDP handler.
>>
>> A little bit of variable name reshuffling is required to bring the
>> code back to readable state.
>>
>> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> So I see where you added the sync_single_for_cpu, but what about the
> sync_single_for_device? It needs to be called for the buffer before
> you assign it for Rx. On x86 it won't really matter but for proper
> utilization of the DMA API you need to sync the buffer even for Rx
> just to make certain that the cache lines are evicted prior to the
> device attempting to write to the buffer.
Agreed, a sync before giving the buffer to the device is necessary.
^ permalink raw reply
* Re: net/core: BUG in unregister_netdevice_many
From: David Miller @ 2017-04-21 19:38 UTC (permalink / raw)
To: xiyou.wangcong
Cc: torvalds, andreyknvl, edumazet, kuznet, jmorris, yoshfuji, kaber,
netdev, linux-kernel, alexander.h.duyck, dsa, daniel, me, jiri,
stephen, dvyukov, kcc, syzkaller
In-Reply-To: <CAM_iQpUoWzeZPSKTCm13tumvOa7fLMJnz_0F_LSq4odYvWtRaQ@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 21 Apr 2017 11:55:04 -0700
> On Fri, Apr 21, 2017 at 10:25 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Fri, Apr 21, 2017 at 5:48 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>>
>>> I've got the following error report while fuzzing the kernel with syzkaller.
>>>
>>> ------------[ cut here ]------------
>>> kernel BUG at net/core/dev.c:6813!
>>
>> Another useless BUG_ON() that
>
> I think we are double-unregister'ing the pim6reg device,
> we probably need something like:
This particular bug is fixed by Nikolay's fix.
I'm not saying you haven't spotted another bug.
^ permalink raw reply
* Re: [PATCH RFC] sparc64: eBPF JIT
From: David Miller @ 2017-04-21 19:41 UTC (permalink / raw)
To: alexei.starovoitov; +Cc: daniel, sparclinux, netdev, ast
In-Reply-To: <20170421192619.GA91454@ast-mbp.thefacebook.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Fri, 21 Apr 2017 12:26:21 -0700
> It should pick up local headers without touching /usr/include.
> In the past I used to do 'make headers_install' before doing a build
> in samples/bpf or selftests, but then suddenly it started working
> without that step, so I figured something got fixed in the build system.
> May be it's arch specific somehow.
Yes, that's what the issue seemed to be.
I ran something unrelated and that triggered a headers_install, and
after that everything built fine.
I have some minor patches coming, to define arch specific accessors
for bpf_helpers.h and such.
^ permalink raw reply
* Re: net: cleanup_net is slow
From: Dmitry Vyukov @ 2017-04-21 19:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrey Konovalov, Cong Wang, netdev, LKML, Kostya Serebryany,
syzkaller
In-Reply-To: <CANn89i+iYtPLGDZpt3qk_cA-dq+004B=1qjP0ZygY3oREskQYA@mail.gmail.com>
On Fri, Apr 21, 2017 at 7:57 PM, Eric Dumazet <edumazet@google.com> wrote:
> On Fri, Apr 21, 2017 at 10:50 AM, Andrey Konovalov
> <andreyknvl@google.com> wrote:
>> Hi!
>>
>> We're investigating some approaches to improve isolation of syzkaller
>> programs. One of the ideas is run each program in it's own user/net
>> namespace. However, while I was experimenting with this, I stumbled
>> upon a problem.
>>
>> It seems that cleanup_net() might take a very long time to execute.
>>
>> I've attached the reproducer and kernel .config that I used. Run as
>> "./a.out 1". The reproducer just forks and does unshare(CLONE_NEWNET)
>> in a loop. Note, that I have a lot of network-related configs enabled,
>> which causes a few interfaces to be set up by default.
>>
>> What I see with this reproducer is that at first a huge number
>> (~200-300) net namespaces are created without any contention. But then
>> (probably when one of these namespaces gets destroyed) the program
>> hangs for a considerable amount of time (~100 seconds in my vm).
>> Nothing locks up inside the kernel and the CPU is mostly idle.
>>
>> Adding debug printfs showed that the part that takes almost all of
>> that time is the lines between synchronize_rcu() and
>> mutex_unlock(&net_mutex) in cleanup_net. Running perf showed that the
>> cause of this might be a lot of calls to synchronize_net that happen
>> while executing those lines.
>>
>> Is there any change that can be done to speed up the
>> creation/destruction of a huge number of net namespaces?
>>
>
> We have batches, but fundamentally this is a hard problem to solve.
>
> Every time we try, we add bugs :/
>
> RTNL is the new BKL (Big Kernel Lock of early linux) of today.
>
> Even the synchronize_rcu_expedited() done from synchronize_net() is a
> serious issue on some platforms.
Not sure how hard it is (I suppose hard) but if whole cleanup_net is
structured as series of call_rcu callbacks, it should give perfect
batching across all possible dimensions (e.g. across different
ops_exit_list calls and even across cleanup of different namespaces).
^ permalink raw reply
* [RFC] change the default Kconfig value of mlx5_en
From: Ian Kumlien @ 2017-04-21 19:45 UTC (permalink / raw)
To: saeedm, Linux Kernel Network Developers
[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]
Hi,
For some reason I spend some hours, two days in a row, trying to debug
why a newer
kernel didn't work on our machines. It worked just fine with the older kernel...
And there was no network interfaces to see or try to figure out what
was going on with.
Playing with the infiniband tools all i could see was things like:
...
state: 1: DOWN
phys state: 3: Disabled
cat: /sys/class/infiniband/mlx5_0/ports/1/rate: Invalid argument
rate: unknown
link_layer: Ethernet
...
It turns out that the kernel was compiled with mlx5_en disabled, since
it's the default
Unless there is a really good reason not to, lets change the default
value to 'y' =)
I'm hoping that this will lead to others not experiencing the same
surreal journey of
trying to debug this ;)
----
The mellanox driver supports both ethernet and infiniband, but it
is located in the ethernet drivers - the ethernet support should
default to 'yes'.
Signed-off-by: Ian Kumlien <ian.kumlien@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index ddb4ca4ff930..206894f06dec 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -15,7 +15,7 @@ config MLX5_CORE_EN
bool "Mellanox Technologies ConnectX-4 Ethernet support"
depends on NETDEVICES && ETHERNET && PCI && MLX5_CORE
imply PTP_1588_CLOCK
- default n
+ default y
---help---
Ethernet support in Mellanox Technologies ConnectX-4 NIC.
--
2.12.2
[-- Attachment #2: 0001-Switch-mlx5_en-default-configiuration-value.patch --]
[-- Type: text/x-patch, Size: 1070 bytes --]
From 19bc8a18fe793177e753589ffd69992434f38348 Mon Sep 17 00:00:00 2001
From: Ian Kumlien <ian.kumlien@gmail.com>
Date: Fri, 21 Apr 2017 21:30:30 +0200
Subject: [PATCH] Switch mlx5_en default configiuration value
The mellanox driver supports both ethernet and infiniband, but it
is located in the ethernet drivers - the ethernet support should
default to 'yes'.
Signed-off-by: Ian Kumlien <ian.kumlien@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index ddb4ca4ff930..206894f06dec 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -15,7 +15,7 @@ config MLX5_CORE_EN
bool "Mellanox Technologies ConnectX-4 Ethernet support"
depends on NETDEVICES && ETHERNET && PCI && MLX5_CORE
imply PTP_1588_CLOCK
- default n
+ default y
---help---
Ethernet support in Mellanox Technologies ConnectX-4 NIC.
--
2.12.2
^ permalink raw reply related
* Re: [PATCH v2] netpoll: Check for skb->queue_mapping
From: David Miller @ 2017-04-21 19:45 UTC (permalink / raw)
To: tushar.n.dave; +Cc: brouer, edumazet, netdev, sowmini.varadhan
In-Reply-To: <1492729051-4269-1-git-send-email-tushar.n.dave@oracle.com>
From: Tushar Dave <tushar.n.dave@oracle.com>
Date: Thu, 20 Apr 2017 15:57:31 -0700
> Reducing real_num_tx_queues needs to be in sync with skb queue_mapping
> otherwise skbs with queue_mapping greater than real_num_tx_queues
> can be sent to the underlying driver and can result in kernel panic.
>
> One such event is running netconsole and enabling VF on the same
> device. Or running netconsole and changing number of tx queues via
> ethtool on same device.
...
> Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com>
> ---
> v1->v2:
> - addressed comments from Eric Dumazet.
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: net: cleanup_net is slow
From: Florian Westphal @ 2017-04-21 19:45 UTC (permalink / raw)
To: Florian Westphal
Cc: Eric Dumazet, Andrey Konovalov, Cong Wang, netdev, LKML,
Dmitry Vyukov, Kostya Serebryany, syzkaller
In-Reply-To: <20170421192729.GA8853@breakpoint.cc>
Florian Westphal <fw@strlen.de> wrote:
> Indeed. Setting net.netfilter.nf_conntrack_default_on=0 cuts time
> cleanup time by 2/3 ...
>
> nf unregister is way too happy to issue synchronize_net(), I'll work on
> a fix.
I'll test this patch as a start. Maybe we can also leverage exit_batch
more on netfilter side.
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index a87a6f8a74d8..08fe1f526265 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -126,14 +126,15 @@ int nf_register_net_hook(struct net *net, const struct nf_hook_ops *reg)
}
EXPORT_SYMBOL(nf_register_net_hook);
-void nf_unregister_net_hook(struct net *net, const struct nf_hook_ops *reg)
+static struct nf_hook_entry *
+__nf_unregister_net_hook(struct net *net, const struct nf_hook_ops *reg)
{
struct nf_hook_entry __rcu **pp;
struct nf_hook_entry *p;
pp = nf_hook_entry_head(net, reg);
if (WARN_ON_ONCE(!pp))
- return;
+ return NULL;
mutex_lock(&nf_hook_mutex);
for (; (p = nf_entry_dereference(*pp)) != NULL; pp = &p->next) {
@@ -145,7 +146,7 @@ void nf_unregister_net_hook(struct net *net, const struct nf_hook_ops *reg)
mutex_unlock(&nf_hook_mutex);
if (!p) {
WARN(1, "nf_unregister_net_hook: hook not found!\n");
- return;
+ return NULL;
}
#ifdef CONFIG_NETFILTER_INGRESS
if (reg->pf == NFPROTO_NETDEV && reg->hooknum == NF_NETDEV_INGRESS)
@@ -154,6 +155,17 @@ void nf_unregister_net_hook(struct net *net, const struct nf_hook_ops *reg)
#ifdef HAVE_JUMP_LABEL
static_key_slow_dec(&nf_hooks_needed[reg->pf][reg->hooknum]);
#endif
+
+ return p;
+}
+
+void nf_unregister_net_hook(struct net *net, const struct nf_hook_ops *reg)
+{
+ struct nf_hook_entry *p = __nf_unregister_net_hook(net, reg);
+
+ if (!p)
+ return;
+
synchronize_net();
nf_queue_nf_hook_drop(net, p);
/* other cpu might still process nfqueue verdict that used reg */
@@ -183,10 +195,36 @@ int nf_register_net_hooks(struct net *net, const struct nf_hook_ops *reg,
EXPORT_SYMBOL(nf_register_net_hooks);
void nf_unregister_net_hooks(struct net *net, const struct nf_hook_ops *reg,
- unsigned int n)
+ unsigned int hookcount)
{
- while (n-- > 0)
- nf_unregister_net_hook(net, ®[n]);
+ struct nf_hook_entry *to_free[16];
+ unsigned int i, n;
+
+ WARN_ON_ONCE(hookcount > ARRAY_SIZE(to_free));
+
+ next_round:
+ n = min_t(unsigned int, hookcount, ARRAY_SIZE(to_free));
+
+ for (i = 0; i < n; i++)
+ to_free[i] = __nf_unregister_net_hook(net, ®[i]);
+
+ synchronize_net();
+
+ for (i = 0; i < n; i++) {
+ if (to_free[i])
+ nf_queue_nf_hook_drop(net, to_free[i]);
+ }
+
+ synchronize_net();
+
+ for (i = 0; i < n; i++)
+ kfree(to_free[i]);
+
+ if (n < hookcount) {
+ hookcount -= n;
+ reg += n;
+ goto next_round;
+ }
}
EXPORT_SYMBOL(nf_unregister_net_hooks);
^ permalink raw reply related
* Re: [RFC] change the default Kconfig value of mlx5_en
From: David Miller @ 2017-04-21 19:47 UTC (permalink / raw)
To: ian.kumlien; +Cc: saeedm, netdev
In-Reply-To: <CAA85sZumYPfUg_yA=5azrHneqq-XBmHiGNgRaEvBwbewVRj11w@mail.gmail.com>
From: Ian Kumlien <ian.kumlien@gmail.com>
Date: Fri, 21 Apr 2017 21:45:00 +0200
> The mellanox driver supports both ethernet and infiniband, but it
> is located in the ethernet drivers - the ethernet support should
> default to 'yes'.
I don't have that card and I therefore perhaps don't want that driver
in my builds.
This is not an appropriate change, sorry.
^ permalink raw reply
* Re: [PATCH net] ip6mr: fix notification device destruction
From: Nikolay Aleksandrov @ 2017-04-21 19:50 UTC (permalink / raw)
To: David Miller
Cc: netdev, yoshfuji, dvyukov, kcc, syzkaller, edumazet, roopa,
torvalds, linux-kernel
In-Reply-To: <20170421.153635.1878323052363882645.davem@davemloft.net>
On 21/04/17 22:36, David Miller wrote:
> From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Date: Fri, 21 Apr 2017 21:30:42 +0300
>
>> On 21/04/17 20:42, Nikolay Aleksandrov wrote:
>>> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
>>> because we call unregister_netdevice_many for a device that is already
>>> being destroyed. In IPv4's ipmr that has been resolved by two commits
>>> long time ago by introducing the "notify" parameter to the delete
>>> function and avoiding the unregister when called from a notifier, so
>>> let's do the same for ip6mr.
> ...
>> +CC LKML and Linus
>
> Applied, thanks Nikolay and thanks Andrey for the report and testing.
>
> Nikolay, how far does this bug go back?
>
Good question, AFAICS since ip6mr exists because it was copied from ipmr:
commit 7bc570c8b4f7
Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Thu Apr 3 09:22:53 2008 +0900
[IPV6] MROUTE: Support multicast forwarding.
^ permalink raw reply
* Re: [RFC] change the default Kconfig value of mlx5_en
From: Ian Kumlien @ 2017-04-21 19:51 UTC (permalink / raw)
To: David Miller; +Cc: saeedm, Linux Kernel Network Developers
In-Reply-To: <20170421.154745.182611990085743539.davem@davemloft.net>
On Fri, Apr 21, 2017 at 9:47 PM, David Miller <davem@davemloft.net> wrote:
> From: Ian Kumlien <ian.kumlien@gmail.com>
> Date: Fri, 21 Apr 2017 21:45:00 +0200
>
>> The mellanox driver supports both ethernet and infiniband, but it
>> is located in the ethernet drivers - the ethernet support should
>> default to 'yes'.
>
> I don't have that card and I therefore perhaps don't want that driver
> in my builds.
Ah, sorry - really tired here, got it in to my head that this was just
a flag for
the driver to build the ethernet module, sorry
> This is not an appropriate change, sorry.
Nope, completely agree... sorry for the noise
^ permalink raw reply
* Re: [PATCH net] ip6mr: fix notification device destruction
From: David Miller @ 2017-04-21 19:55 UTC (permalink / raw)
To: nikolay
Cc: netdev, yoshfuji, dvyukov, kcc, syzkaller, edumazet, roopa,
torvalds, linux-kernel
In-Reply-To: <44095170-e47c-ce85-d0f6-95a24da0e200@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Fri, 21 Apr 2017 22:50:35 +0300
> On 21/04/17 22:36, David Miller wrote:
>> From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>> Date: Fri, 21 Apr 2017 21:30:42 +0300
>>
>>> On 21/04/17 20:42, Nikolay Aleksandrov wrote:
>>>> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
>>>> because we call unregister_netdevice_many for a device that is already
>>>> being destroyed. In IPv4's ipmr that has been resolved by two commits
>>>> long time ago by introducing the "notify" parameter to the delete
>>>> function and avoiding the unregister when called from a notifier, so
>>>> let's do the same for ip6mr.
>> ...
>>> +CC LKML and Linus
>>
>> Applied, thanks Nikolay and thanks Andrey for the report and testing.
>>
>> Nikolay, how far does this bug go back?
>>
>
> Good question, AFAICS since ip6mr exists because it was copied from ipmr:
> commit 7bc570c8b4f7
> Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Date: Thu Apr 3 09:22:53 2008 +0900
>
> [IPV6] MROUTE: Support multicast forwarding.
Ok will queue it up for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH net] ip6mr: fix notification device destruction
From: Nikolay Aleksandrov @ 2017-04-21 19:56 UTC (permalink / raw)
To: David Miller
Cc: netdev, yoshfuji, dvyukov, kcc, syzkaller, edumazet, roopa,
torvalds, linux-kernel
In-Reply-To: <44095170-e47c-ce85-d0f6-95a24da0e200@cumulusnetworks.com>
On 21/04/17 22:50, Nikolay Aleksandrov wrote:
> On 21/04/17 22:36, David Miller wrote:
>> From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>> Date: Fri, 21 Apr 2017 21:30:42 +0300
>>
>>> On 21/04/17 20:42, Nikolay Aleksandrov wrote:
>>>> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
>>>> because we call unregister_netdevice_many for a device that is already
>>>> being destroyed. In IPv4's ipmr that has been resolved by two commits
>>>> long time ago by introducing the "notify" parameter to the delete
>>>> function and avoiding the unregister when called from a notifier, so
>>>> let's do the same for ip6mr.
>> ...
>>> +CC LKML and Linus
>>
>> Applied, thanks Nikolay and thanks Andrey for the report and testing.
>>
>> Nikolay, how far does this bug go back?
>>
>
> Good question, AFAICS since ip6mr exists because it was copied from ipmr:
> commit 7bc570c8b4f7
> Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Date: Thu Apr 3 09:22:53 2008 +0900
>
> [IPV6] MROUTE: Support multicast forwarding.
>
>
Oops no, my bad. That wouldn't cause it to BUG because it was already removed by mif6_delete
earlier. So since it can be destroyed by a netns exiting, currently I don't see any other
way which is outside of ip6mr for destroying that device.
That should be:
commit 8229efdaef1e
Author: Benjamin Thery <benjamin.thery@bull.net>
Date: Wed Dec 10 16:30:15 2008 -0800
netns: ip6mr: enable namespace support in ipv6 multicast forwarding code
Which allowed the notifier to be executed for pimreg devices in other network namespaces.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2017-04-21 19:56 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Don't race in IPSEC dumps, from Yuejie Shi.
2) Verify lengths properly in IPSEC reqeusts, from Herbert Xu.
3) Fix out of bounds access in ipv6 segment routing code, from David
Lebrun.
4) Don't write into the header of cloned SKBs in smsc95xx driver, from
James Hughes.
5) Several other drivers have this bug too, fix them. From Eric
Dumazet.
6) Fix access to uninitialized data in TC action cookie code, from
Wolfgang Bumiller.
7) Fix double free in IPV6 segment routing, again from David Lebrun.
8) Don't let userspace set the RTF_PCPU flag, oops. From David Ahern.
9) Fix use after free in qrtr code, from Dan Carpenter.
10) Don't double-destroy devices in ip6mr code, from Nikolay
Aleksandrov.
11) Don't pass out-of-range TX queue indices into drivers, from Tushar
Dave.
Please pull, thanks a lot!
The following changes since commit 005882e53d62f25dae10351a8d3f13326051e8f5:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc (2017-04-18 13:56:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to c70b17b775edb21280e9de7531acf6db3b365274:
netpoll: Check for skb->queue_mapping (2017-04-21 15:45:19 -0400)
----------------------------------------------------------------
Dan Carpenter (2):
dp83640: don't recieve time stamps twice
net: qrtr: potential use after free in qrtr_sendmsg()
Daniel Borkmann (1):
bpf, doc: update bpf maintainers entry
David Ahern (1):
net: ipv6: RTF_PCPU should not be settable from userspace
David Lebrun (2):
ipv6: sr: fix out-of-bounds access in SRH validation
ipv6: sr: fix double free of skb after handling invalid SRH
David Miller (1):
bpf: Fix values type used in test_maps
David S. Miller (5):
Merge tag 'mac80211-for-davem-2017-04-18' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
Merge branch 'qed-dcbx-fixes'
MAINTAINERS: Add "B:" field for networking.
Merge branch 'skb_cow_head'
Eric Dumazet (6):
smsc75xx: use skb_cow_head() to deal with cloned skbs
cx82310_eth: use skb_cow_head() to deal with cloned skbs
sr9700: use skb_cow_head() to deal with cloned skbs
lan78xx: use skb_cow_head() to deal with cloned skbs
ch9200: use skb_cow_head() to deal with cloned skbs
kaweth: use skb_cow_head() to deal with cloned skbs
Herbert Xu (1):
af_key: Fix sadb_x_ipsecrequest parsing
Ilan Tayari (1):
gso: Validate assumption of frag_list segementation
James Hughes (1):
smsc95xx: Use skb_cow_head to deal with cloned skbs
Johannes Berg (2):
mac80211: fix MU-MIMO follow-MAC mode
mac80211: reject ToDS broadcast data frames
Mike Maloney (1):
selftests/net: Fixes psock_fanout CBPF test case
Nikolay Aleksandrov (1):
ip6mr: fix notification device destruction
Sekhar Nori (1):
MAINTAINERS: update entry for TI's CPSW driver
Sergei Shtylyov (1):
sh_eth: unmap DMA buffers when freeing rings
Tushar Dave (1):
netpoll: Check for skb->queue_mapping
Wolfgang Bumiller (1):
net sched actions: allocate act cookie early
Yuejie Shi (1):
af_key: Add lock to key dump
sudarsana.kalluru@cavium.com (4):
qed: Fix possible error in populating max_tc field.
qed: Fix sending an invalid PFC error mask to MFW.
qed: Fix possible system hang in the dcbnl-getdcbx() path.
qed: Fix issue in populating the PFC config paramters.
MAINTAINERS | 18 +++++++++++++++--
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 13 +++++++++++-
drivers/net/ethernet/renesas/sh_eth.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------
drivers/net/phy/dp83640.c | 2 --
drivers/net/usb/ch9200.c | 9 ++-------
drivers/net/usb/cx82310_eth.c | 7 ++-----
drivers/net/usb/kaweth.c | 18 ++++++-----------
drivers/net/usb/lan78xx.c | 9 ++-------
drivers/net/usb/smsc75xx.c | 8 ++------
drivers/net/usb/smsc95xx.c | 12 +++++------
drivers/net/usb/sr9700.c | 9 ++-------
include/uapi/linux/ipv6_route.h | 2 +-
net/core/netpoll.c | 10 ++++++++--
net/core/skbuff.c | 18 +++++++++++++----
net/ipv6/exthdrs.c | 1 -
net/ipv6/ip6mr.c | 13 ++++++------
net/ipv6/route.c | 4 ++++
net/ipv6/seg6.c | 3 +++
net/key/af_key.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------
net/mac80211/rx.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------
net/qrtr/qrtr.c | 4 +++-
net/sched/act_api.c | 55 ++++++++++++++++++++++++++++++---------------------
tools/testing/selftests/bpf/test_maps.c | 4 ++--
tools/testing/selftests/net/psock_fanout.c | 22 +++++++++++++++++++--
tools/testing/selftests/net/psock_lib.h | 13 +++---------
25 files changed, 345 insertions(+), 210 deletions(-)
^ 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