Re: [PATCH v3 1/1] sched: watchdog: Touch kernel watchdog with sched count

On Mon, Oct 26, 2020 at 1:32 AM Vincent Guittot wrote: > > On Sun, 25 Oct 2020 at 00:57, Xi Wang wrote: > > > > Instead of periodically resetting watchdogs from thread context, > > this patch simply forces resched and checks rq->sched_count. > > Watchdog is r

[PATCH v3 1/1] sched: watchdog: Touch kernel watchdog with sched count

tra Signed-off-by: Xi Wang --- include/linux/sched.h | 4 kernel/sched/core.c | 23 +++-- kernel/sched/sched.h | 6 +- kernel/watchdog.c | 47 +-- 4 files changed, 44 insertions(+), 36 deletions(-) diff --git a/include/li

gFrom 9667d5ddbb1dc230653e5f8cedb778e9c562d46c Mon Sep 17 00:00:00 2001

ill need to check resched v2: - Use sched_count instead of having sched calling into watchdog code - Remove the sysctl and add a boot option, which can be removed later - Changed the subject line Xi Wang (1): sched: watchdog: Touch kernel watchdog with sched count include/linux/sched.h |

Re: [PATCH v2 1/1] sched: watchdog: Touch kernel watchdog with sched count

On Wed, Oct 21, 2020 at 3:13 AM Peter Zijlstra wrote: > > On Tue, Oct 20, 2020 at 01:57:04PM -0700, Xi Wang wrote: > > > + if (watchdog_touch_with_sched) { > > + /* Trigger reschedule for the next round */ > > + s

[PATCH v2 0/1] Touch kernel watchdog with sched count

ctl and add a boot option, which can be removed later - Changed the subject line Xi Wang (1): sched: watchdog: Touch kernel watchdog with sched count include/linux/sched.h | 4 kernel/sched/core.c | 23 -- kernel/sched/sched.h | 6 +- kernel/watchdo

[PATCH v2 1/1] sched: watchdog: Touch kernel watchdog with sched count

vel of protection with less overhead. With this patch we can still switch back to the old method with the boot option watchdog_touch_with_thread. However code for the old method can be completely removed in the future. Suggested-by: Paul Turner Suggested-by: Peter Zijlstra Signed-off-by: Xi Wang --- incl

Re: [PATCH] sched: watchdog: Touch kernel watchdog in sched code

On Mon, Oct 5, 2020 at 4:19 AM Peter Zijlstra wrote: > > On Fri, Mar 06, 2020 at 02:34:20PM -0800, Xi Wang wrote: > > On Fri, Mar 6, 2020 at 12:40 AM Peter Zijlstra wrote: > > > > > > On Thu, Mar 05, 2020 at 02:11:49PM -0800, Paul Turner wrote: > > > >

Re: [PATCH] arm64: bpf: Fix branch offset in JIT

On Mon, Sep 14, 2020 at 11:28 AM Ilias Apalodimas wrote: > Even if that's true, is any reason at all why we should skip the first element > of the array, that's now needed since 7c2e988f400 to jump back to the first > instruction? > Introducing 2 extra if conditions and hotfix the array on the

Re: [PATCH] arm64: bpf: Fix branch offset in JIT

On Mon, Sep 14, 2020 at 10:55 AM Ilias Apalodimas wrote: > We've briefly discussed this approach with Yauheni while coming up with the > posted patch. > I think that contructing the array correctly in the first place is better. > Right now it might only be used in bpf2a64_offset() and >

Re: [PATCH] arm64: bpf: Fix branch offset in JIT

On Mon, Sep 14, 2020 at 10:03 AM Ilias Apalodimas wrote: > Naresh from Linaro reported it during his tests on 5.8-rc1 as well [1]. > I've included both Jiri and him on the v2 as reporters. > > [1] https://lkml.org/lkml/2020/8/11/58 I'm curious what you think of Luke's earlier patch to this bug:

Re: [PATCH] sched: Make select_idle_sibling search domain configurable

On Tue, Jul 28, 2020 at 10:54 AM Xi Wang wrote: > > On Tue, Jul 28, 2020 at 3:39 AM wrote: > > > > On Tue, Jul 28, 2020 at 12:01:31AM -0700, Xi Wang wrote: > > > The scope of select_idle_sibling idle cpu search is LLC. This > > > becomes a problem for the

Re: [PATCH] sched: Make select_idle_sibling search domain configurable

On Tue, Jul 28, 2020 at 3:39 AM wrote: > > On Tue, Jul 28, 2020 at 12:01:31AM -0700, Xi Wang wrote: > > The scope of select_idle_sibling idle cpu search is LLC. This > > becomes a problem for the AMD CCX architecture, as the sd_llc is only > > 4 cores. On a many core mach

[PATCH] sched: Make select_idle_sibling search domain configurable

and sds->have_idle_cores are only active for the main search. On a 128 core (2 socket * 64 core, 256 hw threads) AMD machine ran hackbench as hackbench -g 20 -f 20 --loops 1 A snapshot of run time was Baseline: 11.8 With the patch: 7.6(configured as in the example above) Signed-

Re: [PATCH bpf-next] bpf, riscv: Fix stack layout of JITed code on RV32

13.063704 ] [] __do_sys_bpf+0x766/0x13b4 > [ 13.063840 ] [] sys_bpf+0xc/0x14 > [ 13.063961 ] [] ret_from_syscall+0x0/0x2 > > The new code is also simpler to understand and includes an ASCII diagram > of the stack layout. > > Tested on riscv32 QEMU virt machine. > > Signed-off-by: Luke Nelson Thanks for the fix! Acked-by: Xi Wang

