* Re: [PATCH v2 bpf-next] samples/bpf: xdpsock: order memory on AArch64
From: Björn Töpel @ 2018-07-26 12:18 UTC (permalink / raw)
To: Brian Brooks
Cc: ast, Daniel Borkmann, Björn Töpel, Karlsson, Magnus,
Netdev, LKML
In-Reply-To: <20180725210819.1458-1-brian.brooks@linaro.org>
Den ons 25 juli 2018 kl 23:09 skrev Brian Brooks <brian.brooks@linaro.org>:
>
> Define u_smp_rmb() and u_smp_wmb() to respective barrier instructions.
> This ensures the processor will order accesses to queue indices against
> accesses to queue ring entries.
>
Thanks Brian!
Acked-by: Björn Töpel <bjorn.topel@intel.com>
> Signed-off-by: Brian Brooks <brian.brooks@linaro.org>
> ---
> samples/bpf/xdpsock_user.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
> index 5904b1543831..1e82f7c617c3 100644
> --- a/samples/bpf/xdpsock_user.c
> +++ b/samples/bpf/xdpsock_user.c
> @@ -145,8 +145,13 @@ static void dump_stats(void);
> } while (0)
>
> #define barrier() __asm__ __volatile__("": : :"memory")
> +#ifdef __aarch64__
> +#define u_smp_rmb() __asm__ __volatile__("dmb ishld": : :"memory")
> +#define u_smp_wmb() __asm__ __volatile__("dmb ishst": : :"memory")
> +#else
> #define u_smp_rmb() barrier()
> #define u_smp_wmb() barrier()
> +#endif
> #define likely(x) __builtin_expect(!!(x), 1)
> #define unlikely(x) __builtin_expect(!!(x), 0)
>
> --
> 2.18.0
>
^ permalink raw reply
* [PATCH] NET: stmmac: align DMA stuff to largest cache line length
From: Eugeniy Paltsev @ 2018-07-26 12:05 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, linux-snps-arc, David S . Miller, Jose Abreu,
Alexandre Torgue, Giuseppe Cavallaro, Eugeniy Paltsev
As for today STMMAC_ALIGN macro (which is used to align DMA stuff)
relies on L1 line length (L1_CACHE_BYTES).
This isn't correct in case of system with several cache levels
which might have L1 cache line length smaller than L2 line. This
can lead to sharing one cache line between DMA buffer and other
data, so we can lose this data while invalidate DMA buffer before
DMA transaction.
Fix that by using SMP_CACHE_BYTES instead of L1_CACHE_BYTES for
aligning.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 60f59abab009..ef6a8d39db2f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -53,7 +53,7 @@
#include "dwmac1000.h"
#include "hwif.h"
-#define STMMAC_ALIGN(x) L1_CACHE_ALIGN(x)
+#define STMMAC_ALIGN(x) __ALIGN_KERNEL(x, SMP_CACHE_BYTES)
#define TSO_MAX_BUFF_SIZE (SZ_16K - 1)
/* Module parameters */
--
2.14.4
^ permalink raw reply related
* Re: general protection fault in rds_ib_get_mr
From: Johannes Thumshirn @ 2018-07-26 11:40 UTC (permalink / raw)
To: santosh.shilimkar@oracle.com
Cc: Eric Biggers, linux-rdma, rds-devel, syzbot, davem, linux-kernel,
netdev, syzkaller-bugs
In-Reply-To: <a879fe73-1755-8e4c-6f23-203b8d46a373@oracle.com>
On Tue, Jul 24, 2018 at 08:58:43PM -0700, santosh.shilimkar@oracle.com wrote:
> On 7/6/18 1:11 AM, Johannes Thumshirn wrote:
> > On Thu, Jul 05, 2018 at 09:09:44AM -0700, Santosh Shilimkar wrote:
> > > OK. we will look into it if an interim fix can be made....
> >
> > Thanks a lot.
> >
> Intermediate fix is posted here [1]
>
> Regards,
> Santosh
>
> [1] https://patchwork.ozlabs.org/patch/949010/
Thanks,
Johannes
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: [patch net-next v4 03/12] net: sched: introduce chain object to uapi
From: Jiri Pirko @ 2018-07-26 10:06 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jakub Kicinski, Simon Horman, john.hurley, David Ahern, mlxsw,
sridhar.samudrala
In-Reply-To: <20180726073839.GB2222@nanopsycho>
Thu, Jul 26, 2018 at 09:38:39AM CEST, jiri@resnulli.us wrote:
>Wed, Jul 25, 2018 at 06:40:44PM CEST, xiyou.wangcong@gmail.com wrote:
>>On Tue, Jul 24, 2018 at 11:49 PM Jiri Pirko <jiri@resnulli.us> wrote:
>>>
>>> Wed, Jul 25, 2018 at 01:20:08AM CEST, xiyou.wangcong@gmail.com wrote:
>>> >So, you only send out notification when the last refcnt is gone.
>>> >
>>> >If the chain that is being deleted by a user is still used by an action,
>>> >you return 0 or -EPERM?
>>>
>>> 0 and the chain stays there until the action is removed. Hmm, do you thing
>>> that -EPERM should be returned in that case? The thing is, we have to
>>> flush the chain in order to see the action references are there. We would
>>> have to have 2 ref counters, one for filter, one for actions.
>>> What do you think?
>>
>>_If_ RTM_DELCHAIN does decrease the chain refcnt, then it is
>>broken:
>>
>># tc chain add X... (refcnt == 1)
>># tc action add ... goto chain X (refcnt==2)
>># tc chain del X ... (refcnt== 1)
>># tc chain del X ... (refcnt==0)
>>
>>RTM_DELCHAIN should just test if refcnt is 1, if it is, delete it,
>>otherwise return -EPERM. This is how we handle tc standalone
>>actions, see tcf_idr_delete_index().
>>
>>Yes, you might need two refcnt's here.
>
>Okay. Sounds good. I'm on it.
Actually, I found an issue. The action to "goto chain" might be attached
to a filter in the same chain. That is completely legitimate usage.
When I do:
# tc chain del X
I expect the chain to be flushed and removed. If there is an action
there with "goto" to the same chain, the command should be successful.
However, I don't see any easy way to find out if the chain is referenced
only by actions used by filters in the same chain :/
Thoughts?
^ permalink raw reply
* Re: [PATCH] 9p: fix NULL pointer dereferences
From: Dmitry Vyukov @ 2018-07-26 9:54 UTC (permalink / raw)
To: Dominique Martinet
Cc: Tomas Bortoli, David Miller, v9fs-developer, netdev, LKML,
syzkaller
In-Reply-To: <20180726094849.GA18334@nautica>
On Thu, Jul 26, 2018 at 11:48 AM, Dominique Martinet
<asmadeus@codewreck.org> wrote:
> Dmitry Vyukov wrote on Thu, Jul 26, 2018:
>> > Let's refuse that at much higher level, like v9fs_mount() in
>> > fs/9p/vfs_super.c
>> >
>> > I can't think of any valid reason for dev_name to be NULL, it's the
>> > target IP or virtio handle.
>>
>> But I think trans=fd allows NULL addr today, no?
>
> Ah, right, I read the patch too fast and read unix_create as fd_create,
> I never realized there was a unix_create variant...
>
> fd legitimately doesn't need a name, you are correct.
>
> I'm really curious if anyone ever uses the unix/fd variants for "real"
> stuff though! (not meaning syzbot isn't real, but I have yet to see
> anything take advantage of this, even if I could imagine some fun
> applications by piping the wmii libixp server socket.. and just crashed
> my laptop trying because of the (fixed) trans put bug.. I have yet to
> see anyone actually doing this)
I don't really know any real-world cases, but 9p over fd it looks like
a kind of fuse, so perhaps somebody uses it this way.
Also, fd allows to use something like sctp socket, and if I am not
mistaken, trans=tcp can't even do ipv6 tcp (?).
> On the other hand, virtio, rdma and xen all have the same problem, so
> Thomas, please fix them instead :)
^ permalink raw reply
* [patch net-next] selftests: forwarding: add tests for TC chain get and dump operations
From: Jiri Pirko @ 2018-07-26 9:38 UTC (permalink / raw)
To: netdev
Cc: davem, jhs, xiyou.wangcong, jakub.kicinski, simon.horman,
john.hurley, dsahern, mlxsw, sridhar.samudrala
From: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
tools/testing/selftests/net/forwarding/tc_chains.sh | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/tools/testing/selftests/net/forwarding/tc_chains.sh b/tools/testing/selftests/net/forwarding/tc_chains.sh
index 031e322e28b3..2934fb5ed2a2 100755
--- a/tools/testing/selftests/net/forwarding/tc_chains.sh
+++ b/tools/testing/selftests/net/forwarding/tc_chains.sh
@@ -88,9 +88,30 @@ create_destroy_chain()
tc chain add dev $h2 ingress
check_err $? "Failed to create default chain"
+ output="$(tc -j chain get dev $h2 ingress)"
+ check_err $? "Failed to get default chain"
+
+ echo $output | jq -e ".[] | select(.chain == 0)" &> /dev/null
+ check_err $? "Unexpected output for default chain"
+
tc chain add dev $h2 ingress chain 1
check_err $? "Failed to create chain 1"
+ output="$(tc -j chain get dev $h2 ingress chain 1)"
+ check_err $? "Failed to get chain 1"
+
+ echo $output | jq -e ".[] | select(.chain == 1)" &> /dev/null
+ check_err $? "Unexpected output for chain 1"
+
+ output="$(tc -j chain show dev $h2 ingress)"
+ check_err $? "Failed to dump chains"
+
+ echo $output | jq -e ".[] | select(.chain == 0)" &> /dev/null
+ check_err $? "Can't find default chain in dump"
+
+ echo $output | jq -e ".[] | select(.chain == 1)" &> /dev/null
+ check_err $? "Can't find chain 1 in dump"
+
tc chain del dev $h2 ingress
check_err $? "Failed to destroy default chain"
--
2.14.4
^ permalink raw reply related
* Re: [PATCH] 9p: fix NULL pointer dereferences
From: Dominique Martinet @ 2018-07-26 10:25 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Tomas Bortoli, David Miller, v9fs-developer, netdev, LKML,
syzkaller
In-Reply-To: <CACT4Y+Zk_d_Ea-oM0R4cRsdnXogq4S+MZMLHJiJuYzibUkanfA@mail.gmail.com>
Dmitry Vyukov wrote on Thu, Jul 26, 2018:
> On Thu, Jul 26, 2018 at 11:48 AM, Dominique Martinet
> <asmadeus@codewreck.org> wrote:
> > I'm really curious if anyone ever uses the unix/fd variants for "real"
> > stuff though! (not meaning syzbot isn't real, but I have yet to see
> > anything take advantage of this, even if I could imagine some fun
> > applications by piping the wmii libixp server socket.. and just crashed
> > my laptop trying because of the (fixed) trans put bug.. I have yet to
> > see anyone actually doing this)
>
> I don't really know any real-world cases, but 9p over fd it looks like
> a kind of fuse, so perhaps somebody uses it this way.
I guess, who knows...
> Also, fd allows to use something like sctp socket, and if I am not
> mistaken, trans=tcp can't even do ipv6 tcp (?).
Yeah... I have a server that supposedly supports it (nfs-ganesha) so
it's been on my todo list forever, but frankly I don't know many more
people using tcp either...
I'd like to at least get this done for rdma eventually but we're stuck
with ipv4 for Lustre anyway so this hasn't really been a priority, even
if either of the transports are likely a few lines "fix" to make them
support both protocols.
--
Dominique Martinet
^ permalink raw reply
* [PATCH bpf-next v2] samples/bpf: Add BTF build flags to Makefile
From: Taeung Song @ 2018-07-26 10:13 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov; +Cc: netdev, linux-kernel, Jakub Kicinski
To smoothly test BTF supported binary on samples/bpf,
let samples/bpf/Makefile probe llc, pahole and
llvm-objcopy for BPF support and use them
like tools/testing/selftests/bpf/Makefile
changed from the commit c0fa1b6c3efc ("bpf: btf:
Add BTF tests")
Acked-by: Martin KaFai Lau <kafai@fb.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
---
samples/bpf/Makefile | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 9ea2f7b64869..77f512625b8c 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -195,6 +195,8 @@ HOSTLOADLIBES_xdpsock += -pthread
# make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
LLC ?= llc
CLANG ?= clang
+LLVM_OBJCOPY ?= llvm-objcopy
+BTF_PAHOLE ?= pahole
# Detect that we're cross compiling and use the cross compiler
ifdef CROSS_COMPILE
@@ -202,6 +204,16 @@ HOSTCC = $(CROSS_COMPILE)gcc
CLANG_ARCH_ARGS = -target $(ARCH)
endif
+BTF_LLC_PROBE := $(shell $(LLC) -march=bpf -mattr=help 2>&1 | grep dwarfris)
+BTF_PAHOLE_PROBE := $(shell $(BTF_PAHOLE) --help 2>&1 | grep BTF)
+BTF_OBJCOPY_PROBE := $(shell $(LLVM_OBJCOPY) --help 2>&1 | grep -i 'usage.*llvm')
+
+ifneq ($(and $(BTF_LLC_PROBE),$(BTF_PAHOLE_PROBE),$(BTF_OBJCOPY_PROBE)),)
+ EXTRA_CFLAGS += -g
+ LLC_FLAGS += -mattr=dwarfris
+ DWARF2BTF = y
+endif
+
# Trick to allow make to be run from this directory
all:
$(MAKE) -C ../../ $(CURDIR)/ BPF_SAMPLES_PATH=$(CURDIR)
@@ -260,4 +272,7 @@ $(obj)/%.o: $(src)/%.c
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option $(CLANG_ARCH_ARGS) \
- -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
+ -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf $(LLC_FLAGS) -filetype=obj -o $@
+ifeq ($(DWARF2BTF),y)
+ $(BTF_PAHOLE) -J $@
+endif
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] samples/bpf: Add BTF build flags to Makefile
From: Taeung Song @ 2018-07-26 10:08 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, linux-kernel,
Martin KaFai Lau
In-Reply-To: <20180725181603.69289f5d@cakuba.netronome.com>
On 07/26/2018 10:16 AM, Jakub Kicinski wrote:
> On Thu, 26 Jul 2018 01:30:39 +0900, Taeung Song wrote:
>> To smoothly test BTF supported binary on samples/bpf,
>> let samples/bpf/Makefile probe llc, pahole and
>> llvm-objcopy for BPF support and use them
>> like tools/testing/selftests/bpf/Makefile
>> changed from the commit c0fa1b6c3efc ("bpf: btf:
>> Add BTF tests")
>>
>> Cc: Martin KaFai Lau <kafai@fb.com>
>> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
>> ---
>> samples/bpf/Makefile | 21 ++++++++++++++++++++-
>> 1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 1303af10e54d..e079266360a3 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -191,6 +191,8 @@ HOSTLOADLIBES_xdpsock += -pthread
>> # make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
>> LLC ?= llc
>> CLANG ?= clang
>> +LLVM_OBJCOPY ?= llvm-objcopy
>> +BTF_PAHOLE ?= pahole
>>
>> # Detect that we're cross compiling and use the cross compiler
>> ifdef CROSS_COMPILE
>> @@ -198,6 +200,20 @@ HOSTCC = $(CROSS_COMPILE)gcc
>> CLANG_ARCH_ARGS = -target $(ARCH)
>> endif
>>
>> +BTF_LLC_PROBE := $(shell $(LLC) -march=bpf -mattr=help 2>&1 | grep dwarfris)
>> +BTF_PAHOLE_PROBE := $(shell $(BTF_PAHOLE) --help 2>&1 | grep BTF)
>> +BTF_OBJCOPY_PROBE := $(shell $(LLVM_OBJCOPY) --help 2>&1 | grep -i 'usage.*llvm')
>> +
>> +ifneq ($(BTF_LLC_PROBE),)
>> +ifneq ($(BTF_PAHOLE_PROBE),)
>> +ifneq ($(BTF_OBJCOPY_PROBE),)
>
> Nice patch! FWIW you could consider using $(and ...) here:
>
> ifneq ($(and $(BTF_LLC_PROBE),$(BTF_PAHOLE_PROBE),$(BTF_OBJCOPY_PROBE)),)
>
> https://www.gnu.org/software/make/manual/html_node/Conditional-Functions.html#Conditional-Functions
>
> Not sure it's worth a respin..
>
Hi Jakub,
Thanks for reviewing this.
I also think the conditional functions looks more tidy, will change it!
Thanks,
Taeung
>> + EXTRA_CFLAGS += -g
>> + LLC_FLAGS += -mattr=dwarfris
>> + DWARF2BTF = y
>> +endif
>> +endif
>> +endif
>> +
>> # Trick to allow make to be run from this directory
>> all:
>> $(MAKE) -C ../../ $(CURDIR)/ BPF_SAMPLES_PATH=$(CURDIR)
>> @@ -256,4 +272,7 @@ $(obj)/%.o: $(src)/%.c
>> -Wno-gnu-variable-sized-type-not-at-end \
>> -Wno-address-of-packed-member -Wno-tautological-compare \
>> -Wno-unknown-warning-option $(CLANG_ARCH_ARGS) \
>> - -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
>> + -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf $(LLC_FLAGS) -filetype=obj -o $@
>> +ifeq ($(DWARF2BTF),y)
>> + $(BTF_PAHOLE) -J $@
>> +endif
^ permalink raw reply
* Re: [PATCH] samples/bpf: Add BTF build flags to Makefile
From: Taeung Song @ 2018-07-26 9:54 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, linux-kernel
In-Reply-To: <20180725204538.is5aidet4qwbvlg4@kafai-mbp.dhcp.thefacebook.com>
On 07/26/2018 05:45 AM, Martin KaFai Lau wrote:
> On Wed, Jul 25, 2018 at 01:38:44PM -0700, Martin KaFai Lau wrote:
>> On Thu, Jul 26, 2018 at 01:30:39AM +0900, Taeung Song wrote:
>>> To smoothly test BTF supported binary on samples/bpf,
>>> let samples/bpf/Makefile probe llc, pahole and
>>> llvm-objcopy for BPF support and use them
>>> like tools/testing/selftests/bpf/Makefile
>>> changed from the commit c0fa1b6c3efc ("bpf: btf:
>>> Add BTF tests")
>>>
>>> Cc: Martin KaFai Lau <kafai@fb.com>
>>> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
>> Thanks for the patch. LGTM.
>>
>> Acked-by: Martin KaFai Lau <kafai@fb.com>
> and it should go to bpf-next (Please use the proper tag in the
> Subject, thanks!).
>
Yep, will change it ! :)
Thanks,
Taeung
^ permalink raw reply
* [PATCH] selftests/net: add tls to .gitignore
From: Anders Roxell @ 2018-07-26 9:53 UTC (permalink / raw)
To: davem, shuah, davejwatson
Cc: netdev, linux-kselftest, linux-kernel, Anders Roxell
Add the tls binary to .gitignore
Fixes: 7f657d5bf507 ("selftests: tls: add selftests for TLS sockets")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
tools/testing/selftests/net/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/net/.gitignore b/tools/testing/selftests/net/.gitignore
index 1a0ac3a29ec5..78b24cf76f40 100644
--- a/tools/testing/selftests/net/.gitignore
+++ b/tools/testing/selftests/net/.gitignore
@@ -13,3 +13,4 @@ udpgso
udpgso_bench_rx
udpgso_bench_tx
tcp_inq
+tls
--
2.18.0
^ permalink raw reply related
* Re: [PATCH] 9p: fix NULL pointer dereferences
From: Dominique Martinet @ 2018-07-26 9:48 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Tomas Bortoli, David Miller, v9fs-developer, netdev, LKML,
syzkaller
In-Reply-To: <CACT4Y+ark+0EYSZaOX-qDKpOkyfLgSO9CkidZzx=xkUuhpr65A@mail.gmail.com>
Dmitry Vyukov wrote on Thu, Jul 26, 2018:
> > Let's refuse that at much higher level, like v9fs_mount() in
> > fs/9p/vfs_super.c
> >
> > I can't think of any valid reason for dev_name to be NULL, it's the
> > target IP or virtio handle.
>
> But I think trans=fd allows NULL addr today, no?
Ah, right, I read the patch too fast and read unix_create as fd_create,
I never realized there was a unix_create variant...
fd legitimately doesn't need a name, you are correct.
I'm really curious if anyone ever uses the unix/fd variants for "real"
stuff though! (not meaning syzbot isn't real, but I have yet to see
anything take advantage of this, even if I could imagine some fun
applications by piping the wmii libixp server socket.. and just crashed
my laptop trying because of the (fixed) trans put bug.. I have yet to
see anyone actually doing this)
On the other hand, virtio, rdma and xen all have the same problem, so
Thomas, please fix them instead :)
--
Dominique Martinet
^ permalink raw reply
* Re: net-next boot error
From: Dmitry Vyukov via Virtualization @ 2018-07-26 9:34 UTC (permalink / raw)
To: syzbot
Cc: Michael S. Tsirkin, Marc Zyngier, netdev, Tetsuo Handa,
syzkaller-bugs, LKML, Steven Rostedt, David Miller,
Peter Zijlstra, Jason Baron, Josh Poimboeuf, Paolo Bonzini,
Borislav Petkov, virtualization, Ingo Molnar
In-Reply-To: <000000000000352dc20571e3a0d8@google.com>
On Thu, Jul 26, 2018 at 11:29 AM, syzbot
<syzbot+604f8271211546f5b3c7@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: dc66fe43b7eb rds: send: Fix dead code in rds_sendmsg
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=127874c8400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=f34ce142a9f5f0e8
> dashboard link: https://syzkaller.appspot.com/bug?extid=604f8271211546f5b3c7
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+604f8271211546f5b3c7@syzkaller.appspotmail.com
>
> possible deadlock in static_key_slow_incsd 0:0:1:0: [sda] Attached SCSI disk
> MACsec IEEE 802.1AE
> tun: Universal TUN/TAP device driver, 1.6
>
> ============================================
> WARNING: possible recursive locking detected
+Tetsuo, perhaps this boot lockdep problem then disables lockdep for
actual testing. I think lockdep should respect panic_on_warn.
> 4.18.0-rc6+ #141 Not tainted
> --------------------------------------------
> swapper/0/1 is trying to acquire lock:
> (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at:
> static_key_slow_inc+0x12/0x30 kernel/jump_label.c:124
>
> but task is already holding lock:
> (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: get_online_cpus
> include/linux/cpu.h:126 [inline]
> (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: init_vqs+0xe1a/0x1520
> drivers/net/virtio_net.c:2777
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
> ----
> lock(cpu_hotplug_lock.rw_sem);
> lock(cpu_hotplug_lock.rw_sem);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 3 locks held by swapper/0/1:
> #0: (____ptrval____) (&dev->mutex){....}, at: device_lock
> include/linux/device.h:1134 [inline]
> #0: (____ptrval____) (&dev->mutex){....}, at: __driver_attach+0x15f/0x2f0
> drivers/base/dd.c:820
> #1: (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: get_online_cpus
> include/linux/cpu.h:126 [inline]
> #1: (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at:
> init_vqs+0xe1a/0x1520 drivers/net/virtio_net.c:2777
> #2: (____ptrval____) (xps_map_mutex){+.+.}, at:
> __netif_set_xps_queue+0x243/0x23f0 net/core/dev.c:2278
>
> stack backtrace:
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc6+ #141
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
> check_deadlock kernel/locking/lockdep.c:1809 [inline]
> validate_chain kernel/locking/lockdep.c:2405 [inline]
> __lock_acquire.cold.65+0x1fb/0x486 kernel/locking/lockdep.c:3435
> lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
> percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36 [inline]
> percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> cpus_read_lock+0x43/0xa0 kernel/cpu.c:289
> static_key_slow_inc+0x12/0x30 kernel/jump_label.c:124
> __netif_set_xps_queue+0xaac/0x23f0 net/core/dev.c:2320
> netif_set_xps_queue+0x26/0x30 net/core/dev.c:2455
> virtnet_set_affinity+0x2ba/0x4b0 drivers/net/virtio_net.c:1944
> init_vqs+0xe22/0x1520 drivers/net/virtio_net.c:2778
> virtnet_probe+0x1092/0x2260 drivers/net/virtio_net.c:3016
> virtio_dev_probe+0x592/0x942 drivers/virtio/virtio.c:245
> really_probe drivers/base/dd.c:446 [inline]
> driver_probe_device+0x6ad/0x970 drivers/base/dd.c:588
> __driver_attach+0x28b/0x2f0 drivers/base/dd.c:822
> bus_for_each_dev+0x15d/0x1f0 drivers/base/bus.c:311
> driver_attach+0x3d/0x50 drivers/base/dd.c:841
> bus_add_driver+0x4b2/0x600 drivers/base/bus.c:667
> driver_register+0x1c8/0x320 drivers/base/driver.c:170
> register_virtio_driver+0x79/0xd0 drivers/virtio/virtio.c:296
> virtio_net_driver_init+0x8d/0xc9 drivers/net/virtio_net.c:3209
> do_one_initcall+0x127/0x913 init/main.c:884
> do_initcall_level init/main.c:952 [inline]
> do_initcalls init/main.c:960 [inline]
> do_basic_setup init/main.c:978 [inline]
> kernel_init_freeable+0x49b/0x58e init/main.c:1135
> kernel_init+0x11/0x1b3 init/main.c:1061
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
> vcan: Virtual CAN interface driver
> vxcan: Virtual CAN Tunnel driver
> slcan: serial line CAN interface driver
> slcan: 10 dynamic interface channels.
> CAN device driver interface
> enic: Cisco VIC Ethernet NIC Driver, ver 2.3.0.53
> e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
> e100: Copyright(c) 1999-2006 Intel Corporation
> e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
> e1000: Copyright (c) 1999-2006 Intel Corporation.
> e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
> e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
> sky2: driver version 1.30
> PPP generic driver version 2.4.2
> PPP BSD Compression module registered
> PPP Deflate Compression module registered
> PPP MPPE Compression module registered
> NET: Registered protocol family 24
> PPTP driver version 0.8.5
> mac80211_hwsim: initializing netlink
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
> usbcore: registered new interface driver asix
> usbcore: registered new interface driver ax88179_178a
> usbcore: registered new interface driver cdc_ether
> usbcore: registered new interface driver net1080
> usbcore: registered new interface driver cdc_subset
> usbcore: registered new interface driver zaurus
> usbcore: registered new interface driver cdc_ncm
> aoe: AoE v85 initialised.
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-pci: EHCI PCI platform driver
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> ohci-pci: OHCI PCI platform driver
> uhci_hcd: USB Universal Host Controller Interface driver
> usbcore: registered new interface driver usblp
> usbcore: registered new interface driver usb-storage
> i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
> i8042: Warning: Keylock active
> serio: i8042 KBD port at 0x60,0x64 irq 1
> serio: i8042 AUX port at 0x60,0x64 irq 12
> mousedev: PS/2 mouse device common for all mice
> rtc_cmos 00:00: RTC can wake from S4
> rtc_cmos 00:00: registered as rtc0
> rtc_cmos 00:00: alarms up to one day, 114 bytes nvram
> i2c /dev entries driver
> piix4_smbus 0000:00:01.3: SMBus base address uninitialized - upgrade BIOS or
> use force_addr=0xaddr
> i2c-parport-light: adapter type unspecified
> usbcore: registered new interface driver RobotFuzz Open Source InterFace,
> OSIF
> usbcore: registered new interface driver i2c-tiny-usb
> device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised:
> dm-devel@redhat.com
> device-mapper: raid: Loading target version 1.13.2
> usbcore: registered new interface driver btusb
> usnic_verbs: Cisco VIC (USNIC) Verbs Driver v1.0.3 (December 19, 2013)
> usnic_verbs:usnic_uiom_init:585:
> IOMMU required but not present or enabled. USNIC QPs will not function w/o
> enabling IOMMU
> usnic_verbs:usnic_ib_init:649:
> Unable to initalize umem with err -1
> iscsi: registered transport (iser)
> OPA Virtual Network Driver - v1.0
> hidraw: raw HID events driver (C) Jiri Kosina
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> NET: Registered protocol family 40
> ashmem: initialized
> NET: Registered protocol family 26
> Mirror/redirect action on
> Simple TC action Loaded
> netem: version 1.3
> u32 classifier
> Actions configured
> nf_conntrack_irc: failed to register helpers
> nf_conntrack_sane: failed to register helpers
> nf_conntrack_sip: failed to register helpers
> xt_time: kernel timezone is -0000
> IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
> IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
> IPVS: ipvs loaded.
> IPVS: [rr] scheduler registered.
> IPVS: [wrr] scheduler registered.
> IPVS: [lc] scheduler registered.
> IPVS: [wlc] scheduler registered.
> IPVS: [fo] scheduler registered.
> IPVS: [ovf] scheduler registered.
> IPVS: [lblc] scheduler registered.
> IPVS: [lblcr] scheduler registered.
> IPVS: [dh] scheduler registered.
> IPVS: [sh] scheduler registered.
> IPVS: [mh] scheduler registered.
> IPVS: [sed] scheduler registered.
> IPVS: [nq] scheduler registered.
> IPVS: ftp: loaded support on port[0] = 21
> IPVS: [sip] pe registered.
> ipip: IPv4 and MPLS over IPv4 tunneling driver
> gre: GRE over IPv4 demultiplexor driver
> ip_gre: GRE over IPv4 tunneling driver
> IPv4 over IPsec tunneling driver
> ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
> Initializing XFRM netlink socket
> NET: Registered protocol family 10
> Segment Routing with IPv6
> mip6: Mobile IPv6
> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> ip6_gre: GRE over IPv6 tunneling driver
> bpfilter: Loaded bpfilter_umh pid 2080
> NET: Registered protocol family 15
> Bridge firewalling registered
> can: controller area network core (rev 20170425 abi 9)
> NET: Registered protocol family 29
> can: raw protocol (rev 20170425)
> can: broadcast manager protocol (rev 20170425 t)
> can: netlink gateway (rev 20170425) max_hops=1
> Bluetooth: RFCOMM TTY layer initialized
> Bluetooth: RFCOMM socket layer initialized
> Bluetooth: RFCOMM ver 1.11
> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> Bluetooth: BNEP filters: protocol multicast
> Bluetooth: BNEP socket layer initialized
> Bluetooth: HIDP (Human Interface Emulation) ver 1.2
> Bluetooth: HIDP socket layer initialized
> RPC: Registered rdma transport module.
> RPC: Registered rdma backchannel transport module.
> NET: Registered protocol family 41
> lec:lane_module_init: lec.c: initialized
> mpoa:atm_mpoa_init: mpc.c: initialized
> l2tp_core: L2TP core driver, V2.0
> l2tp_ppp: PPPoL2TP kernel driver, V2.0
> 8021q: 802.1Q VLAN Support v1.8
> input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input2
> DCCP: Activated CCID 2 (TCP-like)
> DCCP: Activated CCID 3 (TCP-Friendly Rate Control)
> sctp: Hash tables configured (bind 64/64)
> tipc: Activated (version 2.0.0)
> NET: Registered protocol family 30
> tipc: Started in single node mode
> NET: Registered protocol family 43
> 9pnet: Installing 9P2000 support
> NET: Registered protocol family 36
> Key type dns_resolver registered
> Key type ceph registered
> libceph: loaded (mon/osd proto 15/24)
> openvswitch: Open vSwitch switching datapath
> mpls_gso: MPLS GSO support
> start plist test
> end plist test
> AVX2 version of gcm_enc/dec engaged.
> AES CTR mode by8 optimization enabled
> sched_clock: Marking stable (4559438359, 0)->(6126385605, -1566947246)
> registered taskstats version 1
> Loading compiled-in X.509 certificates
> zswap: default zpool zbud not available
> zswap: pool creation failed
> Btrfs loaded, crc32c=crc32c-intel
> Key type big_key registered
> Key type encrypted registered
> Magic number: 10:317:168
> console [netcon0] enabled
> netconsole: network logging started
> gtp: GTP module loaded (pdp ctx size 104 bytes)
> rdma_rxe: loaded
> cfg80211: Loading compiled-in X.509 certificates for regulatory database
> cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> platform regulatory.0: Direct firmware load for regulatory.db failed with
> error -2
> cfg80211: failed to load regulatory.db
> ALSA device list:
> #0: Dummy 1
> #1: Loopback 1
> #2: Virtual MIDI Card 1
> input: ImExPS/2 Generic Explorer Mouse as
> /devices/platform/i8042/serio1/input/input4
> md: Waiting for all devices to be available before autodetect
> md: If you don't use raid, use raid=noautodetect
> md: Autodetecting RAID arrays.
> md: autorun ...
> md: ... autorun DONE.
> EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
> VFS: Mounted root (ext4 filesystem) readonly on device 8:1.
> devtmpfs: mounted
> Freeing unused kernel memory: 3900K
> Kernel memory protection disabled.
> SELinux: Disabled at runtime.
> SELinux: Unregistering netfilter hooks
> audit: type=1404 audit(1532588961.277:2): enforcing=0 old_enforcing=0
> auid=4294967295 ses=4294967295 enabled=0 old-enabled=1 lsm=selinux res=1
> stty (2166) used greatest stack depth: 19664 bytes left
> EXT4-fs (sda1): re-mounted. Opts: (null)
> logsave (3615) used greatest stack depth: 17632 bytes left
> random: dd: uninitialized urandom read (512 bytes read)
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in virtnet_receive
> drivers/net/virtio_net.c:1356 [inline]
+virtio maintainers for this one
Probably something very recent.
> BUG: KASAN: slab-out-of-bounds in virtnet_poll+0x111a/0x1226
> drivers/net/virtio_net.c:1421
> Read of size 8 at addr ffff8801cee08ff0 by task ip/3969
>
> CPU: 0 PID: 3969 Comm: ip Not tainted 4.18.0-rc6+ #141
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> virtnet_receive drivers/net/virtio_net.c:1356 [inline]
> virtnet_poll+0x111a/0x1226 drivers/net/virtio_net.c:1421
> napi_poll net/core/dev.c:6214 [inline]
> net_rx_action+0x7a5/0x1920 net/core/dev.c:6280
> __do_softirq+0x2e8/0xb17 kernel/softirq.c:292
> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
> </IRQ>
> do_softirq.part.18+0x155/0x1a0 kernel/softirq.c:336
> do_softirq arch/x86/include/asm/preempt.h:23 [inline]
> __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:189
> local_bh_enable include/linux/bottom_half.h:32 [inline]
> virtnet_napi_enable+0x8c/0xb0 drivers/net/virtio_net.c:1264
> virtnet_open+0x16d/0x4d0 drivers/net/virtio_net.c:1464
> __dev_open+0x26d/0x410 net/core/dev.c:1392
> __dev_change_flags+0x739/0x9c0 net/core/dev.c:7434
> dev_change_flags+0x89/0x150 net/core/dev.c:7503
> do_setlink+0xb16/0x3dd0 net/core/rtnetlink.c:2416
> rtnl_newlink+0x138d/0x1d60 net/core/rtnetlink.c:3029
> rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4705
> netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2447
> rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4723
> netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
> netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1336
> netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1901
> sock_sendmsg_nosec net/socket.c:641 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:651
> ___sys_sendmsg+0x7fd/0x930 net/socket.c:2125
> __sys_sendmsg+0x11d/0x290 net/socket.c:2163
> __do_sys_sendmsg net/socket.c:2172 [inline]
> __se_sys_sendmsg net/socket.c:2170 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2170
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x7f318d594320
> Code: 02 48 83 c8 ff eb 8d 48 8b 05 14 7b 2a 00 f7 da 64 89 10 48 83 c8 ff
> eb c9 90 83 3d d5 d2 2a 00 00 75 10 b8 2e 00 00 00 0f 05 <48> 3d 01 f0 ff ff
> 73 31 c3 48 83 ec 08 e8 5e ba 00 00 48 89 04 24
> RSP: 002b:00007ffd985d8f38 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 00007ffd985dd030 RCX: 00007f318d594320
> RDX: 0000000000000000 RSI: 00007ffd985d8f70 RDI: 0000000000000003
> RBP: 00007ffd985d8f70 R08: 0000000000000000 R09: 000000000000000f
> R10: 0000000000000000 R11: 0000000000000246 R12: 000000005b5973aa
> R13: 0000000000000000 R14: 00000000006395c0 R15: 00007ffd985dd808
>
> Allocated by task 1:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> __do_kmalloc mm/slab.c:3718 [inline]
> __kmalloc+0x14e/0x760 mm/slab.c:3727
> kmalloc_array include/linux/slab.h:635 [inline]
> kcalloc include/linux/slab.h:646 [inline]
> virtnet_alloc_queues drivers/net/virtio_net.c:2731 [inline]
> init_vqs+0x127/0x1520 drivers/net/virtio_net.c:2769
> virtnet_probe+0x1092/0x2260 drivers/net/virtio_net.c:3016
> virtio_dev_probe+0x592/0x942 drivers/virtio/virtio.c:245
> really_probe drivers/base/dd.c:446 [inline]
> driver_probe_device+0x6ad/0x970 drivers/base/dd.c:588
> __driver_attach+0x28b/0x2f0 drivers/base/dd.c:822
> bus_for_each_dev+0x15d/0x1f0 drivers/base/bus.c:311
> driver_attach+0x3d/0x50 drivers/base/dd.c:841
> bus_add_driver+0x4b2/0x600 drivers/base/bus.c:667
> driver_register+0x1c8/0x320 drivers/base/driver.c:170
> register_virtio_driver+0x79/0xd0 drivers/virtio/virtio.c:296
> virtio_net_driver_init+0x8d/0xc9 drivers/net/virtio_net.c:3209
> do_one_initcall+0x127/0x913 init/main.c:884
> do_initcall_level init/main.c:952 [inline]
> do_initcalls init/main.c:960 [inline]
> do_basic_setup init/main.c:978 [inline]
> kernel_init_freeable+0x49b/0x58e init/main.c:1135
> kernel_init+0x11/0x1b3 init/main.c:1061
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>
> Freed by task 0:
> (stack is not available)
>
> The buggy address belongs to the object at ffff8801cee08500
> which belongs to the cache kmalloc-4096 of size 4096
> The buggy address is located 2800 bytes inside of
> 4096-byte region [ffff8801cee08500, ffff8801cee09500)
> The buggy address belongs to the page:
> page:ffffea00073b8200 count:1 mapcount:0 mapping:ffff8801dac00dc0 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffffea00073b7d88 ffffea00073b8288 ffff8801dac00dc0
> raw: 0000000000000000 ffff8801cee08500 0000000100000001 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801cee08e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801cee08f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>
>> ffff8801cee08f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
> ^
> ffff8801cee09000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801cee09080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
> --
> 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/000000000000352dc20571e3a0d8%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH] 9p: fix NULL pointer dereferences
From: Dmitry Vyukov @ 2018-07-26 9:27 UTC (permalink / raw)
To: Dominique Martinet
Cc: Tomas Bortoli, David Miller, v9fs-developer, netdev, LKML,
syzkaller
In-Reply-To: <20180726081727.GA6699@nautica>
On Thu, Jul 26, 2018 at 10:17 AM, Dominique Martinet
<asmadeus@codewreck.org> wrote:
> Tomas Bortoli wrote on Thu, Jul 26, 2018:
>> In p9_fd_create_tcp() and p9_fd_create_unix() it is possible to get
>> a NULL value in the addr parameter. Return -EINVAL in such cases.
>
> Let's refuse that at much higher level, like v9fs_mount() in
> fs/9p/vfs_super.c
>
> I can't think of any valid reason for dev_name to be NULL, it's the
> target IP or virtio handle.
But I think trans=fd allows NULL addr today, no?
^ permalink raw reply
* Re: [PATCH 1/4] docs: bpf: Rename README.rst to index.rst
From: Sergei Shtylyov @ 2018-07-26 7:48 UTC (permalink / raw)
To: Tobin C. Harding
Cc: Jonathan Corbet, Alexei Starovoitov, Daniel Borkmann, linux-doc,
netdev, linux-kernel
In-Reply-To: <20180725222823.GD6067@eros>
On 7/26/2018 1:28 AM, Tobin C. Harding wrote:
>>> Recently bpf/ docs were converted to us RST format. 'README.rst' was
>>
>> s/us/use/?
>
> Thanks for the review Sergei, will fix and re-spin.
Perhaps could be fixed while applying...
>>> created but in order to fit in with the Sphinx build system this file
>>> should be named 'index.rst'. Rename file, fixes to integrate into Sphinx
>>> build system in following patches.
>>>
>>> docs: Rename Documentation/bpf/README.rst to Documentation/bpf/index.rst
>>>
>>> Signed-off-by: Tobin C. Harding <me@tobin.cc>
>> [...]
>>
>> MBR, Sergei
>
> What does MBR stand for please (not master boot record I'm guessing)?
My best regards. :-)
> Tobin
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next v3 1/5] tc/act: user space can't use TC_ACT_REDIRECT directly
From: Jiri Pirko @ 2018-07-26 7:43 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Paolo Abeni, Jamal Hadi Salim, netdev, Cong Wang,
Marcelo Ricardo Leitner, Eyal Birger, David S. Miller,
alexei.starovoitov
In-Reply-To: <15b57fa8-670a-a7a3-a5f5-0685207d054f@iogearbox.net>
Wed, Jul 25, 2018 at 06:29:54PM CEST, daniel@iogearbox.net wrote:
>On 07/25/2018 05:48 PM, Paolo Abeni wrote:
>> On Wed, 2018-07-25 at 15:03 +0200, Jiri Pirko wrote:
>>> Wed, Jul 25, 2018 at 02:54:04PM CEST, pabeni@redhat.com wrote:
>>>> On Wed, 2018-07-25 at 13:56 +0200, Jiri Pirko wrote:
>>>>> Tue, Jul 24, 2018 at 10:06:39PM CEST, pabeni@redhat.com wrote:
>>>>>> Only cls_bpf and act_bpf can safely use such value. If a generic
>>>>>> action is configured by user space to return TC_ACT_REDIRECT,
>>>>>> the usually visible behavior is passing the skb up the stack - as
>>>>>> for unknown action, but, with complex configuration, more random
>>>>>> results can be obtained.
>>>>>>
>>>>>> This patch forcefully converts TC_ACT_REDIRECT to TC_ACT_UNSPEC
>>>>>> at action init time, making the kernel behavior more consistent.
>>>>>>
>>>>>> v1 -> v3: use TC_ACT_UNSPEC instead of a newly definied act value
>>>>>>
>>>>>> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>>>>>> ---
>>>>>> net/sched/act_api.c | 5 +++++
>>>>>> 1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/net/sched/act_api.c b/net/sched/act_api.c
>>>>>> index 148a89ab789b..24b5534967fe 100644
>>>>>> --- a/net/sched/act_api.c
>>>>>> +++ b/net/sched/act_api.c
>>>>>> @@ -895,6 +895,11 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> + if (a->tcfa_action == TC_ACT_REDIRECT) {
>>>>>> + net_warn_ratelimited("TC_ACT_REDIRECT can't be used directly");
>>>>>
>>>>> Can't you push this warning through extack?
>>>>>
>>>>> But, wouldn't it be more appropriate to fail here? User is passing
>>>>> invalid configuration....
>>>>
>>>> Jiri, Jamal, thank you for the feedback.
>>>>
>>>> Please allow me to answer both of you here, since you raised similar
>>>> concers.
>>>>
>>>> I thought about rejecting the action, but that change of behavior could
>>>> break some users, as currently most kind of invalid tcfa_action values
>>>> are simply accepted.
>>>>
>>>> If there is consensus about it, I can simply fail.
>>>
>>> Well it was obviously wrong to expose TC_ACT_REDIRECT to uapi and it
>>> really has no meaning for anyone to use it throughout its whole history.
>
>That claim is completely wrong.
Why? Does addition of TC_ACT_REDIRECT to uapi have any meaning?
>
>>> I would vote for "fail", yet I admit that I am usually alone in opinion
>>> about similar uapi changes :)
>>
>> Since even Jamal suggested the same, unless someone else voice some
>> opposition soon, in v4 I'll opt for rejecting actions using
>> TC_ACT_REDIRECT.
>
>You should probably leave out act_bpf from that rejection as there may be
>a small chance that users could potentially use it as default action.
>
>Thanks,
>Daniel
^ permalink raw reply
* Re: [patch net-next v4 03/12] net: sched: introduce chain object to uapi
From: Jiri Pirko @ 2018-07-26 7:38 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jakub Kicinski, Simon Horman, john.hurley, David Ahern, mlxsw,
sridhar.samudrala
In-Reply-To: <CAM_iQpU8EQ+GDPROek7f12oJJeXB5Jp2sUaBSKP4hPBSLNN1dg@mail.gmail.com>
Wed, Jul 25, 2018 at 06:40:44PM CEST, xiyou.wangcong@gmail.com wrote:
>On Tue, Jul 24, 2018 at 11:49 PM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Wed, Jul 25, 2018 at 01:20:08AM CEST, xiyou.wangcong@gmail.com wrote:
>> >So, you only send out notification when the last refcnt is gone.
>> >
>> >If the chain that is being deleted by a user is still used by an action,
>> >you return 0 or -EPERM?
>>
>> 0 and the chain stays there until the action is removed. Hmm, do you thing
>> that -EPERM should be returned in that case? The thing is, we have to
>> flush the chain in order to see the action references are there. We would
>> have to have 2 ref counters, one for filter, one for actions.
>> What do you think?
>
>_If_ RTM_DELCHAIN does decrease the chain refcnt, then it is
>broken:
>
># tc chain add X... (refcnt == 1)
># tc action add ... goto chain X (refcnt==2)
># tc chain del X ... (refcnt== 1)
># tc chain del X ... (refcnt==0)
>
>RTM_DELCHAIN should just test if refcnt is 1, if it is, delete it,
>otherwise return -EPERM. This is how we handle tc standalone
>actions, see tcf_idr_delete_index().
>
>Yes, you might need two refcnt's here.
Okay. Sounds good. I'm on it.
^ permalink raw reply
* Re: [Query]: DSA Understanding
From: Lad, Prabhakar @ 2018-07-26 7:38 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180725161923.GD16819@lunn.ch>
Hi Andrew,
Thanks for the reply.
On Wed, Jul 25, 2018 at 5:19 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Wed, Jul 25, 2018 at 09:39:50AM +0100, Lad, Prabhakar wrote:
>> Hi,
>>
>> We are trying to integrate a MAC to an external switch as following:
>>
>> +-------------------+ +------------------+
>> | | RGMII | |
>> | +------------+ KSZ9897 +------ 1000baseT MDI ("LAN1")
>> | | PORT 6 | 7-port +------ 1000baseT MDI ("LAN2")
>> | AM572x | | Ethernet +------ 1000baseT MDI ("LAN3")
>> | CPSW |MIImgmt | switch +------ 1000baseT MDI ("LAN4")
>> | +-------------+ +------
>> 1000baseT MDI ("LAN5")
>> | | SPI | |
>> | | | |
>> | | | +------
>> 1000baseT MII ("LAN7")
>> | | | |
>> +------------------+ +------------------+
>
> Please use a fixed size font, otherwise this is unreadable.
>
sorry about that, Ill take care of it henceforth.
>>
>> I have done all the configuration required for the MAC controller and
>> enabled the KSZ driver in the kernel, I can see the following:
>> ~$ ip link show
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>> mode DEFAULT group default qlen 1000
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
>> DOWN mode DEFAULT group default qlen 1000
>
> eth0 is you master device. NO-CARRIER is bad, since that means you
> cannot send/receive from from the switch. Are you using a fixed phy on
> the CPSW? What does your device tree look like?
>
With my earlier post, the dsa was linking to eth0, which is incorrect
as the switch is connected to eth1.
I had to patch the dsa to pickup eth1 instead of eth0.
CPSW can support two ports internally one port is connected to KSZ9031
phy chip which is eth0 and the
other port is connected to KSZ9897 chip eth1, following is the ip link
dump with my patch applied.
~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
DOWN mode DEFAULT group default qlen 1000
link/ether c4:f3:12:08:fe:7e brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 1000
link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
5: lan0@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT group default qlen 1000
link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff
6: lan1@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT group default qlen 1000
link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff
7: lan2@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT group default qlen 1000
link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff
8: lan3@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT group default qlen 1000
link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff
9: lan4@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT group default qlen 1000
link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff
10: lan6@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT group default qlen 1000
link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff
~$
Yes I am using fixed phy on slave1, following is my dts:
ethernet@48484000 {
compatible = "ti,dra7-cpsw", "ti,cpsw";
ti,hwmods = "gmac";
clocks = <0x124 0x125>;
clock-names = "fck", "cpts";
cpdma_channels = <0x8>;
ale_entries = <0x400>;
bd_ram_size = <0x2000>;
mac_control = <0x20>;
slaves = <0x2>;
active_slave = <0x0>;
cpts_clock_mult = <0x784cfe14>;
cpts_clock_shift = <0x1d>;
reg = <0x48484000 0x1000 0x48485200 0x2e00>;
#address-cells = <0x1>;
#size-cells = <0x1>;
ti,no-idle;
interrupts = <0x0 0x14e 0x4 0x0 0x14f 0x4 0x0 0x150 0x4
0x0 0x151 0x4>;
ranges;
syscon = <0x8>;
status = "okay";
pinctrl-names = "default", "sleep";
pinctrl-0 = <0x126 0x127>;
pinctrl-1 = <0x128 0x129>;
dual_emac;
linux,phandle = <0x500>;
phandle = <0x500>;
mdio@48485000 {
compatible = "ti,cpsw-mdio", "ti,davinci_mdio";
#address-cells = <0x1>;
#size-cells = <0x0>;
ti,hwmods = "davinci_mdio";
bus_freq = <0xf4240>;
reg = <0x48485000 0x100>;
status = "okay";
pinctrl-names = "default", "sleep";
pinctrl-0 = <0x12a>;
pinctrl-1 = <0x12b>;
ethernet-phy@1 {
reg = <0x1>;
linux,phandle = <0x12c>;
phandle = <0x12c>;
};
};
slave@48480200 {
mac-address = [00 00 00 00 00 00];
status = "okay";
phy-handle = <0x12c>;
phy-mode = "rgmii";
dual_emac_res_vlan = <0x1>;
};
slave@48480300 {
mac-address = [00 00 00 00 00 00];
status = "okay";
phy-mode = "rgmii";
dual_emac_res_vlan = <0x2>;
linux,phandle = <0xf3>;
phandle = <0xf3>;
fixed-link {
speed = <0x3e8>;
full-duplex;
};
};
cpsw-phy-sel@4a002554 {
compatible = "ti,dra7xx-cpsw-phy-sel";
reg = <0x4a002554 0x4>;
reg-names = "gmii-sel";
};
};
spi@480ba000 {
compatible = "ti,omap4-mcspi";
reg = <0x480ba000 0x200>;
interrupts = <0x0 0x2b 0x4>;
#address-cells = <0x1>;
#size-cells = <0x0>;
ti,hwmods = "mcspi4";
ti,spi-num-cs = <0x1>;
dmas = <0xb2 0x46 0xb2 0x47>;
dma-names = "tx0", "rx0";
status = "okay";
ti,pindir-d0-out-d1-in;
ksz9477@0 {
compatible = "microchip,ksz9477";
reg = <0x0>;
spi-max-frequency = <0x2dc6c00>;
spi-cpha;
spi-cpol;
ports {
#address-cells = <0x1>;
#size-cells = <0x0>;
port@0 {
reg = <0x0>;
label = "lan0";
};
port@1 {
reg = <0x1>;
label = "lan1";
};
port@2 {
reg = <0x2>;
label = "lan2";
};
port@3 {
reg = <0x3>;
label = "lan3";
};
port@4 {
reg = <0x4>;
label = "lan4";
};
port@5 {
reg = <0x5>;
label = "cpu";
ethernet = <0x500>;
};
port@6 {
reg = <0x6>;
label = "lan6";
};
};
};
};
Where port 6 of ksz9897 chip is connected to slave 1 (eth1) of cpsw
via rgmii interface. Following is the dmesg log:
[ 2.596958] Microchip KSZ9477 dsa-0.0:00: attached PHY driver
[Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:00, irq=POLL)
[ 2.714959] Microchip KSZ9477 dsa-0.0:01: attached PHY driver
[Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:01, irq=POLL)
[ 2.832958] Microchip KSZ9477 dsa-0.0:02: attached PHY driver
[Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:02, irq=POLL)
[ 2.950960] Microchip KSZ9477 dsa-0.0:03: attached PHY driver
[Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:03, irq=POLL)
[ 3.068958] Microchip KSZ9477 dsa-0.0:04: attached PHY driver
[Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:04, irq=POLL)
[ 3.080953] Generic PHY dsa-0.0:06: attached PHY driver [Generic
PHY] (mii_bus:phy_addr=dsa-0.0:06, irq=POLL)
Cheers,
--Prabhakar
^ permalink raw reply
* Re: [PATCH 00/18] xfrm: Add compat layer
From: Florian Westphal @ 2018-07-26 8:49 UTC (permalink / raw)
To: Dmitry Safonov
Cc: linux-kernel, David S. Miller, Herbert Xu, Steffen Klassert,
Dmitry Safonov, netdev, Andy Lutomirski, Ard Biesheuvel,
H. Peter Anvin, Ingo Molnar, John Stultz, Kirill A. Shutemov,
Oleg Nesterov, Stephen Boyd, Steven Rostedt, Thomas Gleixner, x86,
linux-efi, Andrew Morton, Greg Kroah-Hartman, Mauro
In-Reply-To: <20180726023144.31066-1-dima@arista.com>
Dmitry Safonov <dima@arista.com> wrote:
> So, here I add a compatible layer to xfrm.
> As xfrm uses netlink notifications, kernel should send them in ABI
> format that an application will parse. The proposed solution is
> to save the ABI of bind() syscall. The realization detail is
> to create kernel-hidden, non visible to userspace netlink groups
> for compat applications.
Why not use exisiting netlink support?
Just add the 32bit skb to skb64->frag_list and let
netlink find if tasks needs 64 or 32 one.
It only needs this small fix to properly signal the end of a dump:
https://marc.info/?l=linux-netdev&m=126625240303351&w=2
I had started a second attempt to make xfrm compat work,
but its still in early stage.
One link that might still have some value:
https://git.breakpoint.cc/cgit/fw/net-next.git/commit/?h=xfrm_config_compat_07&id=f64430e6d9e297f3990f485a4832e273751b9869
(compat structure definitions with BUILD_BUG_ON checking)
My plan was to make xfrm compat work strictly as shrinker (64->32)
and expander (32->64), i.e. no/little changes to exisiting code and
pass all "expanded" skbs through existing xfrm rcv functions.
Example to illustrate idea:
https://git.breakpoint.cc/cgit/fw/net-next.git/commit/?h=xfrm_config_compat_07&id=c622f067849b02170127b69471cb3481e4bc9e49
... its supposed to take 64bit skb and create a 32bit one from it.
Just for reference; I currently don't plan to work on this again.
^ permalink raw reply
* Re: [BUG BISECT] NFSv4 client fails on Flush Journal to Persistent Storage
From: Krzysztof Kozlowski @ 2018-07-26 8:46 UTC (permalink / raw)
To: Chuck Lever
Cc: Trond Myklebust, sudeep.holla@arm.com, Trond Myklebust,
Anna Schumaker, Bruce Fields, Jeff Layton, David S. Miller,
Linux NFS Mailing List, netdev, linux-kernel,
linux-samsung-soc@vger.kernel.org
In-Reply-To: <9B9E1627-AC2E-4A0C-AB6E-5815876A59AB@oracle.com>
On 25 July 2018 at 16:31, Chuck Lever <chuck.lever@oracle.com> wrote:
>
>
>> On Jul 25, 2018, at 9:27 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 18 June 2018 at 18:20, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>
>>> The extra serialization appears to have a reproducible performance
>>> impact on RDMA, which no longer takes the reserve_lock when allocating
>>> a slot.
>>>
>>> I could put an xprt_alloc_xid call in xprt_alloc_slot, but that would
>>> only work for socket-based transports. Would it be OK if RDMA had its
>>> own XID allocation mechanism?
>>
>> Hi,
>>
>> On recent next the issue appeared again. My boards with NFSv4 root
>> timeout on 80% of boots. This time my NFS server is faster - Pi3 B+
>> :).
>>
>> Is this know? Should I start long bisect or maybe you can point me to
>> possible causes?
>
> Hi Krzysztof, I don't know of any recent changes. Bisecting would be
> a good place to start.
Hi,
That was my mistake because of missing part of NFS server
configuration on new board. I tested again recent releases and current
linux-next and everything works fine.
Sorry for the noise.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink
From: Jiri Pirko @ 2018-07-26 7:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Alexander Duyck, Eran Ben Elisha, Saeed Mahameed, David S. Miller,
netdev@vger.kernel.org
In-Reply-To: <20180725174359.6952c937@cakuba.netronome.com>
Thu, Jul 26, 2018 at 02:43:59AM CEST, jakub.kicinski@netronome.com wrote:
>On Wed, 25 Jul 2018 08:23:26 -0700, Alexander Duyck wrote:
>> On Wed, Jul 25, 2018 at 5:31 AM, Eran Ben Elisha wrote:
>> > On 7/24/2018 10:51 PM, Jakub Kicinski wrote:
>> >>>> The devlink params haven't been upstream even for a full cycle and
>> >>>> already you guys are starting to use them to configure standard
>> >>>> features like queuing.
>> >>>
>> >>> We developed the devlink params in order to support non-standard
>> >>> configuration only. And for non-standard, there are generic and vendor
>> >>> specific options.
>> >>
>> >> I thought it was developed for performing non-standard and possibly
>> >> vendor specific configuration. Look at DEVLINK_PARAM_GENERIC_* for
>> >> examples of well justified generic options for which we have no
>> >> other API. The vendor mlx4 options look fairly vendor specific if you
>> >> ask me, too.
>> >>
>> >> Configuring queuing has an API. The question is it acceptable to enter
>> >> into the risky territory of controlling offloads via devlink parameters
>> >> or would we rather make vendors take the time and effort to model
>> >> things to (a subset) of existing APIs. The HW never fits the APIs
>> >> perfectly.
>> >
>> > I understand what you meant here, I would like to highlight that this
>> > mechanism was not meant to handle SRIOV, Representors, etc.
>> > The vendor specific configuration suggested here is to handle a congestion
>> > state in Multi Host environment (which includes PF and multiple VFs per
>> > host), where one host is not aware to the other hosts, and each is running
>> > on its own pci/driver. It is a device working mode configuration.
>> >
>> > This couldn't fit into any existing API, thus creating this vendor specific
>> > unique API is needed.
>>
>> If we are just going to start creating devlink interfaces in for every
>> one-off option a device wants to add why did we even bother with
>> trying to prevent drivers from using sysfs? This just feels like we
>> are back to the same arguments we had back in the day with it.
>>
>> I feel like the bigger question here is if devlink is how we are going
>> to deal with all PCIe related features going forward, or should we
>> start looking at creating a new interface/tool for PCI/PCIe related
>> features? My concern is that we have already had features such as DMA
>> Coalescing that didn't really fit into anything and now we are
>> starting to see other things related to DMA and PCIe bus credits. I'm
>> wondering if we shouldn't start looking at a tool/interface to
>> configure all the PCIe related features such as interrupts, error
>> reporting, DMA configuration, power management, etc. Maybe we could
>> even look at sharing it across subsystems and include things like
>> storage, graphics, and other subsystems in the conversation.
>
>Agreed, for actual PCIe configuration (i.e. not ECN marking) we do need
>to build up an API. Sharing it across subsystems would be very cool!
I wonder howcome there isn't such API in place already. Or is it?
If it is not, do you have any idea how should it look like? Should it be
an extension of the existing PCI uapi or something completely new?
It would be probably good to loop some PCI people in...
^ permalink raw reply
* [ipsec-next:testing 13/13] net/xfrm/xfrm_interface.c:692:1-3: WARNING: PTR_ERR_OR_ZERO can be used
From: kbuild test robot @ 2018-07-26 7:09 UTC (permalink / raw)
To: Benedict Wong; +Cc: kbuild-all, netdev, Steffen Klassert
tree: https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git testing
head: 44e2b838c24d883dae8496dc7b6ddac7956ba53c
commit: 44e2b838c24d883dae8496dc7b6ddac7956ba53c [13/13] xfrm: Return detailed errors from xfrmi_newlink
coccinelle warnings: (new ones prefixed by >>)
>> net/xfrm/xfrm_interface.c:692:1-3: WARNING: PTR_ERR_OR_ZERO can be used
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
* [PATCH] xfrm: fix ptr_ret.cocci warnings
From: kbuild test robot @ 2018-07-26 7:09 UTC (permalink / raw)
To: Benedict Wong; +Cc: kbuild-all, netdev, Steffen Klassert
In-Reply-To: <201807261538.y1P9yjWE%fengguang.wu@intel.com>
From: kbuild test robot <fengguang.wu@intel.com>
net/xfrm/xfrm_interface.c:692:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Fixes: 44e2b838c24d ("xfrm: Return detailed errors from xfrmi_newlink")
CC: Benedict Wong <benedictwong@google.com>
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
xfrm_interface.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/net/xfrm/xfrm_interface.c
+++ b/net/xfrm/xfrm_interface.c
@@ -689,10 +689,7 @@ static int xfrmi_newlink(struct net *src
nla_strlcpy(p->name, tb[IFLA_IFNAME], IFNAMSIZ);
xi = xfrmi_locate(net, p, 1);
- if (IS_ERR(xi))
- return PTR_ERR(xi);
-
- return 0;
+ return PTR_ERR_OR_ZERO(xi);
}
static void xfrmi_dellink(struct net_device *dev, struct list_head *head)
^ permalink raw reply
* Re: [PATCH] 9p: fix NULL pointer dereferences
From: Dominique Martinet @ 2018-07-26 8:17 UTC (permalink / raw)
To: Tomas Bortoli; +Cc: davem, v9fs-developer, netdev, linux-kernel, syzkaller
In-Reply-To: <20180726081049.10527-1-tomasbortoli@gmail.com>
Tomas Bortoli wrote on Thu, Jul 26, 2018:
> In p9_fd_create_tcp() and p9_fd_create_unix() it is possible to get
> a NULL value in the addr parameter. Return -EINVAL in such cases.
Let's refuse that at much higher level, like v9fs_mount() in
fs/9p/vfs_super.c
I can't think of any valid reason for dev_name to be NULL, it's the
target IP or virtio handle.
--
Dominique
^ permalink raw reply
* [PATCH] 9p: fix NULL pointer dereferences
From: Tomas Bortoli @ 2018-07-26 8:10 UTC (permalink / raw)
To: ericvh, rminnich, lucho
Cc: asmadeus, davem, v9fs-developer, netdev, linux-kernel, syzkaller,
Tomas Bortoli
In p9_fd_create_tcp() and p9_fd_create_unix() it is possible to get
a NULL value in the addr parameter. Return -EINVAL in such cases.
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
Reported-by: syzbot+1a262da37d3bead15c39@syzkaller.appspotmail.com
---
net/9p/trans_fd.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 964260265b13..ecfceb659d0c 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -941,6 +941,9 @@ p9_fd_create_tcp(struct p9_client *client, const char *addr, char *args)
struct sockaddr_in sin_server;
struct p9_fd_opts opts;
+ if (addr == NULL)
+ return -EINVAL;
+
err = parse_opts(args, &opts);
if (err < 0)
return err;
@@ -995,6 +998,9 @@ p9_fd_create_unix(struct p9_client *client, const char *addr, char *args)
csocket = NULL;
+ if (addr == NULL)
+ return -EINVAL;
+
if (strlen(addr) >= UNIX_PATH_MAX) {
pr_err("%s (%d): address too long: %s\n",
__func__, task_pid_nr(current), addr);
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox