On Fri, Oct 1, 2021 at 2:17 PM Naveen N. Rao
wrote:
>
> We aren't handling subtraction involving an immediate value of
> 0x8000 properly. Fix the same.
>
> Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended
> BPF")
> Signed-off-by: Naveen N. Rao
Acked-by: Song
On Fri, Oct 1, 2021 at 2:16 PM Naveen N. Rao
wrote:
>
> Only ignore the operation if dividing by 1.
>
> Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended
> BPF")
> Signed-off-by: Naveen N. Rao
Acked-by: Song Liu
> ---
> arch/powerpc/net/bpf_jit_comp64.c | 10
On Fri, Oct 1, 2021 at 2:17 PM Naveen N. Rao
wrote:
>
> In some scenarios, it is possible that the program epilogue is outside
> the branch range for a BPF_EXIT instruction. Instead of rejecting such
> programs, emit an indirect branch. We track the size of the bpf program
> emitted after the
On Fri, Oct 1, 2021 at 2:16 PM Naveen N. Rao
wrote:
>
> From: Ravi Bangoria
>
> SEEN_STACK is unused on PowerPC. Remove it. Also, have
> SEEN_TAILCALL use 0x4000.
>
> Signed-off-by: Ravi Bangoria
> Reviewed-by: Christophe Leroy
Acked-by: Song Liu
> ---
> arch/powerpc/net/bpf_jit.h | 3
On Fri, Oct 1, 2021 at 2:16 PM Naveen N. Rao
wrote:
>
> Add checks to ensure that we never emit branch instructions with
> truncated branch offsets.
>
> Suggested-by: Michael Ellerman
> Signed-off-by: Naveen N. Rao
Acked-by: Song Liu
> ---
> arch/powerpc/net/bpf_jit.h| 26
On Fri, Oct 1, 2021 at 2:16 PM Naveen N. Rao
wrote:
>
> Add a helper to check if a given offset is within the branch range for a
> powerpc conditional branch instruction, and update some sites to use the
> new helper.
>
> Signed-off-by: Naveen N. Rao
Acked-by: Song Liu
With one nitpick:
>
Daniel Borkmann wrote:
On 9/29/21 1:18 PM, Hari Bathini wrote:
Patch #1 & #2 are simple cleanup patches. Patch #3 refactors JIT
compiler code with the aim to simplify adding BPF_PROBE_MEM support.
Patch #4 introduces PPC_RAW_BRANCH() macro instead of open coding
branch instruction. Patch #5 &
Add a helper to return the stf_barrier type for the current processor.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/security_features.h | 5 +
arch/powerpc/kernel/security.c | 5 +
2 files changed, 10 insertions(+)
diff --git
Emit similar instruction sequences to commit a048a07d7f4535
("powerpc/64s: Add support for a store forwarding barrier at kernel
entry/exit") when encountering BPF_NOSPEC.
Mitigations are enabled depending on what the firmware advertises. In
particular, we do not gate these mitigations based on
Johan reported the below crash with test_bpf on ppc64 e5500:
test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1
Oops: Exception in kernel mode, sig: 4 [#1]
BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500
Modules linked in: test_bpf(+)
CPU: 0 PID: 76 Comm: insmod Not
We aren't handling subtraction involving an immediate value of
0x8000 properly. Fix the same.
Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended
BPF")
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit_comp64.c | 16
1 file changed, 8
Only ignore the operation if dividing by 1.
Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended
BPF")
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit_comp64.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
In some scenarios, it is possible that the program epilogue is outside
the branch range for a BPF_EXIT instruction. Instead of rejecting such
programs, emit an indirect branch. We track the size of the bpf program
emitted after the initial run and do a second pass since BPF_EXIT can
end up
From: Ravi Bangoria
SEEN_STACK is unused on PowerPC. Remove it. Also, have
SEEN_TAILCALL use 0x4000.
Signed-off-by: Ravi Bangoria
Reviewed-by: Christophe Leroy
---
arch/powerpc/net/bpf_jit.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit.h
Add checks to ensure that we never emit branch instructions with
truncated branch offsets.
Suggested-by: Michael Ellerman
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit.h| 26 --
arch/powerpc/net/bpf_jit_comp.c | 6 +-
Add a helper to check if a given offset is within the branch range for a
powerpc conditional branch instruction, and update some sites to use the
new helper.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/code-patching.h | 1 +
arch/powerpc/lib/code-patching.c | 7 ++-
Various fixes to the eBPF JIT for powerpc, thanks to some new tests
added by Johan. This series fixes all failures in test_bpf on powerpc64.
There are still some failures on powerpc32 to be looked into.
- Naveen
Naveen N. Rao (8):
powerpc/lib: Add helper to check if offset is within
On Fri, Oct 1, 2021 at 4:46 AM Krzysztof Kozlowski
wrote:
>
> On 01/10/2021 02:09, Li Yang wrote:
> > Convert the ifc binding to yaml schema, in the mean while remove the
> > "simple-bus" compatible from the binding to make sure ifc device probes
> > before any of the child devices. Update the
On Fri, Oct 01, 2021 at 12:25:42PM +0200, Vincent Guittot wrote:
> Hi Guillaume,
>
> This patch and the patchset which includes this patch only impacts
> systems with hyperthreading which is not the case of rk3328-rock64
> AFAICT. So there is no reason that this code is used by the board. The
>
On Fri, Oct 1, 2021 at 11:29 AM Li Yang wrote:
>
> On Fri, Oct 1, 2021 at 8:18 AM Rob Herring wrote:
> >
> > On Thu, 30 Sep 2021 19:09:20 -0500, Li Yang wrote:
> > > Convert the txt binding to yaml format and add description. Drop the
> > > "simple-bus" compatible string from the example and
On Fri, Oct 1, 2021 at 8:18 AM Rob Herring wrote:
>
> On Thu, 30 Sep 2021 19:09:20 -0500, Li Yang wrote:
> > Convert the txt binding to yaml format and add description. Drop the
> > "simple-bus" compatible string from the example and not allowed by the
> > binding any more. This will help to
On Fri, Oct 1, 2021 at 5:01 AM Krzysztof Kozlowski
wrote:
>
> On 01/10/2021 02:09, Li Yang wrote:
> > Convert the txt binding to yaml format and add description. Drop the
> > "simple-bus" compatible string from the example and not allowed by the
> > binding any more. This will help to enforce
On Thu, 30 Sep 2021 13:44:54 +1000, Alexey Kardashevskiy wrote:
> According to dma-api.rst, the dma_get_required_mask() helper should return
> "the mask that the platform requires to operate efficiently". Which in
> the case of PPC64 means the bypass mask and not a mask from an IOMMU table
> which
On Thu, 30 Sep 2021 19:09:20 -0500, Li Yang wrote:
> Convert the txt binding to yaml format and add description. Drop the
> "simple-bus" compatible string from the example and not allowed by the
> binding any more. This will help to enforce the correct probe order
> between parent device and
Hi Ricardo,
Please see the bisection report below about a boot failure on
rk3288-rock64.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.
Some more details can be found here:
On 01/10/2021 11:33, Guillaume Tucker wrote:
> Please see the bisection report below about a boot failure on
> rk3288-rock64.
Sorry, I meant rk3328-rock64.
Guillaume
Daniel Axtens writes:
> Hi Athira,
>
>> PERF_REG_PMU_MASK_300 and PERF_REG_PMU_MASK_31 defines the mask
>> value for extended registers. Current definition of these mask values
>> uses hex constant and does not use registers by name, making it less
>> readable. Patch refactor the macro values in
Hi Guillaume,
This patch and the patchset which includes this patch only impacts
systems with hyperthreading which is not the case of rk3328-rock64
AFAICT. So there is no reason that this code is used by the board. The
only impact should be an increase of the binary for this platform.
Could it be
> On 01-Oct-2021, at 11:50 AM, Daniel Axtens wrote:
>
> Hi Athira,
>
>> PERF_REG_PMU_MASK_300 and PERF_REG_PMU_MASK_31 defines the mask
>> value for extended registers. Current definition of these mask values
>> uses hex constant and does not use registers by name, making it less
>>
On Thu, 23 Sep 2021 10:26:44 -0700
Ben Widawsky wrote:
> Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
> Extended Capability with the specified DVSEC ID.
>
> The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
> more vendor specific capabilities that
On 01/10/2021 02:09, Li Yang wrote:
> Convert the txt binding to yaml format and add description. Drop the
> "simple-bus" compatible string from the example and not allowed by the
> binding any more. This will help to enforce the correct probe order
> between parent device and child devices, but
On 01/10/2021 02:09, Li Yang wrote:
> Convert the ifc binding to yaml schema, in the mean while remove the
> "simple-bus" compatible from the binding to make sure ifc device probes
> before any of the child devices. Update the driver and existing DTSes
> accordingly.
>
> DTS changes should be
> #ifdef __KERNEL__
> +/*
> + * Check if an address is part of freed initmem. After initmem is freed,
> + * memory can be allocated from it, and such allocations would then have
> + * addresses within the range [_stext, _end].
> + */
> +#ifndef arch_is_kernel_initmem_freed
> +static int
Athira Rajeev writes:
> Patch adds support to include Sampled Instruction Address Register
This is a nit and doesn't require a new revision, but I think this
should read "Include Sampled Instruction Address ...", not "Patch adds
support to include Sampled Instruction ..." - see
Hi Athira,
> PERF_REG_PMU_MASK_300 and PERF_REG_PMU_MASK_31 defines the mask
> value for extended registers. Current definition of these mask values
> uses hex constant and does not use registers by name, making it less
> readable. Patch refactor the macro values in perf tools side header file
>
Hi Vasant,
> Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added
> opal notifier. But I missed to unregister the notifier during module unload
> path. This results in below call trace if you try to unload and load
> opal_prd module.
>
> Fixes: 587164cd ("powerpc/powernv:
36 matches
Mail list logo