Re: [PATCH] bpf: add mod default A and X test cases

On Wed, Nov 4, 2015 at 11:36 AM, Yang Shi wrote: > When running "mod X" operation, if X is 0 the filter has to be halt. > Add new test cases to cover A = A mod X if X is 0, and A = A mod 1. > > CC: Xi Wang > CC: Zi Shen Lim > Signed-off-by: Yang Shi Acked-by: Xi

Re: [PATCH] bpf: add mod default A and X test cases

On Wed, Nov 4, 2015 at 11:36 AM, Yang Shi <yang@linaro.org> wrote: > When running "mod X" operation, if X is 0 the filter has to be halt. > Add new test cases to cover A = A mod X if X is 0, and A = A mod 1. > > CC: Xi Wang <xi.w...@gmail.com> > CC: Zi S

Re: [PATCH] arm64: bpf: fix div-by-zero case

On Tue, Nov 3, 2015 at 10:56 PM, Zi Shen Lim wrote: > case BPF_ALU | BPF_DIV | BPF_X: > case BPF_ALU64 | BPF_DIV | BPF_X: > + { > + const u8 r0 = bpf2a64[BPF_REG_0]; > + > + /* if (src == 0) return 0 */ > + jmp_offset = 3; /* skip

Re: [PATCH] arm64: bpf: fix div-by-zero case

On Tue, Nov 3, 2015 at 10:56 PM, Zi Shen Lim wrote: > case BPF_ALU | BPF_DIV | BPF_X: > case BPF_ALU64 | BPF_DIV | BPF_X: > + { > + const u8 r0 = bpf2a64[BPF_REG_0]; > + > + /* if (src == 0) return 0 */ > +

[PATCH net-next] test_bpf: extend tests for 32-bit endianness conversion

Currently "ALU_END_FROM_BE 32" and "ALU_END_FROM_LE 32" do not test if the upper bits of the result are zeros (the arm64 JIT had such bugs). Extend the two tests to catch this. Cc: Alexei Starovoitov Signed-off-by: Xi Wang --- See the arm64 JIT bugs: https://lkml.or

[PATCH net-next] test_bpf: extend tests for 32-bit endianness conversion

Currently ALU_END_FROM_BE 32 and ALU_END_FROM_LE 32 do not test if the upper bits of the result are zeros (the arm64 JIT had such bugs). Extend the two tests to catch this. Cc: Alexei Starovoitov a...@plumgrid.com Signed-off-by: Xi Wang xi.w...@gmail.com --- See the arm64 JIT bugs: https

[RFC PATCH] arm64: bpf: fix endianness conversion bugs

Starovoitov Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler") Signed-off-by: Xi Wang --- The current testsuite catches the 16-bit bugs. I'll send a separate patch that extends test_bpf to catch the 32-bit ones. --- arch/arm64/net/bpf_jit.h | 4 arch/arm64/net/bpf_jit_c

[PATCH] arm64: bpf: fix out-of-bounds read in bpf2a64_offset()

, leading to a bogus jump offset and kernel panic. This patch moves updating ctx->offset to after calling build_insn(), and changes indexing to use bpf_to and bpf_from without + 1. Cc: Zi Shen Lim Cc: Alexei Starovoitov Cc: Will Deacon Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler&qu

[PATCH] arm64: bpf: fix out-of-bounds read in bpf2a64_offset()

compiler) Signed-off-by: Xi Wang xi.w...@gmail.com --- arch/arm64/net/bpf_jit_comp.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c index dc6a484..c81ddd4 100644 --- a/arch/arm64/net/bpf_jit_comp.c +++ b/arch

[RFC PATCH] arm64: bpf: fix endianness conversion bugs

