The dereference rport->data should come after the NULL check of rport.
Signed-off-by: Xi Wang
---
drivers/scsi/bnx2fc/bnx2fc_io.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c
index 8d4626c..eebe
First, `dev' is dereferenced in dev_to_node(dev), suggesting that it
must be non-null. Later `dev' is checked against NULL, suggesting
the opposite. This patch adds a NULL check before its use.
Signed-off-by: Xi Wang
---
mm/dmapool.c |5 -
1 file changed, 4 insertions(+),
have been a 64-bit shift:
if (i >= 32) {
mvi->sata_reg_set |= bit(i);
...
}
The other two patches fix similar oversized shift issues.
Xi Wang (3):
[SCSI] mvsas: fix shift in mvs_94xx_assign_reg_set()
[SCSI] mvsas: fix shift in mvs_94xx_fr
Invoking ffz(x) with x = ~0 is undefined. This patch returns -1
for this case, and invokes __ffs64() instead.
Signed-off-by: Xi Wang
---
drivers/scsi/mvsas/mv_94xx.h | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/mvsas/mv_94xx.h b/drivers
ds to undefined behavior.
The result varies depending on the architecture.
This patch changes bit(n) to do a 64-bit shift.
Signed-off-by: Xi Wang
---
drivers/scsi/mvsas/mv_sas.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/mvsas/mv_sas.h b/drivers/scsi
Invoking bit(n) with n >= 64 is undefined behavior, since bit(n) does
a 64-bit shift. This patch adds a check on the shifting amount.
Signed-off-by: Xi Wang
---
drivers/scsi/mvsas/mv_94xx.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/mv
On 11/5/12 3:37 PM, Andrew Morton wrote:
>
> Well, the dma_pool_create() kerneldoc does not describe dev==NULL to be
> acceptable usage and given the lack of oops reports, we can assume that
> no code is calling this function with dev==NULL.
>
> So I think we can just remove the code which handle
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
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 no
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(), dma
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 bit(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 co
e
cut-and-paste 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
@@ -115
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
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.k
s that it'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/
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
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 Drewr
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
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
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
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
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
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
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
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 used
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, looks
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
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 patches.
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 it
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 & TS_C
omp filters; 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 th
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 ne
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
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
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
---
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
---
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 t
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 no
> 2 * get_max_files()
which prevents the kernel from creating a unix domain socket when the
sysadmin sets a large file-max.
Suggested-by: Eric Dumazet
Signed-off-by: Xi Wang
---
What's the best min value for file-max? This patch uses NR_FILE.
Zero seems weird. BITS_PER_LONG as sysctl_nr_open_
The allowed value of "how" is SHUT_RD/SHUT_WR/SHUT_RDWR (0/1/2),
rather than SHUTDOWN_MASK (3).
Signed-off-by: Xi Wang
---
net/decnet/af_decnet.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
index 2ba1a2
Return -EINVAL rather than 0 given an invalid "mode" parameter.
Signed-off-by: Xi Wang
---
Another way to check "mode" is as in inet_shutdown():
mode++;
if ((mode & ~SHUTDOWN_MASK) || !mode)
return -EINVAL;
This patch uses a simpler for
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/k
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 b
eger 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
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 Deaco
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
ff-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
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 ahe
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
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
, 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
lexei 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
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
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:
> > > >
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 AM
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
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
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 reset
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
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 |
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
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-
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
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:
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
> bpf_prog_
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 fly
67 matches
Mail list logo
