* [PATCH net] net: avoid false positives in untrusted gso validation
From: Willem de Bruijn @ 2019-02-19 4:37 UTC (permalink / raw)
To: netdev; +Cc: davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
GSO packets with vnet_hdr must conform to a small set of gso_types.
The below commit uses flow dissection to drop packets that do not.
But it has false positives when the skb is not fully initialized.
Dissection needs skb->protocol and skb->network_header.
Infer skb->protocol from gso_type as the two must agree.
SKB_GSO_UDP can use both ipv4 and ipv6, so try both.
Exclude callers for which network header offset is not known.
Fixes: d5be7f632bad ("net: validate untrusted gso packets without csum offload")
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
include/linux/virtio_net.h | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 71f2394abbf7..e0348cb0a1dd 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -61,10 +61,20 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
/* gso packets without NEEDS_CSUM do not set transport_offset.
* probe and drop if does not match one of the above types.
*/
- if (gso_type) {
+ if (gso_type && skb->network_header) {
+ if (!skb->protocol)
+ virtio_net_hdr_set_proto(skb, hdr);
+retry:
skb_probe_transport_header(skb, -1);
- if (!skb_transport_header_was_set(skb))
+ if (!skb_transport_header_was_set(skb)) {
+ /* UFO does not specify ipv4 or 6: try both */
+ if (gso_type & SKB_GSO_UDP &&
+ skb->protocol == htons(ETH_P_IP)) {
+ skb->protocol = htons(ETH_P_IPV6);
+ goto retry;
+ }
return -EINVAL;
+ }
}
}
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel
From: Joel Fernandes @ 2019-02-19 4:34 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Alexei Starovoitov, Networking, Linux Kernel Mailing List,
Andrew Morton, Alexei Starovoitov, atish patra, Daniel Colascione,
Dan Williams, Greg Kroah-Hartman, Jonathan Corbet, Karim Yaghmour,
Kees Cook, kernel-team, open list:DOCUMENTATION,
open list:KERNEL SELFTEST FRAMEWORK, Manoj Rao, Paul McKenney,
Peter Zijlstra (Intel), Randy Dunlap, Steven Rostedt, Shuah Khan,
Thomas Gleixner, Yonghong Song
In-Reply-To: <CAK7LNAThSm1n1B_Ss0gRDZ3H-DWj2bvpZ+6Ui2jEo4Pt9YynEA@mail.gmail.com>
On Tue, Feb 19, 2019 at 01:14:11PM +0900, Masahiro Yamada wrote:
> On Fri, Feb 15, 2019 at 11:48 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Mon, Feb 11, 2019 at 09:35:59AM -0500, Joel Fernandes (Google) wrote:
> > > Introduce in-kernel headers and other artifacts which are made available
> > > as an archive through proc (/proc/kheaders.txz file).
>
>
> The extension '.txz' is not used in kernel code.
>
>
> '.tar.xz' is used for 'tarxz-pkg', 'perf-tarxz-src-pkg' etc.
>
>
> $ git grep '\.txz'
> $ git grep '\.tar\.xz'
> Documentation/admin-guide/README.rst: xz -cd linux-4.X.tar.xz | tar xvf -
> arch/x86/crypto/camellia-aesni-avx-asm_64.S: *
> http://koti.mbnet.fi/axh/crypto/camellia-BSD-1.2.0-aesni1.tar.xz
> crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
> crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
> crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
> crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
> crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
> scripts/package/Makefile: @echo ' perf-tarxz-src-pkg - Build
> $(perf-tar).tar.xz source tarball'
> tools/testing/selftests/gen_kselftest_tar.sh:
> ext=".tar.xz"
>
>
>
> I prefer '.tar.xz' for consistency.
Ok, I will change it to that.
> BTW, have you ever looked at scripts/extract-ikconfig?
>
> You added IKHD_ST and IKHD_ED
> just to mimic kernel/configs.c
>
> It is currently pointless without the extracting tool,
> but you might think it is useful to extract headers
> from vmlinux or the module without mounting procfs.
I am planing add to extraction support in the future, so I prefer to leave the
markers as it is for now. Hope that's Ok with you.
> > > This archive makes
> > > it possible to build kernel modules, run eBPF programs, and other
> > > tracing programs that need to extend the kernel for tracing purposes
> > > without any dependency on the file system having headers and build
> > > artifacts.
> > >
> > > On Android and embedded systems, it is common to switch kernels but not
> > > have kernel headers available on the file system. Raw kernel headers
> > > also cannot be copied into the filesystem like they can be on other
> > > distros, due to licensing and other issues. There's no linux-headers
> > > package on Android. Further once a different kernel is booted, any
> > > headers stored on the file system will no longer be useful. By storing
> > > the headers as a compressed archive within the kernel, we can avoid these
> > > issues that have been a hindrance for a long time.
> >
> > The set looks good to me and since the main use case is building bpf progs
> > I can route it via bpf-next tree if there are no objections.
> > Masahiro, could you please ack it?
>
>
> Honestly, I was not tracking this thread
> since I did not know I was responsible for this.
>
>
> I just started to take a closer look, then immediately got scared.
>
> This version is not mature enough for the merge.
> First of all, this patch cannot be compiled out-of-tree (O= option).
Oh, ok. This is not how I build the kernel. So I am sorry for missing that. I
will try this out-of-tree build option and fix it.
> I do not know why 0-day bot did not catch this apparent breakage.
>
>
> $ make -j8 O=hoge
> make[1]: Entering directory '/home/masahiro/workspace/bsp/linux/hoge'
> GEN Makefile
> Using .. as source for kernel
> DESCEND objtool
> CALL ../scripts/checksyscalls.sh
> CHK include/generated/compile.h
> make[2]: *** No rule to make target 'Module.symvers', needed by
> 'kernel/kheaders_data.txz'. Stop.
> make[2]: *** Waiting for unfinished jobs....
> /home/masahiro/workspace/bsp/linux/Makefile:1043: recipe for target
> 'kernel' failed
> make[1]: *** [kernel] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make[1]: Leaving directory '/home/masahiro/workspace/bsp/linux/hoge'
> Makefile:152: recipe for target 'sub-make' failed
> make: *** [sub-make] Error 2
>
>
>
>
>
> I was able to compile it in-tree
> but it makes the incremental build extremely slow.
>
> (Here, the incremental build means
> "make" without changing any code after the full build.)
>
>
>
>
> Before this patch, "make -j8" took 11 sec on my machine.
>
> real 0m11.777s
> user 0m16.608s
> sys 0m5.164s
>
>
>
> After this patch, x86_64_defconfig + CONFIG_IKHEADERS_PROC=y
> takes 53 sec for me since kernel/kheaders_data.txz is regenerated
> every time even when you did not touch any source file.
Hmm, true. Let me know look into that as well..
> $ time make -j8
> DESCEND objtool
> CALL scripts/checksyscalls.sh
> CHK include/generated/compile.h
> GEN kernel/kheaders_data.txz
> UPD kernel/kheaders_data.h
> CC kernel/kheaders.o
> AR kernel/built-in.a
> GEN .version
> CHK include/generated/compile.h
> UPD include/generated/compile.h
> CC init/version.o
> AR init/built-in.a
> AR built-in.a
> LD vmlinux.o
> MODPOST vmlinux.o
> KSYM .tmp_kallsyms1.o
> KSYM .tmp_kallsyms2.o
> LD vmlinux
> SORTEX vmlinux
> SYSMAP System.map
> Building modules, stage 2.
> CC arch/x86/boot/version.o
> MODPOST 17 modules
> VOFFSET arch/x86/boot/compressed/../voffset.h
> OBJCOPY arch/x86/boot/compressed/vmlinux.bin
> RELOCS arch/x86/boot/compressed/vmlinux.relocs
> CC arch/x86/boot/compressed/kaslr.o
> GZIP arch/x86/boot/compressed/vmlinux.bin.gz
> CC arch/x86/boot/compressed/misc.o
> MKPIGGY arch/x86/boot/compressed/piggy.S
> AS arch/x86/boot/compressed/piggy.o
> LD arch/x86/boot/compressed/vmlinux
> ZOFFSET arch/x86/boot/zoffset.h
> OBJCOPY arch/x86/boot/vmlinux.bin
> AS arch/x86/boot/header.o
> LD arch/x86/boot/setup.elf
> OBJCOPY arch/x86/boot/setup.bin
> BUILD arch/x86/boot/bzImage
> Setup is 15612 bytes (padded to 15872 bytes).
> System is 12673 kB
> CRC 697aaf88
> Kernel: arch/x86/boot/bzImage is ready (#6)
>
> real 0m53.024s
> user 0m32.076s
> sys 0m9.296s
>
>
>
>
> Also, I notice $(ARCH) must be fixed to $(SRCARCH),
> but that is one of minor issues.
Ok.
> We should take time for careful review and test.
Yes, I agree.
> Please give me more time for thorough review.
Sure. Thanks a lot for the feedback provided so far. I will send another
revision soon with all the suggestions addressed.
thanks,
- Joel
^ permalink raw reply
* Re: Three questions about busy poll
From: Cong Wang @ 2019-02-19 4:30 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Alexander Duyck, Eric Dumazet, Samudrala, Sridhar,
Linux Kernel Network Developers
In-Reply-To: <CA+FuTSc-Oq0XWowxDEYeZ+oT6SG8YZSu5nvzeOO5sUq3v51Lvg@mail.gmail.com>
On Fri, Feb 15, 2019 at 2:47 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> > > > 2. Why there is no socket option for sysctl.net.busy_poll? Clearly
> > > > sysctl_net_busy_poll is global and SO_BUSY_POLL only works for
> > > > sysctl.net.busy_read.
> > >
> > > I guess because of how sock_poll works. In that case it is not needed.
> > > The poll duration applies more to the pollset than any of the
> > > individual sockets, too.
> >
> >
> > Good point, it's probably like struct eventpoll vs. struct epitem.
> >
> > The reason why I am looking for a per-socket tuning is to minimize
> > the impact of setting busy_poll. I don't know if it is possible to somehow
> > make this per-socket via epoll interfaces, perhaps fundamentally
> > it is impossible?
>
> I think it may be possible. The way busy_read and busy_poll work
> in sock_poll is that the sum of all (per socket tunable) busy_read
> durations on the sockets in the pollset is ~bound by (global) busy_poll.
Good idea!!
I was actually thinking about checking sk->sk_ll_usec
ep_set_busy_poll_napi_id(). Your idea sounds better than mine.
Maybe we can do both together. :)
>
> The epoll implementation is restricted in the sense that it polls only
> on one napi_id at a time. Alongside setting ep->napi_id in
> ep_set_busy_poll_napi_id, we could also set a new ep field takes
> the min of the global busy_poll and sk->sk_ll_usec.
>
> Though I guess you want to be able to poll on a given pollset
> without setting the global sysctl_net_busy_poll at all? That
> would be a useful feature both for epoll and poll/select. But
> definitely requires refining net_busy_loop_on() to optionally
> take some state derived from the sockets in the (e)pollset.
Yes, or at least give some control to each application.
I was thinking about this:
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index a5d219d920e7..1b104c8bda5e 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -432,7 +432,7 @@ static inline void ep_set_busy_poll_napi_id(struct
epitem *epi)
return;
sk = sock->sk;
- if (!sk)
+ if (!sk || !sk->sk_ll_usec)
return;
napi_id = READ_ONCE(sk->sk_napi_id);
With this change, busy_poll would rely on either busy_read or
SO_BUSY_POLL.
Does this make any sense?
Thanks.
^ permalink raw reply related
* Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel
From: Alexei Starovoitov @ 2019-02-19 4:28 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Joel Fernandes (Google), Networking, Linux Kernel Mailing List,
Andrew Morton, Alexei Starovoitov, atish patra, Daniel Colascione,
Dan Williams, Greg Kroah-Hartman, Jonathan Corbet, Karim Yaghmour,
Kees Cook, kernel-team, open list:DOCUMENTATION,
open list:KERNEL SELFTEST FRAMEWORK, Manoj Rao, Paul McKenney,
Peter Zijlstra (Intel), Randy Dunlap, Steven Rostedt, Shuah Khan,
Thomas Gleixner, Yonghong Song
In-Reply-To: <CAK7LNAThSm1n1B_Ss0gRDZ3H-DWj2bvpZ+6Ui2jEo4Pt9YynEA@mail.gmail.com>
On Tue, Feb 19, 2019 at 01:14:11PM +0900, Masahiro Yamada wrote:
>
> I was able to compile it in-tree
> but it makes the incremental build extremely slow.
>
> (Here, the incremental build means
> "make" without changing any code after the full build.)
>
> Before this patch, "make -j8" took 11 sec on my machine.
>
> After this patch, x86_64_defconfig + CONFIG_IKHEADERS_PROC=y
> takes 53 sec for me since kernel/kheaders_data.txz is regenerated
> every time even when you did not touch any source file.
>
> We should take time for careful review and test.
>
> Please give me more time for thorough review.
Thanks for taking a look. All are very valid points.
Incremental build is must have.
^ permalink raw reply
* [tipc-discussion][net 0/2] improvement for wait and wakeup
From: Tung Nguyen @ 2019-02-19 4:20 UTC (permalink / raw)
To: davem, netdev; +Cc: tipc-discussion
Some improvements for tipc_wait_for_xzy().
Tung Nguyen (2):
tipc: improve function tipc_wait_for_cond()
tipc: improve function tipc_wait_for_rcvmsg()
net/tipc/socket.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--
2.17.1
^ permalink raw reply
* [tipc-discussion][net 1/2] tipc: improve function tipc_wait_for_cond()
From: Tung Nguyen @ 2019-02-19 4:20 UTC (permalink / raw)
To: davem, netdev; +Cc: tipc-discussion
In-Reply-To: <20190219042048.23243-1-tung.q.nguyen@dektech.com.au>
Commit 844cf763fba6 ("tipc: make macro tipc_wait_for_cond() smp safe")
replaced finish_wait() with remove_wait_queue() but still used
prepare_to_wait(). This causes unnecessary conditional
checking before adding to wait queue in prepare_to_wait().
This commit replaces prepare_to_wait() with add_wait_queue()
as the pair function with remove_wait_queue().
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
---
net/tipc/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 1217c90a363b..81b87916a0eb 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -388,7 +388,7 @@ static int tipc_sk_sock_err(struct socket *sock, long *timeout)
rc_ = tipc_sk_sock_err((sock_), timeo_); \
if (rc_) \
break; \
- prepare_to_wait(sk_sleep(sk_), &wait_, TASK_INTERRUPTIBLE); \
+ add_wait_queue(sk_sleep(sk_), &wait_); \
release_sock(sk_); \
*(timeo_) = wait_woken(&wait_, TASK_INTERRUPTIBLE, *(timeo_)); \
sched_annotate_sleep(); \
--
2.17.1
^ permalink raw reply related
* [tipc-discussion][net 2/2] tipc: improve function tipc_wait_for_rcvmsg()
From: Tung Nguyen @ 2019-02-19 4:20 UTC (permalink / raw)
To: davem, netdev; +Cc: tipc-discussion
In-Reply-To: <20190219042048.23243-1-tung.q.nguyen@dektech.com.au>
This commit replaces schedule_timeout() with wait_woken()
in function tipc_wait_for_rcvmsg(). wait_woken() uses
memory barriers in its implementation to avoid potential
race condition when putting a process into sleeping state
and then waking it up.
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
---
net/tipc/socket.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 81b87916a0eb..684f2125fc6b 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1677,7 +1677,7 @@ static void tipc_sk_send_ack(struct tipc_sock *tsk)
static int tipc_wait_for_rcvmsg(struct socket *sock, long *timeop)
{
struct sock *sk = sock->sk;
- DEFINE_WAIT(wait);
+ DEFINE_WAIT_FUNC(wait, woken_wake_function);
long timeo = *timeop;
int err = sock_error(sk);
@@ -1685,15 +1685,17 @@ static int tipc_wait_for_rcvmsg(struct socket *sock, long *timeop)
return err;
for (;;) {
- prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
if (timeo && skb_queue_empty(&sk->sk_receive_queue)) {
if (sk->sk_shutdown & RCV_SHUTDOWN) {
err = -ENOTCONN;
break;
}
+ add_wait_queue(sk_sleep(sk), &wait);
release_sock(sk);
- timeo = schedule_timeout(timeo);
+ timeo = wait_woken(&wait, TASK_INTERRUPTIBLE, timeo);
+ sched_annotate_sleep();
lock_sock(sk);
+ remove_wait_queue(sk_sleep(sk), &wait);
}
err = 0;
if (!skb_queue_empty(&sk->sk_receive_queue))
@@ -1709,7 +1711,6 @@ static int tipc_wait_for_rcvmsg(struct socket *sock, long *timeop)
if (err)
break;
}
- finish_wait(sk_sleep(sk), &wait);
*timeop = timeo;
return err;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel
From: Masahiro Yamada @ 2019-02-19 4:14 UTC (permalink / raw)
To: Alexei Starovoitov, Joel Fernandes (Google)
Cc: Networking, Linux Kernel Mailing List, Andrew Morton,
Alexei Starovoitov, atish patra, Daniel Colascione, Dan Williams,
Greg Kroah-Hartman, Jonathan Corbet, Karim Yaghmour, Kees Cook,
kernel-team, open list:DOCUMENTATION,
open list:KERNEL SELFTEST FRAMEWORK, Manoj Rao, Paul McKenney,
Peter Zijlstra (Intel), Randy Dunlap, Steven Rostedt, Shuah Khan,
Thomas Gleixner, Yonghong Song
In-Reply-To: <20190215031926.ljzluy2cfxp64u6o@ast-mbp>
On Fri, Feb 15, 2019 at 11:48 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Mon, Feb 11, 2019 at 09:35:59AM -0500, Joel Fernandes (Google) wrote:
> > Introduce in-kernel headers and other artifacts which are made available
> > as an archive through proc (/proc/kheaders.txz file).
The extension '.txz' is not used in kernel code.
'.tar.xz' is used for 'tarxz-pkg', 'perf-tarxz-src-pkg' etc.
$ git grep '\.txz'
$ git grep '\.tar\.xz'
Documentation/admin-guide/README.rst: xz -cd linux-4.X.tar.xz | tar xvf -
arch/x86/crypto/camellia-aesni-avx-asm_64.S: *
http://koti.mbnet.fi/axh/crypto/camellia-BSD-1.2.0-aesni1.tar.xz
crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
scripts/package/Makefile: @echo ' perf-tarxz-src-pkg - Build
$(perf-tar).tar.xz source tarball'
tools/testing/selftests/gen_kselftest_tar.sh:
ext=".tar.xz"
I prefer '.tar.xz' for consistency.
BTW, have you ever looked at scripts/extract-ikconfig?
You added IKHD_ST and IKHD_ED
just to mimic kernel/configs.c
It is currently pointless without the extracting tool,
but you might think it is useful to extract headers
from vmlinux or the module without mounting procfs.
> > This archive makes
> > it possible to build kernel modules, run eBPF programs, and other
> > tracing programs that need to extend the kernel for tracing purposes
> > without any dependency on the file system having headers and build
> > artifacts.
> >
> > On Android and embedded systems, it is common to switch kernels but not
> > have kernel headers available on the file system. Raw kernel headers
> > also cannot be copied into the filesystem like they can be on other
> > distros, due to licensing and other issues. There's no linux-headers
> > package on Android. Further once a different kernel is booted, any
> > headers stored on the file system will no longer be useful. By storing
> > the headers as a compressed archive within the kernel, we can avoid these
> > issues that have been a hindrance for a long time.
>
> The set looks good to me and since the main use case is building bpf progs
> I can route it via bpf-next tree if there are no objections.
> Masahiro, could you please ack it?
Honestly, I was not tracking this thread
since I did not know I was responsible for this.
I just started to take a closer look, then immediately got scared.
This version is not mature enough for the merge.
First of all, this patch cannot be compiled out-of-tree (O= option).
I do not know why 0-day bot did not catch this apparent breakage.
$ make -j8 O=hoge
make[1]: Entering directory '/home/masahiro/workspace/bsp/linux/hoge'
GEN Makefile
Using .. as source for kernel
DESCEND objtool
CALL ../scripts/checksyscalls.sh
CHK include/generated/compile.h
make[2]: *** No rule to make target 'Module.symvers', needed by
'kernel/kheaders_data.txz'. Stop.
make[2]: *** Waiting for unfinished jobs....
/home/masahiro/workspace/bsp/linux/Makefile:1043: recipe for target
'kernel' failed
make[1]: *** [kernel] Error 2
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/masahiro/workspace/bsp/linux/hoge'
Makefile:152: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
I was able to compile it in-tree
but it makes the incremental build extremely slow.
(Here, the incremental build means
"make" without changing any code after the full build.)
Before this patch, "make -j8" took 11 sec on my machine.
real 0m11.777s
user 0m16.608s
sys 0m5.164s
After this patch, x86_64_defconfig + CONFIG_IKHEADERS_PROC=y
takes 53 sec for me since kernel/kheaders_data.txz is regenerated
every time even when you did not touch any source file.
$ time make -j8
DESCEND objtool
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
GEN kernel/kheaders_data.txz
UPD kernel/kheaders_data.h
CC kernel/kheaders.o
AR kernel/built-in.a
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
AR init/built-in.a
AR built-in.a
LD vmlinux.o
MODPOST vmlinux.o
KSYM .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.o
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
Building modules, stage 2.
CC arch/x86/boot/version.o
MODPOST 17 modules
VOFFSET arch/x86/boot/compressed/../voffset.h
OBJCOPY arch/x86/boot/compressed/vmlinux.bin
RELOCS arch/x86/boot/compressed/vmlinux.relocs
CC arch/x86/boot/compressed/kaslr.o
GZIP arch/x86/boot/compressed/vmlinux.bin.gz
CC arch/x86/boot/compressed/misc.o
MKPIGGY arch/x86/boot/compressed/piggy.S
AS arch/x86/boot/compressed/piggy.o
LD arch/x86/boot/compressed/vmlinux
ZOFFSET arch/x86/boot/zoffset.h
OBJCOPY arch/x86/boot/vmlinux.bin
AS arch/x86/boot/header.o
LD arch/x86/boot/setup.elf
OBJCOPY arch/x86/boot/setup.bin
BUILD arch/x86/boot/bzImage
Setup is 15612 bytes (padded to 15872 bytes).
System is 12673 kB
CRC 697aaf88
Kernel: arch/x86/boot/bzImage is ready (#6)
real 0m53.024s
user 0m32.076s
sys 0m9.296s
Also, I notice $(ARCH) must be fixed to $(SRCARCH),
but that is one of minor issues.
We should take time for careful review and test.
Please give me more time for thorough review.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Kalle Valo @ 2019-02-19 4:06 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
X86 ML, linux-wireless, Christoph Hellwig, David S. Miller,
Networking, Linux Kernel Mailing List, Lorenzo Bianconi,
moderated list:ARM/Mediatek SoC support, linux-arm-kernel,
Felix Fietkau, Matthias Brugger
In-Reply-To: <CAK7LNAQMgFXw=rtpdPNZ=xpLw-SiwKGAgM__Owvqd1EhTCUntQ@mail.gmail.com>
Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> On Tue, Feb 19, 2019 at 4:38 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Kalle Valo <kvalo@codeaurora.org> writes:
>>
>> > Kalle Valo <kvalo@codeaurora.org> writes:
>> >
>> >> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
>> >>
>> >>> __sw_hweight8() is just internal implementation.
>> >>>
>> >>> Drivers should use the common API, hweight8().
>> >>>
>> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >>
>> >> Acked-by: Kalle Valo <kvalo@codeaurora.org>
>> >>
>> >>> This patch should go to x86 tree along with 2/2.
>> >>>
>> >>> Otherwise, all{yes,mod}config of x86 would be broken.
>> >>>
>> >>> This patch is trivial enough.
>> >>> I want ACK from the net/wireless maintainer
>> >>> so that this can go in via x86 tree.
>> >>
>> >> Sounds good to me, feel free to push via the x86 tree.
>> >
>> > Actually, can you wait a bit? Felix just reminded me that we have a
>> > similar patch pending from Ben Hutchings:
>> >
>> > https://patchwork.kernel.org/patch/10808203/
>> >
>> > And it seems there are two instances of __sw_hweight8, at least in my
>> > wireless-drivers-next tree:
>> >
>> > drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
>> > __sw_hweight8(dev->antenna_mask);
>> > drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
>> > __sw_hweight8(dev->antenna_mask);
>> >
>> > So we need to think what to do.
>>
>> I think the best would be that Felix applies Ben's patch to the wireless
>> tree and I'll push it to Linus during the next merge window (via
>> net-next). Simpler and less conflicts that way.
>>
>> So Masahiro, could you hold your x86 patch for a while until the mt76
>> patch will be in Linus' tree? That should not take more than two weeks,
>> I think.
>
> Sure.
> I will resend 2/2 later.
Great, thanks!
--
Kalle Valo
^ permalink raw reply
* Re: WARNING in xfrm_policy_fini
From: syzbot @ 2019-02-19 3:05 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
In-Reply-To: <000000000000c5745b0573d62311@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: a3b22b9f11d9 Linux 5.0-rc7
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17e3d4d0c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=7132344728e7ec3f
dashboard link: https://syzkaller.appspot.com/bug?extid=9bce6db6c82f06b85d8b
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177317a8c00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9bce6db6c82f06b85d8b@syzkaller.appspotmail.com
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
cgroup: fork rejected by pids controller in /syz3
cgroup: fork rejected by pids controller in /syz2
WARNING: CPU: 1 PID: 31 at net/xfrm/xfrm_policy.c:3871
xfrm_policy_fini+0x30c/0x3a0 net/xfrm/xfrm_policy.c:3871
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 31 Comm: kworker/u4:2 Not tainted 5.0.0-rc7 #77
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
panic+0x2cb/0x65c kernel/panic.c:214
__warn.cold+0x20/0x45 kernel/panic.c:571
report_bug+0x263/0x2b0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
fixup_bug arch/x86/kernel/traps.c:173 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
kobject: 'loop1' (00000000fd200829): kobject_uevent_env
RIP: 0010:xfrm_policy_fini+0x30c/0x3a0 net/xfrm/xfrm_policy.c:3871
Code: c3 e8 b8 e9 72 fb 0f 0b e9 49 fe ff ff e8 ac e9 72 fb 0f 0b e9 cd fd
ff ff e8 a0 e9 72 fb 0f 0b e9 00 ff ff ff e8 94 e9 72 fb <0f> 0b e9 62 fd
ff ff e8 98 e8 a9 fb e9 7d fe ff ff 4c 89 ff e8 ab
kobject: 'loop1' (00000000fd200829): fill_kobj_path: path
= '/devices/virtual/block/loop1'
RSP: 0018:ffff8880a9a8fbb0 EFLAGS: 00010293
RAX: ffff8880a9a82100 RBX: ffff88808e30dbf0 RCX: 1ffff1101535053e
RDX: 0000000000000000 RSI: ffffffff85fcf7ec RDI: ffff8880a9a8297c
RBP: ffff8880a9a8fbf0 R08: ffff8880a9a82100 R09: ffff8880a9a829f0
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88808e30c080
R13: ffff8880a9a8fcc8 R14: ffffffff893d5eb8 R15: dffffc0000000000
xfrm_net_exit+0x1d/0x70 net/xfrm/xfrm_policy.c:3931
ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
cleanup_net+0x3fb/0x960 net/core/net_namespace.c:551
kobject: 'loop1' (00000000fd200829): kobject_uevent_env
kobject: 'loop1' (00000000fd200829): fill_kobj_path: path
= '/devices/virtual/block/loop1'
cgroup: fork rejected by pids controller in /syz1
process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
worker_thread+0x98/0xe40 kernel/workqueue.c:2319
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [PATCH] can: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-02-19 2:57 UTC (permalink / raw)
To: Nicolas.Ferre, wg, mkl, davem, alexandre.belloni,
Ludovic.Desroches
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel, Kees Cook
In-Reply-To: <daae008e-35fd-7553-fcb2-7932fe53b959@embeddedor.com>
Hi,
Friendly ping:
Dave, I wonder if you can take this.
Thanks
--
Gustavo
On 2/14/19 3:37 PM, Gustavo A. R. Silva wrote:
>
>
> On 1/30/19 2:11 AM, Nicolas.Ferre@microchip.com wrote:
>> On 29/01/2019 at 19:06, Gustavo A. R. Silva wrote:
>>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>>> where we are expecting to fall through.
>>>
>>> This patch fixes the following warnings:
>>>
>>> drivers/net/can/peak_canfd/peak_pciefd_main.c:668:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> drivers/net/can/spi/mcp251x.c:875:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> drivers/net/can/usb/peak_usb/pcan_usb.c:422:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> drivers/net/can/at91_can.c:895:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> drivers/net/can/at91_can.c:953:15: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> drivers/net/can/usb/peak_usb/pcan_usb.c: In function ‘pcan_usb_decode_error’:
>>> drivers/net/can/usb/peak_usb/pcan_usb.c:422:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> if (n & PCAN_USB_ERROR_BUS_LIGHT) {
>>> ^
>>> drivers/net/can/usb/peak_usb/pcan_usb.c:428:2: note: here
>>> case CAN_STATE_ERROR_WARNING:
>>> ^~~~
>>>
>>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>>
>>> This patch is part of the ongoing efforts to enabling
>>> -Wimplicit-fallthrough.
>>>
>>> Notice that in some cases spelling mistakes were fixed.
>>> In other cases, the /* fall through */ comment is placed
>>> at the bottom of the case statement, which is what GCC
>>> is expecting to find.
>>>
>>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>>> ---
>>> drivers/net/can/at91_can.c | 6 ++++--
>>
>> For this one:
>> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
>>
>
> Thanks, Nicolas.
>
> Dave:
>
> I wonder if you can take this patch.
>
> Thanks
> --
> Gustavo
>
>>> drivers/net/can/peak_canfd/peak_pciefd_main.c | 2 +-
>>> drivers/net/can/spi/mcp251x.c | 3 ++-
>>> drivers/net/can/usb/peak_usb/pcan_usb.c | 2 +-
>>> 4 files changed, 8 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
>>> index d98c69045b17..1718c20f9c99 100644
>>> --- a/drivers/net/can/at91_can.c
>>> +++ b/drivers/net/can/at91_can.c
>>> @@ -902,7 +902,8 @@ static void at91_irq_err_state(struct net_device *dev,
>>> CAN_ERR_CRTL_TX_WARNING :
>>> CAN_ERR_CRTL_RX_WARNING;
>>> }
>>> - case CAN_STATE_ERROR_WARNING: /* fallthrough */
>>> + /* fall through */
>>> + case CAN_STATE_ERROR_WARNING:
>>> /*
>>> * from: ERROR_ACTIVE, ERROR_WARNING
>>> * to : ERROR_PASSIVE, BUS_OFF
>>> @@ -951,7 +952,8 @@ static void at91_irq_err_state(struct net_device *dev,
>>> netdev_dbg(dev, "Error Active\n");
>>> cf->can_id |= CAN_ERR_PROT;
>>> cf->data[2] = CAN_ERR_PROT_ACTIVE;
>>> - case CAN_STATE_ERROR_WARNING: /* fallthrough */
>>> + /* fall through */
>>> + case CAN_STATE_ERROR_WARNING:
>>> reg_idr = AT91_IRQ_ERRA | AT91_IRQ_WARN | AT91_IRQ_BOFF;
>>> reg_ier = AT91_IRQ_ERRP;
>>> break;
>>> diff --git a/drivers/net/can/peak_canfd/peak_pciefd_main.c b/drivers/net/can/peak_canfd/peak_pciefd_main.c
>>> index c458d5fdc8d3..e4f4d65a76b4 100644
>>> --- a/drivers/net/can/peak_canfd/peak_pciefd_main.c
>>> +++ b/drivers/net/can/peak_canfd/peak_pciefd_main.c
>>> @@ -668,7 +668,7 @@ static int pciefd_can_probe(struct pciefd_board *pciefd)
>>> pciefd_can_writereg(priv, CANFD_CLK_SEL_80MHZ,
>>> PCIEFD_REG_CAN_CLK_SEL);
>>>
>>> - /* fallthough */
>>> + /* fall through */
>>> case CANFD_CLK_SEL_80MHZ:
>>> priv->ucan.can.clock.freq = 80 * 1000 * 1000;
>>> break;
>>> diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
>>> index e90817608645..17257c73c302 100644
>>> --- a/drivers/net/can/spi/mcp251x.c
>>> +++ b/drivers/net/can/spi/mcp251x.c
>>> @@ -875,7 +875,8 @@ static irqreturn_t mcp251x_can_ist(int irq, void *dev_id)
>>> if (new_state >= CAN_STATE_ERROR_WARNING &&
>>> new_state <= CAN_STATE_BUS_OFF)
>>> priv->can.can_stats.error_warning++;
>>> - case CAN_STATE_ERROR_WARNING: /* fallthrough */
>>> + /* fall through */
>>> + case CAN_STATE_ERROR_WARNING:
>>> if (new_state >= CAN_STATE_ERROR_PASSIVE &&
>>> new_state <= CAN_STATE_BUS_OFF)
>>> priv->can.can_stats.error_passive++;
>>> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb.c b/drivers/net/can/usb/peak_usb/pcan_usb.c
>>> index 13238a72a338..eca785532b6b 100644
>>> --- a/drivers/net/can/usb/peak_usb/pcan_usb.c
>>> +++ b/drivers/net/can/usb/peak_usb/pcan_usb.c
>>> @@ -423,7 +423,7 @@ static int pcan_usb_decode_error(struct pcan_usb_msg_context *mc, u8 n,
>>> new_state = CAN_STATE_ERROR_WARNING;
>>> break;
>>> }
>>> - /* else: fall through */
>>> + /* fall through */
>>>
>>> case CAN_STATE_ERROR_WARNING:
>>> if (n & PCAN_USB_ERROR_BUS_HEAVY) {
>>>
>>
>>
^ permalink raw reply
* Re: [PATCH net-next] yellowfin: fix remove set but not used variable warning
From: YueHaibing @ 2019-02-19 2:34 UTC (permalink / raw)
To: David Miller; +Cc: yang.wei9, netdev, kernel-janitors
In-Reply-To: <20190218.121337.147896114474592034.davem@davemloft.net>
On 2019/2/19 4:13, David Miller wrote:
> From: YueHaibing <yuehaibing@huawei.com>
> Date: Mon, 18 Feb 2019 08:15:46 +0000
>
>> @@ -1050,8 +1050,11 @@ static int yellowfin_rx(struct net_device *dev)
>> struct sk_buff *rx_skb = yp->rx_skbuff[entry];
>> s16 frame_status;
>> u16 desc_status;
>> - int data_size, yf_size;
>> + int data_size;
>> u8 *buf_addr;
>> +#ifdef YF_PROTOTYPE
>> + int yf_size = sizeof(struct yellowfin_desc);
>> +#endif
>
> This is just silly.
>
> Please move this variable declaration and initialization into the
> YF_PROTOTYPE basic block in the code below it, like this:
>
> #ifdef YF_PROTOTYPE /* Support for prototype hardware errata. */
> } else if ((yp->flags & HasMACAddrBug) &&
> int yf_size = sizeof(struct yellowfin_desc);
There's just in if condition, define the 'yf_size' seems incorrect
maybe we can remove 'yf_size' and use sizeof directly?
>
> !ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
> entry * yf_size),
> dev->dev_addr) &&
> !ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
> entry * yf_size),
> "\377\377\377\377\377\377")) {
> if (bogus_rx++ == 0)
> netdev_warn(dev, "Bad frame to %pM\n",
> buf_addr);
> #endif
>
> Thanks.
>
> .
>
^ permalink raw reply
* [PATCH][net-next] bridge: remove redundant check on err in br_multicast_ipv4_rcv
From: Li RongQing @ 2019-02-19 2:17 UTC (permalink / raw)
To: netdev
br_ip4_multicast_mrd_rcv only return 0 and -ENOMSG,
no other negative value
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/bridge/br_multicast.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 4a048fd1cbea..fe9f2d8ca2c1 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1615,12 +1615,7 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
if (ip_hdr(skb)->protocol == IPPROTO_PIM)
br_multicast_pim(br, port, skb);
} else if (ipv4_is_all_snoopers(ip_hdr(skb)->daddr)) {
- err = br_ip4_multicast_mrd_rcv(br, port, skb);
-
- if (err < 0 && err != -ENOMSG) {
- br_multicast_err_count(br, port, skb->protocol);
- return err;
- }
+ br_ip4_multicast_mrd_rcv(br, port, skb);
}
return 0;
--
2.16.2
^ permalink raw reply related
* [PATCH] net: remove unneeded switch fall-through
From: Li RongQing @ 2019-02-19 2:15 UTC (permalink / raw)
To: netdev
This case block has been terminated by a return, so not need
a switch fall-through
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/ipv4/igmp.c | 1 -
net/ipv6/mcast_snoop.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index b448cf32296c..6c2febc39dca 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1541,7 +1541,6 @@ static int ip_mc_check_igmp_msg(struct sk_buff *skb)
case IGMP_HOST_LEAVE_MESSAGE:
case IGMP_HOST_MEMBERSHIP_REPORT:
case IGMPV2_HOST_MEMBERSHIP_REPORT:
- /* fall through */
return 0;
case IGMPV3_HOST_MEMBERSHIP_REPORT:
return ip_mc_check_igmp_reportv3(skb);
diff --git a/net/ipv6/mcast_snoop.c b/net/ipv6/mcast_snoop.c
index 55e2ac179f28..dddd75d1be0e 100644
--- a/net/ipv6/mcast_snoop.c
+++ b/net/ipv6/mcast_snoop.c
@@ -128,7 +128,6 @@ static int ipv6_mc_check_mld_msg(struct sk_buff *skb)
switch (mld->mld_type) {
case ICMPV6_MGM_REDUCTION:
case ICMPV6_MGM_REPORT:
- /* fall through */
return 0;
case ICMPV6_MLD2_REPORT:
return ipv6_mc_check_mld_reportv2(skb);
--
2.16.2
^ permalink raw reply related
* Re: [PATCH 0/2] Netfilter/IPVS fixes for net
From: David Miller @ 2019-02-19 1:56 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190218230823.8114-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Tue, 19 Feb 2019 00:08:21 +0100
> The following patchset contains Netfilter/IPVS fixes for net:
>
> 1) Follow up patch to fix a compilation warning in a recent IPVS fix:
> 098e13f5b21d ("ipvs: fix dependency on nf_defrag_ipv6").
>
> 2) Bogus ENOENT error on flush after rule deletion in the same batch,
> reported by Phil Sutter.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net v4.15..v4.19] net: dsa: Fix NPD checking for br_vlan_enabled()
From: David Miller @ 2019-02-19 1:54 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, frank-w, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20190218223011.4824-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 18 Feb 2019 14:30:11 -0800
> It is possible for the DSA slave network device not to be part of a
> bridge, yet have an upper device like a VLAN device be part of a bridge.
> When that VLAN device is enslaved, since it does not define any
> switchdev_ops, we will recurse down to the lower/physical port device,
> call switchdev_port_obj_add() with a VLAN, and here we will check
> br_vlan_enabled() on a NULL dp->bridge_dev, thus causing a NULL pointer
> de-reference.
>
> This is no longer a problem upstream after commit d17d9f5e5143
> ("switchdev: Replace port obj add/del SDO with a notification").
>
> Fixes: 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is disabled")
> Reported-by: Frank Wunderlich <frank-w@public-files.de>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> David,
>
> This affects v4.15..v4.19, but not v5.0-rc1 can you still queue this up
> for -stable? Thanks!
Queued up.
^ permalink raw reply
* Re: [PATCH v2] bonding: fix PACKET_ORIGDEV regression
From: David Ahern @ 2019-02-19 1:51 UTC (permalink / raw)
To: Michal Soltys, David Miller
Cc: Maciej Żenczykowski, Jay Vosburgh, Vincent Bernat,
Mahesh Bandewar, Chonggang Li, Linux NetDev
In-Reply-To: <20190218165528.15575-1-soltys@ziu.info>
On 2/18/19 9:55 AM, Michal Soltys wrote:
> This patch fixes a subtle PACKET_ORIGDEV regression which was a side
> effect of fixes introduced by:
>
> 6a9e461f6fe4 bonding: pass link-local packets to bonding master also.
>
> ... to:
>
> b89f04c61efe bonding: deliver link-local packets with skb->dev set to link that packets arrived on
>
> While 6a9e461f6fe4 restored pre-b89f04c61efe presence of link-local
> packets on bonding masters (which is required e.g. by linux bridges
> participating in spanning tree or needed for lab-like setups created
> with group_fwd_mask) it also caused the originating device
> information to be lost due to cloning.
>
> Maciej Żenczykowski proposed another solution that doesn't require
> packet cloning and retains original device information - instead of
> returning RX_HANDLER_PASS for all link-local packets it's now limited
> only to packets from inactive slaves.
>
> At the same time, packets passed to bonding masters retain correct
> information about the originating device and PACKET_ORIGDEV can be used
> to determine it.
>
> This elegantly solves all issues so far:
>
> - link-local packets that were removed from bonding masters
> - LLDP daemons being forced to explicitly bind to slave interfaces
> - PACKET_ORIGDEV having no effect on bond interfaces
>
> Fixes: 6a9e461f6fe4 (bonding: pass link-local packets to bonding master also.)
> Reported-by: Vincent Bernat <vincent@bernat.ch>
> Signed-off-by: Michal Soltys <soltys@ziu.info>
> ---
> drivers/net/bonding/bond_main.c | 35 +++++++++++++--------------------
> 1 file changed, 14 insertions(+), 21 deletions(-)
>
Hi Michal:
Can you add test cases that shows the expectations of this API? Given
the back and forth on the last set of patches -- and the impacts to
lldpd users for example -- we really need test cases added to selftests.
^ permalink raw reply
* Re: [PATCH] net: netcp: Fix ethss driver probe issue
From: David Miller @ 2019-02-19 1:50 UTC (permalink / raw)
To: m-karicheri2; +Cc: w-kwok2, netdev, linux-kernel
In-Reply-To: <20190218201051.19623-1-m-karicheri2@ti.com>
From: Murali Karicheri <m-karicheri2@ti.com>
Date: Mon, 18 Feb 2019 15:10:51 -0500
> Recent commit below has introduced a bug in netcp driver that causes
> the ethss driver probe failure and thus break the networking function
> on K2 SoCs such as K2HK, K2L, K2E etc. This patch fixes the issue to
> restore networking on the above SoCs.
>
> Fixes: 21c328dcecfc ("net: ethernet: Convert to using %pOFn instead of device_node.name")
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] net: hns: Fixes the missing put_device in positive leg for roce reset
From: David Miller @ 2019-02-19 1:45 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linux-rdma, linuxarm
In-Reply-To: <20190218174032.22972-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Mon, 18 Feb 2019 17:40:32 +0000
> This patch fixes the missing device reference release-after-use in
> the positive leg of the roce reset API of the HNS DSAF.
>
> Fixes: c969c6e7ab8c ("net: hns: Fix object reference leaks in hns_dsaf_roce_reset()")
> Reported-by: John Garry <john.garry@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Applied, thanks Salil.
^ permalink raw reply
* Re: pull-request: wireless-drivers 2019-02-18
From: David Miller @ 2019-02-19 1:41 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87zhqtt98h.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 18 Feb 2019 17:19:26 +0200
> here's one more pull request to net tree for 5.0. Please let me know if
> you have any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH net] net: stmmac: Fix a race in EEE enable callback
From: David Miller @ 2019-02-19 1:40 UTC (permalink / raw)
To: jose.abreu
Cc: netdev, linux-kernel, joao.pinto, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <fb866bb5dd8a11326fab8e6d393f2a37eed5073f.1550496861.git.joabreu@synopsys.com>
From: Jose Abreu <jose.abreu@synopsys.com>
Date: Mon, 18 Feb 2019 14:35:03 +0100
> We are saving the status of EEE even before we try to enable it. This
> leads to a race with XMIT function that tries to arm EEE timer before we
> set it up.
>
> Fix this by only saving the EEE parameters after all operations are
> performed with success.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Fixes: d765955d2ae0 ("stmmac: add the Energy Efficient Ethernet support")
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH][unix] missing barriers in some of unix_sock ->addr and ->path accesses
From: Sasha Levin @ 2019-02-19 1:30 UTC (permalink / raw)
To: Al Viro; +Cc: netdev, David Miller, stable, stable
In-Reply-To: <20190218213246.GV2217@ZenIV.linux.org.uk>
On Mon, Feb 18, 2019 at 09:32:46PM +0000, Al Viro wrote:
>On Mon, Feb 18, 2019 at 09:14:33PM +0000, Sasha Levin wrote:
>> Hi,
>>
>> [This is an automated email]
>>
>> This commit has been processed because it contains a -stable tag.
>
>Ugh... Should've removed Cc; stable from netdev posting; my apologies.
>
>> How should we proceed with this patch?
>
>Wait for it to get into davem's tree, for starters?
It won't go in stable until it's upstream, the only reason for this
early mail is that it's easier to get responses from people while the
patch is still fresh in their brains (as you might have noticed ;) )
rather than in a few weeks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] NETWORKING: avoid use IPCB in cipso_v4_error
From: David Miller @ 2019-02-19 1:25 UTC (permalink / raw)
To: s-nazarov; +Cc: paul, netdev, linux-security-module, kuznet, yoshfuji
In-Reply-To: <1122331550497151@iva7-d29a8296bc3c.qloud-c.yandex.net>
From: Nazarov Sergey <s-nazarov@yandex.ru>
Date: Mon, 18 Feb 2019 16:39:11 +0300
> I think, it would not be a good solution, if I will analyze all
> subsystems using icmp_send, because I do not have enough knowledge
> for this. I propose to add a new function, for example,
> ismp_send_safe, something like that:
Please don't do this.
Solve the problem properly by auditing each case, there aren't a lot and
it is not too difficult to see the upcall sites.
^ permalink raw reply
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Masahiro Yamada @ 2019-02-19 1:13 UTC (permalink / raw)
To: Kalle Valo
Cc: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
X86 ML, linux-wireless, Christoph Hellwig, David S. Miller,
Networking, Linux Kernel Mailing List, Lorenzo Bianconi,
moderated list:ARM/Mediatek SoC support, linux-arm-kernel,
Felix Fietkau, Matthias Brugger
In-Reply-To: <87pnrosy29.fsf@kamboji.qca.qualcomm.com>
On Tue, Feb 19, 2019 at 4:38 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Kalle Valo <kvalo@codeaurora.org> writes:
>
> > Kalle Valo <kvalo@codeaurora.org> writes:
> >
> >> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> >>
> >>> __sw_hweight8() is just internal implementation.
> >>>
> >>> Drivers should use the common API, hweight8().
> >>>
> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >>
> >> Acked-by: Kalle Valo <kvalo@codeaurora.org>
> >>
> >>> This patch should go to x86 tree along with 2/2.
> >>>
> >>> Otherwise, all{yes,mod}config of x86 would be broken.
> >>>
> >>> This patch is trivial enough.
> >>> I want ACK from the net/wireless maintainer
> >>> so that this can go in via x86 tree.
> >>
> >> Sounds good to me, feel free to push via the x86 tree.
> >
> > Actually, can you wait a bit? Felix just reminded me that we have a
> > similar patch pending from Ben Hutchings:
> >
> > https://patchwork.kernel.org/patch/10808203/
> >
> > And it seems there are two instances of __sw_hweight8, at least in my
> > wireless-drivers-next tree:
> >
> > drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
> > __sw_hweight8(dev->antenna_mask);
> > drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
> > __sw_hweight8(dev->antenna_mask);
> >
> > So we need to think what to do.
>
> I think the best would be that Felix applies Ben's patch to the wireless
> tree and I'll push it to Linus during the next merge window (via
> net-next). Simpler and less conflicts that way.
>
> So Masahiro, could you hold your x86 patch for a while until the mt76
> patch will be in Linus' tree? That should not take more than two weeks,
> I think.
Sure.
I will resend 2/2 later.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH net 0/2] qed: iWARP - fix some syn related issues.
From: David Miller @ 2019-02-19 0:52 UTC (permalink / raw)
To: michal.kalderon; +Cc: ariel.elior, netdev, linux-rdma
In-Reply-To: <20190218132403.12487-1-michal.kalderon@marvell.com>
From: Michal Kalderon <michal.kalderon@marvell.com>
Date: Mon, 18 Feb 2019 15:24:01 +0200
> This series fixes two bugs related to iWARP syn processing flow.
Series applied, thanks.
^ 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