@gmail.com Cc: Alexei Starovoitov a...@plumgrid.com Fixes: e54bcde3d69d (arm64: eBPF JIT compiler) Signed-off-by: Xi Wang xi.w...@gmail.com --- The current testsuite catches the 16-bit bugs. I'll send a separate patch that extends test_bpf to catch the 32-bit ones. --- arch/arm64/net/bpf_jit.h

[PATCH net-next] test: bpf: extend "load 64-bit immediate" testcase

-by: Xi Wang --- lib/test_bpf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/test_bpf.c b/lib/test_bpf.c index f2c23ffaa6d7..3c41049d72d8 100644 --- a/lib/test_bpf.c +++ b/lib/test_bpf.c @@ -1755,7 +1755,8 @@ static struct bpf_test tests

[PATCH net-next] test: bpf: extend load 64-bit immediate testcase

will.dea...@arm.com Signed-off-by: Xi Wang xi.w...@gmail.com --- lib/test_bpf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/test_bpf.c b/lib/test_bpf.c index f2c23ffaa6d7..3c41049d72d8 100644 --- a/lib/test_bpf.c +++ b/lib/test_bpf.c @@ -1755,7 +1755,8 @@ static struct

Re: [PATCH] arm64: bpf: fix signedness bug in loading 64-bit immediate

On Fri, May 8, 2015 at 1:38 AM, Will Deacon wrote: >> - imm64 = (u64)insn1.imm << 32 | imm; >> + imm64 = ((u64)(u32)insn1.imm) << 32 | (u64)(u32)imm; > > This seems a bit convoluted to me. Don't you just need to add a (u32) > cast to imm and that's it? The (u64)(u32) looks

Re: [PATCH] arm64: bpf: fix signedness bug in loading 64-bit immediate

On Fri, May 8, 2015 at 1:38 AM, Will Deacon will.dea...@arm.com wrote: - imm64 = (u64)insn1.imm 32 | imm; + imm64 = ((u64)(u32)insn1.imm) 32 | (u64)(u32)imm; This seems a bit convoluted to me. Don't you just need to add a (u32) cast to imm and that's it? The

[PATCH] arm64: bpf: fix signedness bug in loading 64-bit immediate

Before: test_bpf: #58 load 64-bit immediate ret -1 != 1 FAIL (1 times) After: test_bpf: #58 load 64-bit immediate 74 PASS Fixes: 30d3d94cc3d5 ("arm64: bpf: add 'load 64-bit immediate' instruction") Cc: Zi Shen Lim Cc: Alexei Starovoitov Cc: Catalin Marinas Cc: Will Deacon Signed-

[PATCH] arm64: bpf: fix signedness bug in loading 64-bit immediate

: Will Deacon will.dea...@arm.com Signed-off-by: Xi Wang xi.w...@gmail.com --- arch/arm64/net/bpf_jit_comp.c | 2 +- lib/test_bpf.c| 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c index edba042b2325

[PATCH v3 -next 2/2] x86: bpf_jit_comp: optimize BPF_S_ANC_SECCOMP_LD_W

This patch further optimizes JIT for seccomp filters. It removes the call to seccomp_bpf_load() and directly emits instructions instead. Signed-off-by: Xi Wang Cc: Daniel Borkmann Cc: Heiko Carstens Cc: Will Drewry Cc: Eric Dumazet Cc: Russell King Cc: David Laight Cc: "David S. M

[PATCH v3 -next 1/2] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W

This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction in x86 JIT, by simply calling seccomp_bpf_load(). SEEN_SKBREF was suggested by Eric Dumazet. SEEN_SKBREF shouldn't be set in seccomp filters. Signed-off-by: Xi Wang Cc: Daniel Borkmann Cc: Heiko Carstens Cc: Will Drewry Cc

[PATCH v3 -next 0/2] seccomp filter JIT for x86

s way harder to maintain compared to 1/2. I'm posting it here for completeness, but I'd suggest to consider patch 1/2 only for now. Xi Wang (2): x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W x86: bpf_jit_comp: optimize BPF_S_ANC_SECCOMP_LD_W arch/x86/Kconfig|

[PATCH v3 -next 0/2] seccomp filter JIT for x86

posting it here for completeness, but I'd suggest to consider patch 1/2 only for now. Xi Wang (2): x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W x86: bpf_jit_comp: optimize BPF_S_ANC_SECCOMP_LD_W arch/x86/Kconfig| 1 + arch/x86/net/bpf_jit_comp.c | 220

[PATCH v3 -next 2/2] x86: bpf_jit_comp: optimize BPF_S_ANC_SECCOMP_LD_W

This patch further optimizes JIT for seccomp filters. It removes the call to seccomp_bpf_load() and directly emits instructions instead. Signed-off-by: Xi Wang xi.w...@gmail.com Cc: Daniel Borkmann dbork...@redhat.com Cc: Heiko Carstens heiko.carst...@de.ibm.com Cc: Will Drewry w...@chromium.org

[PATCH v3 -next 1/2] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W

This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction in x86 JIT, by simply calling seccomp_bpf_load(). SEEN_SKBREF was suggested by Eric Dumazet. SEEN_SKBREF shouldn't be set in seccomp filters. Signed-off-by: Xi Wang xi.w...@gmail.com Cc: Daniel Borkmann dbork...@redhat.com Cc

Re: [PATCH v2 net-next 2/3] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

On Sat, Apr 27, 2013 at 9:21 PM, Eric Dumazet wrote: > I would feel more comfortable if you added : > > if (seen & SEEN_DATAREF) { > pr_err_once("SECCOMP_LD_W assertion failed\n"): > goto out; > } > > This way, if BPF is changed in the future, but

Re: [PATCH v2 net-next 2/3] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

On Sat, Apr 27, 2013 at 9:21 PM, Eric Dumazet eric.duma...@gmail.com wrote: I would feel more comfortable if you added : if (seen SEEN_DATAREF) { pr_err_once(SECCOMP_LD_W assertion failed\n): goto out; } This way, if BPF is changed in the

Re: [PATCH v2 net-next 3/3] ARM: net: bpf_jit_32: support BPF_S_ANC_SECCOMP_LD_W instruction

On Sat, Apr 27, 2013 at 2:27 AM, Daniel Borkmann wrote: > Arent't you doing here a similar thing in terms of getting arch as Eric > criticized (Nicolas' implementation does not use that part btw.)? Also, > even if it would be possible here, now your 2 JIT implementations differ > in behaviour. I

Re: [PATCH v2 net-next 3/3] ARM: net: bpf_jit_32: support BPF_S_ANC_SECCOMP_LD_W instruction

On Sat, Apr 27, 2013 at 2:27 AM, Daniel Borkmann dbork...@redhat.com wrote: Arent't you doing here a similar thing in terms of getting arch as Eric criticized (Nicolas' implementation does not use that part btw.)? Also, even if it would be possible here, now your 2 JIT implementations differ

[PATCH v2 net-next 2/3] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction in x86 JIT. Signed-off-by: Xi Wang Cc: Daniel Borkmann Cc: Heiko Carstens Cc: Will Drewry Cc: Eric Dumazet Cc: Russell King Cc: David Laight Cc: "David S. Miller" Cc: Andrew Morton Cc: Nicolas Schichan ---

[PATCH v2 net-next 3/3] ARM: net: bpf_jit_32: support BPF_S_ANC_SECCOMP_LD_W instruction

This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction in ARM JIT. Signed-off-by: Xi Wang Cc: Daniel Borkmann Cc: Heiko Carstens Cc: Will Drewry Cc: Eric Dumazet Cc: Russell King Cc: David Laight Cc: "David S. Miller" Cc: Andrew Morton Cc: Nicolas Schichan ---

[PATCH v2 net-next 1/3] filter: refactor BPF JIT for seccomp filters

for seccomp filters. Signed-off-by: Xi Wang Cc: Daniel Borkmann Cc: Heiko Carstens Cc: Will Drewry Cc: Eric Dumazet Cc: Russell King Cc: David Laight Cc: "David S. Miller" Cc: Andrew Morton Cc: Nicolas Schichan --- arch/arm/net/bpf_jit_32.c

[PATCH v2 net-next 0/3] seccomp filter JIT

for the comments on x86 JIT. Changes: make better patch splitting remove arch at jit time in x86 add more comments in x86 Xi Wang (3): filter: refactor BPF JIT for seccomp filters x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction ARM: net: bpf_jit_32: support BPF_S_ANC_SECCOMP_LD_W

Re: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent on struct sk_filter.

Thanks for CCing. One way to clean up this would be to refactor the bpf jit interface as: bpf_func_t bpf_jit_compile(struct sock_filter *filter, unsigned int flen); void bpf_jit_free(bpf_func_t bpf_func); Then both packet and seccomp filters can share the unified interface. Also, we don't

Re: [RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

ters; it's safe to not save them." - xi On Fri, Apr 26, 2013 at 12:14 PM, Eric Dumazet wrote: > On Fri, 2013-04-26 at 12:02 -0400, Xi Wang wrote: >> On Fri, Apr 26, 2013 at 11:11 AM, Eric Dumazet >> wrote: >> > 1) 'current' at the time the code is jitted (com

Re: [RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

On Fri, Apr 26, 2013 at 11:11 AM, Eric Dumazet wrote: > 1) 'current' at the time the code is jitted (compiled) is not the > 'current' at the time the filter will be evaluated. > > On x86_64, if CONFIG_IA32_EMULATION=y, syscall_get_arch() evaluates to : > > if (task_thread_info(task)->status &

Re: [RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

On Fri, Apr 26, 2013 at 11:43 AM, Eric Dumazet wrote: > I do not know. > > This is not explained in your changelog or in any comment. > > You have to make the full analysis yourself and make us comfortable with > the results. > > You send patches and ask us to spend hours on it, this is not how

Re: [RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

On Fri, Apr 26, 2013 at 11:11 AM, Eric Dumazet wrote: > 2) Calling a function potentially destroys some registers. >%rdi,%r8,%r9 for instance, so we are going to crash very easily. > > I dont know, I feel a bit uncomfortable having to explain this to > someone sending security related

Re: [RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

On Fri, Apr 26, 2013 at 10:18 AM, Eric Dumazet wrote: > On Fri, 2013-04-26 at 03:51 -0400, Xi Wang wrote: > >> +#ifdef CONFIG_SECCOMP_FILTER >> + case BPF_S_ANC_SECCOMP_LD_W: >> + if (K == offsetof(s

Re: [RFC PATCH net-next 0/6] seccomp filter JIT

On Fri, Apr 26, 2013 at 7:46 AM, Daniel Borkmann wrote: > I think BPF JIT for seccomp on ARM recently got applied to -mm tree > if I'm not mistaken. It was from Nicolas Schichan (cc): > > http://thread.gmane.org/gmane.linux.ports.arm.kernel/233416/ Thanks for the pointer. For the ARM part,

Re: [RFC PATCH net-next 0/6] seccomp filter JIT

On Fri, Apr 26, 2013 at 7:46 AM, Heiko Carstens wrote: > And build fine on s390. Thanks! >> Btw. are there any test cases around for BPF JIT? >> Not only for the new seccomp but also netfilter? > > This however is still a valid question. Not sure about test cases for BPF JIT in general. I

[RFC PATCH net-next 1/6] filter: refactor BPF JIT for seccomp filters

filters. Signed-off-by: Xi Wang --- include/linux/filter.h | 16 ++-- kernel/seccomp.c | 6 +- net/core/filter.c | 6 ++ 3 files changed, 17 insertions(+), 11 deletions(-) diff --git a/include/linux/filter.h b/include/linux/filter.h index d1248f4..8743093 100644

[RFC PATCH net-next 4/6] PPC: net: bpf_jit_comp: refactor the BPF JIT interface

Implement the refactored bpf_jit_compile() and bpf_jit_free(). Signed-off-by: Xi Wang --- arch/powerpc/net/bpf_jit_comp.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c

[RFC PATCH net-next 5/6] sparc: bpf_jit_comp: refactor the BPF JIT interface

Implement the refactored bpf_jit_compile() and bpf_jit_free(). Signed-off-by: Xi Wang --- arch/sparc/net/bpf_jit_comp.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c index d36a85e

[RFC PATCH net-next 3/6] ARM: net: bpf_jit_32: support BPF_S_ANC_SECCOMP_LD_W instruction

This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction in ARM JIT. Signed-off-by: Xi Wang --- arch/arm/net/bpf_jit_32.c | 64 +-- 1 file changed, 39 insertions(+), 25 deletions(-) diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net

[RFC PATCH net-next 6/6] s390/bpf,jit: refactor the BPF JIT interface

Implement the refactored bpf_jit_compile() and bpf_jit_free(). Signed-off-by: Xi Wang --- arch/s390/net/bpf_jit_comp.c | 31 --- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c index 0972e91

[RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction in x86 JIT. Signed-off-by: Xi Wang --- arch/x86/net/bpf_jit_comp.c | 38 ++ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net

[RFC PATCH net-next 0/6] seccomp filter JIT

ronment here. Can someone help check 5/6 and 6/6? Thanks. Xi Wang (6): filter: refactor BPF JIT for seccomp filters x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction ARM: net: bpf_jit_32: support BPF_S_ANC_SECCOMP_LD_W instruction PPC: net: bpf_jit_comp: refactor the BPF JIT inter

[RFC PATCH net-next 0/6] seccomp filter JIT

someone help check 5/6 and 6/6? Thanks. Xi Wang (6): filter: refactor BPF JIT for seccomp filters x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction ARM: net: bpf_jit_32: support BPF_S_ANC_SECCOMP_LD_W instruction PPC: net: bpf_jit_comp: refactor the BPF JIT interface sparc

[RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction in x86 JIT. Signed-off-by: Xi Wang xi.w...@gmail.com --- arch/x86/net/bpf_jit_comp.c | 38 ++ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/arch/x86/net/bpf_jit_comp.c b

[RFC PATCH net-next 6/6] s390/bpf,jit: refactor the BPF JIT interface

Implement the refactored bpf_jit_compile() and bpf_jit_free(). Signed-off-by: Xi Wang xi.w...@gmail.com --- arch/s390/net/bpf_jit_comp.c | 31 --- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net

[RFC PATCH net-next 3/6] ARM: net: bpf_jit_32: support BPF_S_ANC_SECCOMP_LD_W instruction

This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction in ARM JIT. Signed-off-by: Xi Wang xi.w...@gmail.com --- arch/arm/net/bpf_jit_32.c | 64 +-- 1 file changed, 39 insertions(+), 25 deletions(-) diff --git a/arch/arm/net/bpf_jit_32.c

[RFC PATCH net-next 5/6] sparc: bpf_jit_comp: refactor the BPF JIT interface

Implement the refactored bpf_jit_compile() and bpf_jit_free(). Signed-off-by: Xi Wang xi.w...@gmail.com --- arch/sparc/net/bpf_jit_comp.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c

[RFC PATCH net-next 4/6] PPC: net: bpf_jit_comp: refactor the BPF JIT interface

Implement the refactored bpf_jit_compile() and bpf_jit_free(). Signed-off-by: Xi Wang xi.w...@gmail.com --- arch/powerpc/net/bpf_jit_comp.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc

[RFC PATCH net-next 1/6] filter: refactor BPF JIT for seccomp filters

filters. Signed-off-by: Xi Wang xi.w...@gmail.com --- include/linux/filter.h | 16 ++-- kernel/seccomp.c | 6 +- net/core/filter.c | 6 ++ 3 files changed, 17 insertions(+), 11 deletions(-) diff --git a/include/linux/filter.h b/include/linux/filter.h index d1248f4

Re: [RFC PATCH net-next 0/6] seccomp filter JIT

On Fri, Apr 26, 2013 at 7:46 AM, Heiko Carstens heiko.carst...@de.ibm.com wrote: And build fine on s390. Thanks! Btw. are there any test cases around for BPF JIT? Not only for the new seccomp but also netfilter? This however is still a valid question. Not sure about test cases for BPF JIT

Re: [RFC PATCH net-next 0/6] seccomp filter JIT

On Fri, Apr 26, 2013 at 7:46 AM, Daniel Borkmann dbork...@redhat.com wrote: I think BPF JIT for seccomp on ARM recently got applied to -mm tree if I'm not mistaken. It was from Nicolas Schichan (cc): http://thread.gmane.org/gmane.linux.ports.arm.kernel/233416/ Thanks for the pointer. For the

Re: [RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

On Fri, Apr 26, 2013 at 10:18 AM, Eric Dumazet eric.duma...@gmail.com wrote: On Fri, 2013-04-26 at 03:51 -0400, Xi Wang wrote: +#ifdef CONFIG_SECCOMP_FILTER + case BPF_S_ANC_SECCOMP_LD_W: + if (K == offsetof(struct seccomp_data, arch

Re: [RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

On Fri, Apr 26, 2013 at 11:11 AM, Eric Dumazet eric.duma...@gmail.com wrote: 2) Calling a function potentially destroys some registers. %rdi,%r8,%r9 for instance, so we are going to crash very easily. I dont know, I feel a bit uncomfortable having to explain this to someone sending

Re: [RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

On Fri, Apr 26, 2013 at 11:43 AM, Eric Dumazet eric.duma...@gmail.com wrote: I do not know. This is not explained in your changelog or in any comment. You have to make the full analysis yourself and make us comfortable with the results. You send patches and ask us to spend hours on it,

Re: [RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

On Fri, Apr 26, 2013 at 11:11 AM, Eric Dumazet eric.duma...@gmail.com wrote: 1) 'current' at the time the code is jitted (compiled) is not the 'current' at the time the filter will be evaluated. On x86_64, if CONFIG_IA32_EMULATION=y, syscall_get_arch() evaluates to : if

Re: [RFC PATCH net-next 2/6] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

to not save them. - xi On Fri, Apr 26, 2013 at 12:14 PM, Eric Dumazet eric.duma...@gmail.com wrote: On Fri, 2013-04-26 at 12:02 -0400, Xi Wang wrote: On Fri, Apr 26, 2013 at 11:11 AM, Eric Dumazet eric.duma...@gmail.com wrote: 1) 'current' at the time the code is jitted (compiled

Re: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent on struct sk_filter.

Thanks for CCing. One way to clean up this would be to refactor the bpf jit interface as: bpf_func_t bpf_jit_compile(struct sock_filter *filter, unsigned int flen); void bpf_jit_free(bpf_func_t bpf_func); Then both packet and seccomp filters can share the unified interface. Also, we don't

[PATCH v2 net-next 0/3] seccomp filter JIT

for the comments on x86 JIT. Changes: make better patch splitting remove arch at jit time in x86 add more comments in x86 Xi Wang (3): filter: refactor BPF JIT for seccomp filters x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction ARM: net: bpf_jit_32: support BPF_S_ANC_SECCOMP_LD_W

[PATCH v2 net-next 1/3] filter: refactor BPF JIT for seccomp filters

for seccomp filters. Signed-off-by: Xi Wang xi.w...@gmail.com Cc: Daniel Borkmann dbork...@redhat.com Cc: Heiko Carstens heiko.carst...@de.ibm.com Cc: Will Drewry w...@chromium.org Cc: Eric Dumazet eduma...@google.com Cc: Russell King li...@arm.linux.org.uk Cc: David Laight david.lai...@aculab.com Cc

[PATCH v2 net-next 3/3] ARM: net: bpf_jit_32: support BPF_S_ANC_SECCOMP_LD_W instruction

This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction in ARM JIT. Signed-off-by: Xi Wang xi.w...@gmail.com Cc: Daniel Borkmann dbork...@redhat.com Cc: Heiko Carstens heiko.carst...@de.ibm.com Cc: Will Drewry w...@chromium.org Cc: Eric Dumazet eduma...@google.com Cc: Russell King li

[PATCH v2 net-next 2/3] x86: bpf_jit_comp: support BPF_S_ANC_SECCOMP_LD_W instruction

This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction in x86 JIT. Signed-off-by: Xi Wang xi.w...@gmail.com Cc: Daniel Borkmann dbork...@redhat.com Cc: Heiko Carstens heiko.carst...@de.ibm.com Cc: Will Drewry w...@chromium.org Cc: Eric Dumazet eduma...@google.com Cc: Russell King li

[PATCH] sysctl: fix null checking in bin_dn_node_address()

The null check of `strchr() + 1' is broken, which is always non-null, leading to OOB read. Instead, check the result of strchr(). Signed-off-by: Xi Wang Cc: sta...@vger.kernel.org --- kernel/sysctl_binary.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel

[PATCH] sysctl: fix null checking in bin_dn_node_address()

The null check of `strchr() + 1' is broken, which is always non-null, leading to OOB read. Instead, check the result of strchr(). Signed-off-by: Xi Wang xi.w...@gmail.com Cc: sta...@vger.kernel.org --- kernel/sysctl_binary.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH RFC] exec: avoid possible undefined behavior in count()

On 1/7/13 4:44 PM, Andrew Morton wrote: > I have no problem working around a compiler bug when the workaround is > so small and simple. For clarity and accuracy I renamed the patch to > "fs/exec.c: work around icc miscompilation". Thanks! > However I'd also like to be able to add "this bug has

Re: [PATCH RFC] exec: avoid possible undefined behavior in count()

On 1/7/13 4:44 PM, Andrew Morton wrote: I have no problem working around a compiler bug when the workaround is so small and simple. For clarity and accuracy I renamed the patch to fs/exec.c: work around icc miscompilation. Thanks! However I'd also like to be able to add this bug has been

[PATCH RFC] exec: avoid possible undefined behavior in count()

integer overflow is undefined behavior. This optimization effectively reverts the previous commit 362e6663ef ("exec.c, compat.c: fix count(), compat_count() bounds checking") that tries to fix the check. This patch simply moves ++ after the check. Signed-off-by: Xi Wang --- Not sure how man

[PATCH RFC] exec: avoid possible undefined behavior in count()

is undefined behavior. This optimization effectively reverts the previous commit 362e6663ef (exec.c, compat.c: fix count(), compat_count() bounds checking) that tries to fix the check. This patch simply moves ++ after the check. Signed-off-by: Xi Wang xi.w...@gmail.com --- Not sure how many people

[PATCH] nfs: fix null checking in nfs_get_option_str()

code."). Signed-off-by: Xi Wang Cc: sta...@vger.kernel.org --- fs/nfs/super.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/super.c b/fs/nfs/super.c index c25cadf8..2e7e8c8 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -1152,7 +1152,7 @@

[PATCH] nfs: fix null checking in nfs_get_option_str()

.). Signed-off-by: Xi Wang xi.w...@gmail.com Cc: sta...@vger.kernel.org --- fs/nfs/super.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/super.c b/fs/nfs/super.c index c25cadf8..2e7e8c8 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -1152,7 +1152,7 @@ static int

Re: mvsas regression since 3.5

On 12/22/12 10:33 AM, Drunkard Zhang wrote: > I'm using Asus PIKE 6480 SAS card, whose chipset is "RAID bus > controller: Marvell Technology Group Ltd. MV64460/64461/64462 System > Controller, Revision B", with latest stable branch 3.7.1 only 1 of 8 > ports works, to get others works I got to pull

Re: mvsas regression since 3.5

On 12/22/12 10:33 AM, Drunkard Zhang wrote: I'm using Asus PIKE 6480 SAS card, whose chipset is RAID bus controller: Marvell Technology Group Ltd. MV64460/64461/64462 System Controller, Revision B, with latest stable branch 3.7.1 only 1 of 8 ports works, to get others works I got to pull plug

[PATCH v2] [SCSI] mvsas: fix undefined bit shift

ds to undefined behavior. The result varies depending on the architecture. This patch changes bit(n) to do a 64-bit shift. It also simplifies mv_ffc64() using __ffs64(), since invoking ffz() with ~0 is undefined. Signed-off-by: Xi Wang Cc: Xiangliang Yu Cc: James Bottomley Cc: sta...@vger.ker

[PATCH v2] [SCSI] mvsas: fix undefined bit shift

varies depending on the architecture. This patch changes bit(n) to do a 64-bit shift. It also simplifies mv_ffc64() using __ffs64(), since invoking ffz() with ~0 is undefined. Signed-off-by: Xi Wang xi.w...@gmail.com Cc: Xiangliang Yu yuxia...@marvell.com Cc: James Bottomley jbottom

Re: [PATCH v2] mm: fix null dev in dma_pool_create()

On 11/13/12 7:58 PM, Andrew Morton wrote: > I'm not sure that I really suggested doing this :( You suggested WARN_ON_ONCE(!dev); I changed it to WARN_ON(!dev) and kept the NULL check.. > We know there are a few scruffy drivers which are passing in dev==0. > > Those drivers don't oops because

[PATCH v2] mm: fix null dev in dma_pool_create()

the driver maintainers and avoid the null pointer dereference. Suggested-by: Andrew Morton Signed-off-by: Xi Wang --- mm/dmapool.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/dmapool.c b/mm/dmapool.c index c5ab33b..bf7f8f0 100644 --- a/mm/dmapool.c +++ b/mm

[PATCH v2] mm: fix null dev in dma_pool_create()

the driver maintainers and avoid the null pointer dereference. Suggested-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Xi Wang xi.w...@gmail.com --- mm/dmapool.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/dmapool.c b/mm/dmapool.c index c5ab33b..bf7f8f0

Re: [PATCH v2] mm: fix null dev in dma_pool_create()

On 11/13/12 7:58 PM, Andrew Morton wrote: I'm not sure that I really suggested doing this :( You suggested WARN_ON_ONCE(!dev); I changed it to WARN_ON(!dev) and kept the NULL check.. We know there are a few scruffy drivers which are passing in dev==0. Those drivers don't oops because

Re: [PATCH 2/3] [SCSI] mvsas: fix shift in mvs_94xx_free_reg_set()

On 11/9/12 2:30 AM, Xiangliang Yu wrote: Agree with James, and just need to do NOT operation one time Thanks for reviewing the patches. Okay I'll remove patch 2 in v2 then. About patch 3, I check the ffz code and found it will check ~0 conditions. Can you point me to the ~0 check in ffz

Re: [PATCH 2/3] [SCSI] mvsas: fix shift in mvs_94xx_free_reg_set()

On 11/9/12 2:30 AM, Xiangliang Yu wrote: Agree with James, and just need to do NOT operation one time Thanks for reviewing the patches. Okay I'll remove patch 2 in v2 then. About patch 3, I check the ffz code and found it will check ~0 conditions. Can you point me to the ~0 check in ffz

Re: [PATCH 2/3] [SCSI] mvsas: fix shift in mvs_94xx_free_reg_set()

On 11/6/12 7:06 AM, James Bottomley wrote: Why is this necessary? As I read the reg set assignment code, it finds a free bit in the 64 bit register and uses that ... which can never be greater than 64 so there's no need for the check. This patch just tries to be more defensive for

Re: [PATCH] mm: fix NULL checking in dma_pool_create()

On 11/5/12 4:26 PM, Andrew Morton wrote: > > OK, so it seems that those drivers have never been tested on a > CONFIG_NUMA kernel. whee. > > So we have a large amount of code here which ostensibly supports > dev==NULL but which has not been well tested. Take a look at > dma_alloc_coherent(),

Re: [PATCH] mm: fix NULL checking in dma_pool_create()

On 11/5/12 4:26 PM, Andrew Morton wrote: OK, so it seems that those drivers have never been tested on a CONFIG_NUMA kernel. whee. So we have a large amount of code here which ostensibly supports dev==NULL but which has not been well tested. Take a look at dma_alloc_coherent(),

Re: [PATCH 2/3] [SCSI] mvsas: fix shift in mvs_94xx_free_reg_set()

On 11/6/12 7:06 AM, James Bottomley wrote: Why is this necessary? As I read the reg set assignment code, it finds a free bit in the 64 bit register and uses that ... which can never be greater than 64 so there's no need for the check. This patch just tries to be more defensive for

  1   2   >