* Re: Add Apple M1 support to PASemi i2c driver
From: Arnd Bergmann @ 2021-10-04 11:20 UTC (permalink / raw)
To: Wolfram Sang, Christian Zigotzky, Sven Peter, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Olof Johansson,
Arnd Bergmann, Hector Martin, Mohamed Mediouni, Stan Skowronek,
Mark Kettenis, Linux ARM, Alyssa Rosenzweig, linuxppc-dev,
Linux I2C, Linux Kernel Mailing List, R.T.Dickinson,
Darren Stevens, Matthew Leaman, R.T.Dickinson
In-Reply-To: <YVrPf4yVFm184LEG@shikoro>
On Mon, Oct 4, 2021 at 11:55 AM Wolfram Sang <wsa@kernel.org> wrote:
>
>
> > i2c-8 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
> > i2c-9 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
> > i2c-10 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
>
> As Sven correctly switched from %lx to %p, this is intended behaviour.
> Run 'i2cdetect' as root to see the values again.
I think the address could just get removed here, as this is clearly not helpful.
port number, which is somewhat useful for identifying the device, now
it's either the pointless string, or the virtual address that the
device is mapped
to, which is not helpful either and potentially leaks information about kernel
internal structures.
Arnd
^ permalink raw reply
* Re: Add Apple M1 support to PASemi i2c driver
From: Sven Peter @ 2021-10-04 11:22 UTC (permalink / raw)
To: Arnd Bergmann, Wolfram Sang, Christian Zigotzky, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Olof Johansson,
Hector Martin, Mohamed Mediouni, Stan Skowronek, Mark Kettenis,
Linux ARM, Alyssa Rosenzweig, linuxppc-dev, Linux I2C,
Linux Kernel Mailing List, R.T.Dickinson, Darren Stevens,
Matthew Leaman, R.T.Dickinson
In-Reply-To: <CAK8P3a2760x4OYbNBuFCv32Tgt7K3MdJna4qXvPchdKhV8-8vQ@mail.gmail.com>
On Mon, Oct 4, 2021, at 13:20, Arnd Bergmann wrote:
> On Mon, Oct 4, 2021 at 11:55 AM Wolfram Sang <wsa@kernel.org> wrote:
>>
>>
>> > i2c-8 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
>> > i2c-9 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
>> > i2c-10 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
>>
>> As Sven correctly switched from %lx to %p, this is intended behaviour.
>> Run 'i2cdetect' as root to see the values again.
>
> I think the address could just get removed here, as this is clearly not helpful.
> port number, which is somewhat useful for identifying the device, now
> it's either the pointless string, or the virtual address that the
> device is mapped
> to, which is not helpful either and potentially leaks information about kernel
> internal structures.
Yeah, now that I'm looking at it again it doesn't make much sense to
include it there. Maybe just dev_name(smbus->dev) instead of the address?
Sven
^ permalink raw reply
* Re: Add Apple M1 support to PASemi i2c driver
From: Wolfram Sang @ 2021-10-04 9:55 UTC (permalink / raw)
To: Christian Zigotzky
Cc: Darren Stevens, Arnd Bergmann, Sven Peter, Hector Martin,
Linux Kernel Mailing List, linux-i2c, Paul Mackerras,
Alyssa Rosenzweig, R.T.Dickinson, Olof Johansson,
mohamed.mediouni, Matthew Leaman, Mark Kettenis, linuxppc-dev,
R.T.Dickinson, linux-arm-kernel, Stan Skowronek
In-Reply-To: <1B71F6A3-6467-46EF-858F-82E93D54365D@xenosoft.de>
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
> i2c-8 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
> i2c-9 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
> i2c-10 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
As Sven correctly switched from %lx to %p, this is intended behaviour.
Run 'i2cdetect' as root to see the values again.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Add Apple M1 support to PASemi i2c driver
From: Christian Zigotzky @ 2021-10-04 9:47 UTC (permalink / raw)
To: Sven Peter
Cc: Darren Stevens, Arnd Bergmann, Hector Martin,
Linux Kernel Mailing List, linux-i2c, Paul Mackerras,
Alyssa Rosenzweig, R.T.Dickinson, Olof Johansson,
mohamed.mediouni, Matthew Leaman, Mark Kettenis, linuxppc-dev,
R.T.Dickinson, linux-arm-kernel, Stan Skowronek
In-Reply-To: <49890226-cf04-46ff-bc37-33d1643faea2@www.fastmail.com>
Hi Sven,
Unfortunately Damien has found an issue. [1]
Output of i2cdetect -l with the default RC3 of kernel 5.15 without your modifications:
2c-0 i2c Radeon i2c bit bus 0x90 I2C adapter
i2c-1 i2c Radeon i2c bit bus 0x91 I2C adapter
i2c-2 i2c Radeon i2c bit bus 0x92 I2C adapter
i2c-3 i2c Radeon i2c bit bus 0x93 I2C adapter
i2c-4 i2c Radeon i2c bit bus 0x94 I2C adapter
i2c-5 i2c Radeon i2c bit bus 0x95 I2C adapter
i2c-6 i2c Radeon i2c bit bus 0x96 I2C adapter
i2c-7 i2c Radeon i2c bit bus 0x97 I2C adapter
i2c-8 i2c PA Semi SMBus adapter at 0x800200 I2C adapter
i2c-9 i2c PA Semi SMBus adapter at 0x800240 I2C adapter
i2c-10 i2c PA Semi SMBus adapter at 0x800280 I2C adapter
Output of i2cdetect -l with your modifications:
i2c-0 i2c Radeon i2c bit bus 0x90 I2C adapter
i2c-1 i2c Radeon i2c bit bus 0x91 I2C adapter
i2c-2 i2c Radeon i2c bit bus 0x92 I2C adapter
i2c-3 i2c Radeon i2c bit bus 0x93 I2C adapter
i2c-4 i2c Radeon i2c bit bus 0x94 I2C adapter
i2c-5 i2c Radeon i2c bit bus 0x95 I2C adapter
i2c-6 i2c Radeon i2c bit bus 0x96 I2C adapter
i2c-7 i2c Radeon i2c bit bus 0x97 I2C adapter
i2c-8 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
i2c-9 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
i2c-10 i2c PA Semi SMBus adapter at 0x(____ptrval____) I2C adapter
Please check the outputs.
Thanks,
Christian
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54165#p54165
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: memory: fsl: convert ifc binding to yaml schema
From: Krzysztof Kozlowski @ 2021-10-04 9:31 UTC (permalink / raw)
To: Li Yang
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linuxppc-dev, lkml, Rob Herring, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CADRPPNROVBp_QB=6XEgk8WF5fnEPFTSko4Nn+mm8oLM3iGTuuw@mail.gmail.com>
On 01/10/2021 18:17, Li Yang wrote:
> On Fri, Oct 1, 2021 at 5:01 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
>>
(...)
>>> +
>>> + interrupts:
>>> + minItems: 1
>>> + maxItems: 2
>>> + description: |
>>> + IFC may have one or two interrupts. If two interrupt specifiers are
>>> + present, the first is the "common" interrupt (CM_EVTER_STAT), and the
>>> + second is the NAND interrupt (NAND_EVTER_STAT). If there is only one,
>>> + that interrupt reports both types of event.
>>> +
>>> + little-endian:
>>> + $ref: '/schemas/types.yaml#/definitions/flag'
>>
>> type: boolean
>
> It will not have a true or false value, but only present or not. Is
> the boolean type taking care of this too?
boolean is for a property which does not accept values and true/false
depends on its presence.
See:
Documentation/devicetree/bindings/phy/lantiq,vrx200-pcie-phy.yaml
Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] powerpc/eeh:Fix docstrings in eeh
From: Kai Song @ 2021-10-04 8:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, Kai Song, oohall, linux-kernel, dja
We fix the following warnings when building kernel with W=1:
arch/powerpc/kernel/eeh.c:598: warning: Function parameter or member 'function' not described in 'eeh_pci_enable'
arch/powerpc/kernel/eeh.c:774: warning: Function parameter or member 'edev' not described in 'eeh_set_dev_freset'
arch/powerpc/kernel/eeh.c:774: warning: expecting prototype for eeh_set_pe_freset(). Prototype was for eeh_set_dev_freset() instead
arch/powerpc/kernel/eeh.c:814: warning: Function parameter or member 'include_passed' not described in 'eeh_pe_reset_full'
arch/powerpc/kernel/eeh.c:944: warning: Function parameter or member 'ops' not described in 'eeh_init'
arch/powerpc/kernel/eeh.c:1451: warning: Function parameter or member 'include_passed' not described in 'eeh_pe_reset'
arch/powerpc/kernel/eeh.c:1526: warning: Function parameter or member 'func' not described in 'eeh_pe_inject_err'
arch/powerpc/kernel/eeh.c:1526: warning: Excess function parameter 'function' described in 'eeh_pe_inject_err'
Signed-off-by: Kai Song <songkai01@inspur.com>
---
arch/powerpc/kernel/eeh.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index e9b597ed423c..57a6868a41ab 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -589,6 +589,7 @@ EXPORT_SYMBOL(eeh_check_failure);
/**
* eeh_pci_enable - Enable MMIO or DMA transfers for this slot
* @pe: EEH PE
+ * @function : EEH function
*
* This routine should be called to reenable frozen MMIO or DMA
* so that it would work correctly again. It's useful while doing
@@ -761,8 +762,8 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state stat
}
/**
- * eeh_set_pe_freset - Check the required reset for the indicated device
- * @data: EEH device
+ * eeh_set_dev_freset - Check the required reset for the indicated device
+ * @edev: EEH device
* @flag: return value
*
* Each device might have its preferred reset type: fundamental or
@@ -801,6 +802,7 @@ static void eeh_pe_refreeze_passed(struct eeh_pe *root)
/**
* eeh_pe_reset_full - Complete a full reset process on the indicated PE
* @pe: EEH PE
+ * @include_passed: include passed-through devices?
*
* This function executes a full reset procedure on a PE, including setting
* the appropriate flags, performing a fundamental or hot reset, and then
@@ -937,6 +939,7 @@ static struct notifier_block eeh_device_nb = {
/**
* eeh_init - System wide EEH initialization
+ * @ops: struct to trace EEH operation callback functions
*
* It's the platform's job to call this from an arch_initcall().
*/
@@ -1442,6 +1445,7 @@ static int eeh_pe_reenable_devices(struct eeh_pe *pe, bool include_passed)
* eeh_pe_reset - Issue PE reset according to specified type
* @pe: EEH PE
* @option: reset type
+ * @include_passed: include passed-through devices?
*
* The routine is called to reset the specified PE with the
* indicated type, either fundamental reset or hot reset.
@@ -1513,12 +1517,12 @@ EXPORT_SYMBOL_GPL(eeh_pe_configure);
* eeh_pe_inject_err - Injecting the specified PCI error to the indicated PE
* @pe: the indicated PE
* @type: error type
- * @function: error function
+ * @func: error function
* @addr: address
* @mask: address mask
*
* The routine is called to inject the specified PCI error, which
- * is determined by @type and @function, to the indicated PE for
+ * is determined by @type and @func, to the indicated PE for
* testing purpose.
*/
int eeh_pe_inject_err(struct eeh_pe *pe, int type, int func,
--
2.27.0
^ permalink raw reply related
* Re: [PATCH v4 0/8] bpf powerpc: Add BPF_PROBE_MEM support in powerpc JIT compiler
From: Michael Ellerman @ 2021-10-04 8:43 UTC (permalink / raw)
To: Daniel Borkmann, Hari Bathini, naveen.n.rao, christophe.leroy,
ast
Cc: songliubraving, netdev, john.fastabend, andrii, kpsingh, paulus,
yhs, bpf, linuxppc-dev, kafai
In-Reply-To: <768469ec-a596-9e0c-541c-aca5693d69e7@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> On 10/4/21 12:49 AM, Michael Ellerman wrote:
>> Daniel Borkmann <daniel@iogearbox.net> writes:
>>> 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 & #7 add BPF_PROBE_MEM support for PPC64
>>>> & PPC32 JIT compilers respectively. Patch #6 & #8 handle bad userspace
>>>> pointers for PPC64 & PPC32 cases respectively.
>>>
>>> Michael, are you planning to pick up the series or shall we route via bpf-next?
>>
>> Yeah I'll plan to take it, unless you think there is a strong reason it
>> needs to go via the bpf tree (doesn't look like it from the diffstat).
>
> Sounds good to me, in that case, please also route the recent JIT fixes from
> Naveen through your tree.
Will do.
cheers
^ permalink raw reply
* Re: [PATCH v4 0/8] bpf powerpc: Add BPF_PROBE_MEM support in powerpc JIT compiler
From: Daniel Borkmann @ 2021-10-04 8:05 UTC (permalink / raw)
To: Michael Ellerman, Hari Bathini, naveen.n.rao, christophe.leroy,
ast
Cc: songliubraving, netdev, john.fastabend, andrii, kpsingh, paulus,
yhs, bpf, linuxppc-dev, kafai
In-Reply-To: <87o885raev.fsf@mpe.ellerman.id.au>
On 10/4/21 12:49 AM, Michael Ellerman wrote:
> Daniel Borkmann <daniel@iogearbox.net> writes:
>> 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 & #7 add BPF_PROBE_MEM support for PPC64
>>> & PPC32 JIT compilers respectively. Patch #6 & #8 handle bad userspace
>>> pointers for PPC64 & PPC32 cases respectively.
>>
>> Michael, are you planning to pick up the series or shall we route via bpf-next?
>
> Yeah I'll plan to take it, unless you think there is a strong reason it
> needs to go via the bpf tree (doesn't look like it from the diffstat).
Sounds good to me, in that case, please also route the recent JIT fixes from
Naveen through your tree.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v4 0/8] bpf powerpc: Add BPF_PROBE_MEM support in powerpc JIT compiler
From: Michael Ellerman @ 2021-10-03 22:49 UTC (permalink / raw)
To: Daniel Borkmann, Hari Bathini, naveen.n.rao, christophe.leroy,
ast
Cc: songliubraving, netdev, john.fastabend, andrii, kpsingh, paulus,
yhs, bpf, linuxppc-dev, kafai
In-Reply-To: <88b59272-e3f7-30ba-dda0-c4a6b42c0029@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> 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 & #7 add BPF_PROBE_MEM support for PPC64
>> & PPC32 JIT compilers respectively. Patch #6 & #8 handle bad userspace
>> pointers for PPC64 & PPC32 cases respectively.
>
> Michael, are you planning to pick up the series or shall we route via bpf-next?
Yeah I'll plan to take it, unless you think there is a strong reason it
needs to go via the bpf tree (doesn't look like it from the diffstat).
cheers
^ permalink raw reply
* Re: [PATCH v4 07/11] mm: kasan: Use is_kernel() helper
From: Andrey Konovalov @ 2021-10-03 17:19 UTC (permalink / raw)
To: Kefeng Wang
Cc: linux-arch, Andrey Ryabinin, bpf, Arnd Bergmann, linux-alpha,
LKML, Steven Rostedt, Alexei Starovoitov, mingo, paulus,
Alexander Potapenko, Andrew Morton, linuxppc-dev, David Miller,
Dmitry Vyukov
In-Reply-To: <20210930071143.63410-8-wangkefeng.wang@huawei.com>
On Thu, Sep 30, 2021 at 9:09 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> Directly use is_kernel() helper in kernel_or_module_addr().
>
> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrey Konovalov <andreyknvl@gmail.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> mm/kasan/report.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 3239fd8f8747..1c955e1c98d5 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -226,7 +226,7 @@ static void describe_object(struct kmem_cache *cache, void *object,
>
> static inline bool kernel_or_module_addr(const void *addr)
> {
> - if (addr >= (void *)_stext && addr < (void *)_end)
> + if (is_kernel((unsigned long)addr))
> return true;
> if (is_module_address((unsigned long)addr))
> return true;
> --
> 2.26.2
>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
^ permalink raw reply
* Re: Add Apple M1 support to PASemi i2c driver
From: Christian Zigotzky @ 2021-10-03 15:45 UTC (permalink / raw)
To: Sven Peter
Cc: Darren Stevens, Arnd Bergmann, Hector Martin,
Linux Kernel Mailing List, linux-i2c, Paul Mackerras,
Alyssa Rosenzweig, R.T.Dickinson, Olof Johansson,
mohamed.mediouni, Matthew Leaman, Mark Kettenis, linuxppc-dev,
R.T.Dickinson, linux-arm-kernel, Stan Skowronek
In-Reply-To: <49890226-cf04-46ff-bc37-33d1643faea2@www.fastmail.com>
On 03 October 2021 at 04:36 pm, Sven Peter wrote:
> Hi,
>
>
> On Fri, Oct 1, 2021, at 06:47, Christian Zigotzky wrote:
>> On 27 September 2021 at 07:39 am, Sven Peter wrote:
>> > Hi Christian,
>> >
>> > Thanks already for volunteering to test this!
>> >
>> Hello Sven,
>>
>> Damian (Hypex) has successfully tested the RC3 of kernel 5.15 with your
>> modified i2c driver on his Nemo board yesterday. [1]
>
> Thanks a lot, that's great to hear!
> If he wants to I can credit him with a Tested-by tag in the commit
message,
> see e.g.
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes.
>
>
> Best,
>
>
> Sven
Hello Sven,
We are still testing your i2c modifications. [1]
Please wait a litte bit till we finished our tests.
@Darren
Could you also please check Sven's i2c modifications? He has also
modified your source code a little bit. [2]
@Olof
Are these i2c modifications OK? Do these work on your P.A. Semi board?
Thanks,
Christian
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54138#p54138
[2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-January/153195.html
^ permalink raw reply
* Re: [PATCH 09/10] i2c: pasemi: Add Apple platform driver
From: Sven Peter @ 2021-10-03 14:37 UTC (permalink / raw)
To: Wolfram Sang
Cc: Arnd Bergmann, Hector Martin, linux-kernel, linux-i2c,
Paul Mackerras, linux-arm-kernel, Olof Johansson,
Mohamed Mediouni, Mark Kettenis, linuxppc-dev, Alyssa Rosenzweig,
Stan Skowronek
In-Reply-To: <YVTNpt/vOeZI5P+L@kunai>
On Wed, Sep 29, 2021, at 22:33, Wolfram Sang wrote:
>> drivers/i2c/busses/i2c-pasemi-apple.c | 122 ++++++++++++++++++++++++++
>
> Can't we name it 'i2c-pasemi-platform.c' instead? Makes more sense to me
> because the other instance is named -pci.
Sure, that's more consistent. I'll change the filename for v2.
Thanks,
Sven
^ permalink raw reply
* Re: Add Apple M1 support to PASemi i2c driver
From: Sven Peter @ 2021-10-03 14:36 UTC (permalink / raw)
To: Christian Zigotzky
Cc: Darren Stevens, Arnd Bergmann, Hector Martin,
Linux Kernel Mailing List, linux-i2c, Paul Mackerras,
Alyssa Rosenzweig, R.T.Dickinson, Olof Johansson,
mohamed.mediouni, Matthew Leaman, Mark Kettenis, linuxppc-dev,
R.T.Dickinson, linux-arm-kernel, Stan Skowronek
In-Reply-To: <9c1f5c48-bf1a-0ecc-e769-773d2935c66c@xenosoft.de>
Hi,
On Fri, Oct 1, 2021, at 06:47, Christian Zigotzky wrote:
> On 27 September 2021 at 07:39 am, Sven Peter wrote:
> > Hi Christian,
> >
> > Thanks already for volunteering to test this!
> >
> Hello Sven,
>
> Damian (Hypex) has successfully tested the RC3 of kernel 5.15 with your
> modified i2c driver on his Nemo board yesterday. [1]
Thanks a lot, that's great to hear!
If he wants to I can credit him with a Tested-by tag in the commit message,
see e.g. https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes.
Best,
Sven
^ permalink raw reply
* Re: [PATCH 6/9] powerpc/bpf: Fix BPF_SUB when imm == 0x80000000
From: Christophe Leroy @ 2021-10-03 8:07 UTC (permalink / raw)
To: Naveen N. Rao, Michael Ellerman, Nicholas Piggin, Daniel Borkmann,
Alexei Starovoitov, Johan Almbladh
Cc: bpf, linuxppc-dev
In-Reply-To: <1912a409447071f46ac6cc957ce8edea0e5232b7.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
Le 01/10/2021 à 23:14, Naveen N. Rao a écrit :
> We aren't handling subtraction involving an immediate value of
> 0x80000000 properly. Fix the same.
>
> Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/net/bpf_jit_comp64.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index ffb7a2877a8469..4641a50e82d50d 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -333,15 +333,15 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> case BPF_ALU | BPF_SUB | BPF_K: /* (u32) dst -= (u32) imm */
> case BPF_ALU64 | BPF_ADD | BPF_K: /* dst += imm */
> case BPF_ALU64 | BPF_SUB | BPF_K: /* dst -= imm */
> - if (BPF_OP(code) == BPF_SUB)
> - imm = -imm;
> - if (imm) {
> - if (imm >= -32768 && imm < 32768)
> - EMIT(PPC_RAW_ADDI(dst_reg, dst_reg, IMM_L(imm)));
> - else {
> - PPC_LI32(b2p[TMP_REG_1], imm);
> + if (imm > -32768 && imm < 32768) {
> + EMIT(PPC_RAW_ADDI(dst_reg, dst_reg,
> + BPF_OP(code) == BPF_SUB ? IMM_L(-imm) : IMM_L(imm)));
> + } else {
> + PPC_LI32(b2p[TMP_REG_1], imm);
> + if (BPF_OP(code) == BPF_SUB)
> + EMIT(PPC_RAW_SUB(dst_reg, dst_reg, b2p[TMP_REG_1]));
> + else
> EMIT(PPC_RAW_ADD(dst_reg, dst_reg, b2p[TMP_REG_1]));
> - }
> }
> goto bpf_alu32_trunc;
There is now so few code common to both BPF_ADD and BPF_SUB that you
should make them different cases.
While at it, why not also use ADDIS if imm is 32 bits ? That would be an
ADDIS/ADDI instead of LIS/ORI/ADD
> case BPF_ALU | BPF_MUL | BPF_X: /* (u32) dst *= (u32) src */
>
^ permalink raw reply
* Re: [PATCH 4/9] powerpc/bpf: Handle large branch ranges with BPF_EXIT
From: Christophe Leroy @ 2021-10-03 7:59 UTC (permalink / raw)
To: Naveen N. Rao, Michael Ellerman, Nicholas Piggin, Daniel Borkmann,
Alexei Starovoitov, Johan Almbladh
Cc: bpf, linuxppc-dev
In-Reply-To: <ebc0317ce465cb4f8d6fe485ab468ac5bda7c48f.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
Le 01/10/2021 à 23:14, Naveen N. Rao a écrit :
> 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 emitting different number of instructions depending on the
> program size.
>
> Suggested-by: Jordan Niethe <jniethe5@gmail.com>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/net/bpf_jit.h | 3 +++
> arch/powerpc/net/bpf_jit_comp.c | 22 +++++++++++++++++++++-
> arch/powerpc/net/bpf_jit_comp32.c | 2 +-
> arch/powerpc/net/bpf_jit_comp64.c | 2 +-
> 4 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 89bd744c2bffd4..4023de1698b9f5 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -126,6 +126,7 @@
>
> #define SEEN_FUNC 0x20000000 /* might call external helpers */
> #define SEEN_TAILCALL 0x40000000 /* uses tail calls */
> +#define SEEN_BIG_PROG 0x80000000 /* large prog, >32MB */
>
> #define SEEN_VREG_MASK 0x1ff80000 /* Volatile registers r3-r12 */
> #define SEEN_NVREG_MASK 0x0003ffff /* Non volatile registers r14-r31 */
> @@ -179,6 +180,8 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> void bpf_jit_build_prologue(u32 *image, struct codegen_context *ctx);
> void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx);
> void bpf_jit_realloc_regs(struct codegen_context *ctx);
> +int bpf_jit_emit_exit_insn(u32 *image, struct codegen_context *ctx,
> + int tmp_reg, unsigned long exit_addr);
>
> #endif
>
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index fcbf7a917c566e..3204872fbf2738 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -72,6 +72,21 @@ static int bpf_jit_fixup_subprog_calls(struct bpf_prog *fp, u32 *image,
> return 0;
> }
>
> +int bpf_jit_emit_exit_insn(u32 *image, struct codegen_context *ctx,
> + int tmp_reg, unsigned long exit_addr)
> +{
> + if (!(ctx->seen & SEEN_BIG_PROG) && is_offset_in_branch_range(exit_addr)) {
> + PPC_JMP(exit_addr);
> + } else {
> + ctx->seen |= SEEN_BIG_PROG;
> + PPC_FUNC_ADDR(tmp_reg, (unsigned long)image + exit_addr);
> + EMIT(PPC_RAW_MTCTR(tmp_reg));
> + EMIT(PPC_RAW_BCTR());
> + }
> +
> + return 0;
> +}
> +
> struct powerpc64_jit_data {
> struct bpf_binary_header *header;
> u32 *addrs;
> @@ -155,12 +170,17 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
> goto out_addrs;
> }
>
> + if (!is_offset_in_branch_range((long)cgctx.idx * 4))
> + cgctx.seen |= SEEN_BIG_PROG;
> +
> /*
> * If we have seen a tail call, we need a second pass.
> * This is because bpf_jit_emit_common_epilogue() is called
> * from bpf_jit_emit_tail_call() with a not yet stable ctx->seen.
> + * We also need a second pass if we ended up with too large
> + * a program so as to fix branches.
> */
> - if (cgctx.seen & SEEN_TAILCALL) {
> + if (cgctx.seen & (SEEN_TAILCALL | SEEN_BIG_PROG)) {
> cgctx.idx = 0;
> if (bpf_jit_build_body(fp, 0, &cgctx, addrs, false)) {
> fp = org_fp;
> diff --git a/arch/powerpc/net/bpf_jit_comp32.c b/arch/powerpc/net/bpf_jit_comp32.c
> index a74d52204f8da2..d2a67574a23066 100644
> --- a/arch/powerpc/net/bpf_jit_comp32.c
> +++ b/arch/powerpc/net/bpf_jit_comp32.c
> @@ -852,7 +852,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> * we'll just fall through to the epilogue.
> */
> if (i != flen - 1)
> - PPC_JMP(exit_addr);
> + bpf_jit_emit_exit_insn(image, ctx, tmp_reg, exit_addr);
On ppc32, if you use tmp_reg you must flag it. But I think you could use
r0 instead.
> /* else fall through to the epilogue */
> break;
>
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index f06c62089b1457..3351a866ef6207 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -761,7 +761,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> * we'll just fall through to the epilogue.
> */
> if (i != flen - 1)
> - PPC_JMP(exit_addr);
> + bpf_jit_emit_exit_insn(image, ctx, b2p[TMP_REG_1], exit_addr);
> /* else fall through to the epilogue */
> break;
>
>
^ permalink raw reply
* Re: [PATCH 3/9] powerpc/bpf: Remove unused SEEN_STACK
From: Christophe Leroy @ 2021-10-03 7:55 UTC (permalink / raw)
To: Naveen N. Rao, Michael Ellerman, Nicholas Piggin, Daniel Borkmann,
Alexei Starovoitov, Johan Almbladh
Cc: bpf, linuxppc-dev
In-Reply-To: <92fcd53a43dede52fbba52dc50c76042a6ce284c.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
Le 01/10/2021 à 23:14, Naveen N. Rao a écrit :
> From: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
>
> SEEN_STACK is unused on PowerPC. Remove it. Also, have
> SEEN_TAILCALL use 0x40000000.
Why change SEEN_TAILCALL ? Would it be a problem to leave it as is ?
>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/net/bpf_jit.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 7e9b978b768ed9..89bd744c2bffd4 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -125,8 +125,7 @@
> #define COND_LE (CR0_GT | COND_CMP_FALSE)
>
> #define SEEN_FUNC 0x20000000 /* might call external helpers */
> -#define SEEN_STACK 0x40000000 /* uses BPF stack */
> -#define SEEN_TAILCALL 0x80000000 /* uses tail calls */
> +#define SEEN_TAILCALL 0x40000000 /* uses tail calls */
>
> #define SEEN_VREG_MASK 0x1ff80000 /* Volatile registers r3-r12 */
> #define SEEN_NVREG_MASK 0x0003ffff /* Non volatile registers r14-r31 */
>
^ permalink raw reply
* Re: [PATCH 1/9] powerpc/lib: Add helper to check if offset is within conditional branch range
From: Christophe Leroy @ 2021-10-03 7:50 UTC (permalink / raw)
To: Naveen N. Rao, Michael Ellerman, Nicholas Piggin, Daniel Borkmann,
Alexei Starovoitov, Johan Almbladh
Cc: bpf, linuxppc-dev
In-Reply-To: <f8d581e6a5d9555180c38e009f90d236f310f85e.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
Le 01/10/2021 à 23:14, Naveen N. Rao a écrit :
> 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 <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/code-patching.h | 1 +
> arch/powerpc/lib/code-patching.c | 7 ++++++-
> arch/powerpc/net/bpf_jit.h | 7 +------
> 3 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/code-patching.h b/arch/powerpc/include/asm/code-patching.h
> index a95f63788c6b14..4ba834599c4d4c 100644
> --- a/arch/powerpc/include/asm/code-patching.h
> +++ b/arch/powerpc/include/asm/code-patching.h
> @@ -23,6 +23,7 @@
> #define BRANCH_ABSOLUTE 0x2
>
> bool is_offset_in_branch_range(long offset);
> +bool is_offset_in_cond_branch_range(long offset);
> int create_branch(struct ppc_inst *instr, const u32 *addr,
> unsigned long target, int flags);
> int create_cond_branch(struct ppc_inst *instr, const u32 *addr,
> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> index f9a3019e37b43c..e2342b9a1ab9c9 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -228,6 +228,11 @@ bool is_offset_in_branch_range(long offset)
> return (offset >= -0x2000000 && offset <= 0x1fffffc && !(offset & 0x3));
> }
>
> +bool is_offset_in_cond_branch_range(long offset)
> +{
> + return offset >= -0x8000 && offset <= 0x7FFF && !(offset & 0x3);
> +}
Would be better without capital letters in numbers, in extenso 0x7fff
instead of 0x7FFF
> +
> /*
> * Helper to check if a given instruction is a conditional branch
> * Derived from the conditional checks in analyse_instr()
> @@ -280,7 +285,7 @@ int create_cond_branch(struct ppc_inst *instr, const u32 *addr,
> offset = offset - (unsigned long)addr;
>
> /* Check we can represent the target in the instruction format */
> - if (offset < -0x8000 || offset > 0x7FFF || offset & 0x3)
> + if (!is_offset_in_cond_branch_range(offset))
> return 1;
>
> /* Mask out the flags and target, so they don't step on each other. */
> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 99fad093f43ec1..935ea95b66359e 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -78,11 +78,6 @@
> #define PPC_FUNC_ADDR(d,i) do { PPC_LI32(d, i); } while(0)
> #endif
>
> -static inline bool is_nearbranch(int offset)
> -{
> - return (offset < 32768) && (offset >= -32768);
> -}
> -
> /*
> * The fly in the ointment of code size changing from pass to pass is
> * avoided by padding the short branch case with a NOP. If code size differs
> @@ -91,7 +86,7 @@ static inline bool is_nearbranch(int offset)
> * state.
> */
> #define PPC_BCC(cond, dest) do { \
> - if (is_nearbranch((dest) - (ctx->idx * 4))) { \
> + if (is_offset_in_cond_branch_range((long)(dest) - (ctx->idx * 4))) { \
> PPC_BCC_SHORT(cond, dest); \
> EMIT(PPC_RAW_NOP()); \
> } else { \
>
^ permalink raw reply
* Re: [PATCH 2/9] powerpc/bpf: Validate branch ranges
From: Christophe Leroy @ 2021-10-03 7:54 UTC (permalink / raw)
To: Naveen N. Rao, Michael Ellerman, Nicholas Piggin, Daniel Borkmann,
Alexei Starovoitov, Johan Almbladh
Cc: bpf, linuxppc-dev
In-Reply-To: <d4a44c52712468b805cbf5c244b3c9ba0f802ab8.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
Le 01/10/2021 à 23:14, Naveen N. Rao a écrit :
> Add checks to ensure that we never emit branch instructions with
> truncated branch offsets.
>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/net/bpf_jit.h | 26 ++++++++++++++++++++------
> arch/powerpc/net/bpf_jit_comp.c | 6 +++++-
> arch/powerpc/net/bpf_jit_comp32.c | 8 ++++++--
> arch/powerpc/net/bpf_jit_comp64.c | 8 ++++++--
> 4 files changed, 37 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 935ea95b66359e..7e9b978b768ed9 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -24,16 +24,30 @@
> #define EMIT(instr) PLANT_INSTR(image, ctx->idx, instr)
>
> /* Long jump; (unconditional 'branch') */
> -#define PPC_JMP(dest) EMIT(PPC_INST_BRANCH | \
> - (((dest) - (ctx->idx * 4)) & 0x03fffffc))
> +#define PPC_JMP(dest) \
> + do { \
> + long offset = (long)(dest) - (ctx->idx * 4); \
> + if (!is_offset_in_branch_range(offset)) { \
> + pr_err_ratelimited("Branch offset 0x%lx (@%u) out of range\n", offset, ctx->idx); \
Does it really deserves a KERN_ERR ?
Isn't that something that can trigger with a userland request ?
> + return -ERANGE; \
> + } \
> + EMIT(PPC_INST_BRANCH | (offset & 0x03fffffc)); \
> + } while (0)
> +
> /* blr; (unconditional 'branch' with link) to absolute address */
> #define PPC_BL_ABS(dest) EMIT(PPC_INST_BL | \
> (((dest) - (unsigned long)(image + ctx->idx)) & 0x03fffffc))
> /* "cond" here covers BO:BI fields. */
> -#define PPC_BCC_SHORT(cond, dest) EMIT(PPC_INST_BRANCH_COND | \
> - (((cond) & 0x3ff) << 16) | \
> - (((dest) - (ctx->idx * 4)) & \
> - 0xfffc))
> +#define PPC_BCC_SHORT(cond, dest) \
> + do { \
> + long offset = (long)(dest) - (ctx->idx * 4); \
> + if (!is_offset_in_cond_branch_range(offset)) { \
> + pr_err_ratelimited("Conditional branch offset 0x%lx (@%u) out of range\n", offset, ctx->idx); \
Same
> + return -ERANGE; \
> + } \
> + EMIT(PPC_INST_BRANCH_COND | (((cond) & 0x3ff) << 16) | (offset & 0xfffc)); \
> + } while (0)
> +
> /* Sign-extended 32-bit immediate load */
> #define PPC_LI32(d, i) do { \
> if ((int)(uintptr_t)(i) >= -32768 && \
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index 53aefee3fe70be..fcbf7a917c566e 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -210,7 +210,11 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
> /* Now build the prologue, body code & epilogue for real. */
> cgctx.idx = 0;
> bpf_jit_build_prologue(code_base, &cgctx);
> - bpf_jit_build_body(fp, code_base, &cgctx, addrs, extra_pass);
> + if (bpf_jit_build_body(fp, code_base, &cgctx, addrs, extra_pass)) {
> + bpf_jit_binary_free(bpf_hdr);
> + fp = org_fp;
> + goto out_addrs;
> + }
> bpf_jit_build_epilogue(code_base, &cgctx);
>
> if (bpf_jit_enable > 1)
> diff --git a/arch/powerpc/net/bpf_jit_comp32.c b/arch/powerpc/net/bpf_jit_comp32.c
> index beb12cbc8c2994..a74d52204f8da2 100644
> --- a/arch/powerpc/net/bpf_jit_comp32.c
> +++ b/arch/powerpc/net/bpf_jit_comp32.c
> @@ -200,7 +200,7 @@ void bpf_jit_emit_func_call_rel(u32 *image, struct codegen_context *ctx, u64 fun
> }
> }
>
> -static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 out)
> +static int bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 out)
> {
> /*
> * By now, the eBPF program has already setup parameters in r3-r6
> @@ -261,7 +261,9 @@ static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32
> bpf_jit_emit_common_epilogue(image, ctx);
>
> EMIT(PPC_RAW_BCTR());
> +
> /* out: */
> + return 0;
> }
>
> /* Assemble the body code between the prologue & epilogue */
> @@ -1090,7 +1092,9 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> */
> case BPF_JMP | BPF_TAIL_CALL:
> ctx->seen |= SEEN_TAILCALL;
> - bpf_jit_emit_tail_call(image, ctx, addrs[i + 1]);
> + ret = bpf_jit_emit_tail_call(image, ctx, addrs[i + 1]);
> + if (ret < 0)
> + return ret;
> break;
>
> default:
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index b87a63dba9c8fb..f06c62089b1457 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -206,7 +206,7 @@ void bpf_jit_emit_func_call_rel(u32 *image, struct codegen_context *ctx, u64 fun
> EMIT(PPC_RAW_BCTRL());
> }
>
> -static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 out)
> +static int bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 out)
> {
> /*
> * By now, the eBPF program has already setup parameters in r3, r4 and r5
> @@ -267,7 +267,9 @@ static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32
> bpf_jit_emit_common_epilogue(image, ctx);
>
> EMIT(PPC_RAW_BCTR());
> +
> /* out: */
> + return 0;
> }
>
> /* Assemble the body code between the prologue & epilogue */
> @@ -993,7 +995,9 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> */
> case BPF_JMP | BPF_TAIL_CALL:
> ctx->seen |= SEEN_TAILCALL;
> - bpf_jit_emit_tail_call(image, ctx, addrs[i + 1]);
> + ret = bpf_jit_emit_tail_call(image, ctx, addrs[i + 1]);
> + if (ret < 0)
> + return ret;
> break;
>
> default:
>
^ permalink raw reply
* Re: [PATCH 0/9] powerpc/bpf: Various fixes
From: Johan Almbladh @ 2021-10-02 17:41 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Daniel Borkmann, Nicholas Piggin, bpf, linuxppc-dev,
Alexei Starovoitov
In-Reply-To: <cover.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, Oct 1, 2021 at 11:15 PM Naveen N. Rao
<naveen.n.rao@linux.vnet.ibm.com> wrote:
>
> 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.
Great work! I have tested it on powerpc64 in QEMU, which is the same
setup that previously triggered an illegal instruction, and all tests
pass now. On powerpc32 there are still some issues left as you say.
Thanks!
Johan
>
> - Naveen
>
>
> Naveen N. Rao (8):
> powerpc/lib: Add helper to check if offset is within conditional
> branch range
> powerpc/bpf: Validate branch ranges
> powerpc/bpf: Handle large branch ranges with BPF_EXIT
> powerpc/bpf: Fix BPF_MOD when imm == 1
> powerpc/bpf: Fix BPF_SUB when imm == 0x80000000
> powerpc/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06
> powerpc/security: Add a helper to query stf_barrier type
> powerpc/bpf: Emit stf barrier instruction sequences for BPF_NOSPEC
>
> Ravi Bangoria (1):
> powerpc/bpf: Remove unused SEEN_STACK
>
> arch/powerpc/include/asm/code-patching.h | 1 +
> arch/powerpc/include/asm/ppc-opcode.h | 1 +
> arch/powerpc/include/asm/security_features.h | 5 +
> arch/powerpc/kernel/security.c | 5 +
> arch/powerpc/lib/code-patching.c | 7 +-
> arch/powerpc/net/bpf_jit.h | 39 ++++---
> arch/powerpc/net/bpf_jit64.h | 8 +-
> arch/powerpc/net/bpf_jit_comp.c | 28 ++++-
> arch/powerpc/net/bpf_jit_comp32.c | 10 +-
> arch/powerpc/net/bpf_jit_comp64.c | 113 ++++++++++++++-----
> 10 files changed, 167 insertions(+), 50 deletions(-)
>
>
> base-commit: 044c2d99d9f43c6d6fde8bed00672517dd9a5a57
> --
> 2.33.0
>
^ permalink raw reply
* Re: [PATCH 7/9] powerpc/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06
From: Johan Almbladh @ 2021-10-02 17:35 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Daniel Borkmann, Nicholas Piggin, bpf, linuxppc-dev,
Alexei Starovoitov
In-Reply-To: <b7024b63a5501bbb67699da2345250deeea03d7e.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, Oct 1, 2021 at 11:15 PM Naveen N. Rao
<naveen.n.rao@linux.vnet.ibm.com> wrote:
>
> 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 tainted 5.14.0-03771-g98c2059e008a-dirty #1
> NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18
> REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty)
> MSR: 0000000080089000 <EE,ME> CR: 88002822 XER: 20000000 IRQMASK: 0
> <...>
> NIP [8000000000061c3c] 0x8000000000061c3c
> LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf]
> Call Trace:
> .__run_one+0x60/0x17c [test_bpf] (unreliable)
> .test_bpf_init+0x6a8/0xdc8 [test_bpf]
> .do_one_initcall+0x6c/0x28c
> .do_init_module+0x68/0x28c
> .load_module+0x2460/0x2abc
> .__do_sys_init_module+0x120/0x18c
> .system_call_exception+0x110/0x1b8
> system_call_common+0xf0/0x210
> --- interrupt: c00 at 0x101d0acc
> <...>
> ---[ end trace 47b2bf19090bb3d0 ]---
>
> Illegal instruction
>
> The illegal instruction turned out to be 'ldbrx' emitted for
> BPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of
> the same and implement an alternative approach for older processors.
>
> Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
> Reported-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
Tested-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 1 +
> arch/powerpc/net/bpf_jit_comp64.c | 22 +++++++++++++---------
> 2 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
> index baea657bc8687e..bca31a61e57f88 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -498,6 +498,7 @@
> #define PPC_RAW_LDX(r, base, b) (0x7c00002a | ___PPC_RT(r) | ___PPC_RA(base) | ___PPC_RB(b))
> #define PPC_RAW_LHZ(r, base, i) (0xa0000000 | ___PPC_RT(r) | ___PPC_RA(base) | IMM_L(i))
> #define PPC_RAW_LHBRX(r, base, b) (0x7c00062c | ___PPC_RT(r) | ___PPC_RA(base) | ___PPC_RB(b))
> +#define PPC_RAW_LWBRX(r, base, b) (0x7c00042c | ___PPC_RT(r) | ___PPC_RA(base) | ___PPC_RB(b))
> #define PPC_RAW_LDBRX(r, base, b) (0x7c000428 | ___PPC_RT(r) | ___PPC_RA(base) | ___PPC_RB(b))
> #define PPC_RAW_STWCX(s, a, b) (0x7c00012d | ___PPC_RS(s) | ___PPC_RA(a) | ___PPC_RB(b))
> #define PPC_RAW_CMPWI(a, i) (0x2c000000 | ___PPC_RA(a) | IMM_L(i))
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index 4641a50e82d50d..097d1ecfb9f562 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -601,17 +601,21 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> EMIT(PPC_RAW_MR(dst_reg, b2p[TMP_REG_1]));
> break;
> case 64:
> - /*
> - * Way easier and faster(?) to store the value
> - * into stack and then use ldbrx
> - *
> - * ctx->seen will be reliable in pass2, but
> - * the instructions generated will remain the
> - * same across all passes
> - */
> + /* Store the value to stack and then use byte-reverse loads */
> PPC_BPF_STL(dst_reg, 1, bpf_jit_stack_local(ctx));
> EMIT(PPC_RAW_ADDI(b2p[TMP_REG_1], 1, bpf_jit_stack_local(ctx)));
> - EMIT(PPC_RAW_LDBRX(dst_reg, 0, b2p[TMP_REG_1]));
> + if (cpu_has_feature(CPU_FTR_ARCH_206)) {
> + EMIT(PPC_RAW_LDBRX(dst_reg, 0, b2p[TMP_REG_1]));
> + } else {
> + EMIT(PPC_RAW_LWBRX(dst_reg, 0, b2p[TMP_REG_1]));
> + if (IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN))
> + EMIT(PPC_RAW_SLDI(dst_reg, dst_reg, 32));
> + EMIT(PPC_RAW_LI(b2p[TMP_REG_2], 4));
> + EMIT(PPC_RAW_LWBRX(b2p[TMP_REG_2], b2p[TMP_REG_2], b2p[TMP_REG_1]));
> + if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
> + EMIT(PPC_RAW_SLDI(b2p[TMP_REG_2], b2p[TMP_REG_2], 32));
> + EMIT(PPC_RAW_OR(dst_reg, dst_reg, b2p[TMP_REG_2]));
> + }
> break;
> }
> break;
> --
> 2.33.0
>
^ permalink raw reply
* Re: [PATCH 6/9] powerpc/bpf: Fix BPF_SUB when imm == 0x80000000
From: Johan Almbladh @ 2021-10-02 17:33 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Daniel Borkmann, Nicholas Piggin, bpf, linuxppc-dev,
Alexei Starovoitov
In-Reply-To: <1912a409447071f46ac6cc957ce8edea0e5232b7.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, Oct 1, 2021 at 11:15 PM Naveen N. Rao
<naveen.n.rao@linux.vnet.ibm.com> wrote:
>
> We aren't handling subtraction involving an immediate value of
> 0x80000000 properly. Fix the same.
>
> Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
Tested-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
> ---
> arch/powerpc/net/bpf_jit_comp64.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index ffb7a2877a8469..4641a50e82d50d 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -333,15 +333,15 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> case BPF_ALU | BPF_SUB | BPF_K: /* (u32) dst -= (u32) imm */
> case BPF_ALU64 | BPF_ADD | BPF_K: /* dst += imm */
> case BPF_ALU64 | BPF_SUB | BPF_K: /* dst -= imm */
> - if (BPF_OP(code) == BPF_SUB)
> - imm = -imm;
> - if (imm) {
> - if (imm >= -32768 && imm < 32768)
> - EMIT(PPC_RAW_ADDI(dst_reg, dst_reg, IMM_L(imm)));
> - else {
> - PPC_LI32(b2p[TMP_REG_1], imm);
> + if (imm > -32768 && imm < 32768) {
> + EMIT(PPC_RAW_ADDI(dst_reg, dst_reg,
> + BPF_OP(code) == BPF_SUB ? IMM_L(-imm) : IMM_L(imm)));
> + } else {
> + PPC_LI32(b2p[TMP_REG_1], imm);
> + if (BPF_OP(code) == BPF_SUB)
> + EMIT(PPC_RAW_SUB(dst_reg, dst_reg, b2p[TMP_REG_1]));
> + else
> EMIT(PPC_RAW_ADD(dst_reg, dst_reg, b2p[TMP_REG_1]));
> - }
> }
> goto bpf_alu32_trunc;
> case BPF_ALU | BPF_MUL | BPF_X: /* (u32) dst *= (u32) src */
> --
> 2.33.0
>
^ permalink raw reply
* Re: [PATCH 5/9] powerpc/bpf: Fix BPF_MOD when imm == 1
From: Johan Almbladh @ 2021-10-02 17:32 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Daniel Borkmann, Nicholas Piggin, bpf, linuxppc-dev,
Alexei Starovoitov
In-Reply-To: <8cb6a1725cf3c38ca90ed7f195f78a5b5a83bb25.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, Oct 1, 2021 at 11:15 PM Naveen N. Rao
<naveen.n.rao@linux.vnet.ibm.com> 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 <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
Tested-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
> ---
> arch/powerpc/net/bpf_jit_comp64.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index 3351a866ef6207..ffb7a2877a8469 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -391,8 +391,14 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> case BPF_ALU64 | BPF_DIV | BPF_K: /* dst /= imm */
> if (imm == 0)
> return -EINVAL;
> - else if (imm == 1)
> - goto bpf_alu32_trunc;
> + if (imm == 1) {
> + if (BPF_OP(code) == BPF_DIV) {
> + goto bpf_alu32_trunc;
> + } else {
> + EMIT(PPC_RAW_LI(dst_reg, 0));
> + break;
> + }
> + }
>
> PPC_LI32(b2p[TMP_REG_1], imm);
> switch (BPF_CLASS(code)) {
> --
> 2.33.0
>
^ permalink raw reply
* Re: [PATCH 4/9] powerpc/bpf: Handle large branch ranges with BPF_EXIT
From: Johan Almbladh @ 2021-10-02 17:31 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Daniel Borkmann, Nicholas Piggin, bpf, linuxppc-dev,
Alexei Starovoitov
In-Reply-To: <ebc0317ce465cb4f8d6fe485ab468ac5bda7c48f.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, Oct 1, 2021 at 11:15 PM Naveen N. Rao
<naveen.n.rao@linux.vnet.ibm.com> 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 initial run and do a second pass since BPF_EXIT can
> end up emitting different number of instructions depending on the
> program size.
>
> Suggested-by: Jordan Niethe <jniethe5@gmail.com>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
Tested-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
> ---
> arch/powerpc/net/bpf_jit.h | 3 +++
> arch/powerpc/net/bpf_jit_comp.c | 22 +++++++++++++++++++++-
> arch/powerpc/net/bpf_jit_comp32.c | 2 +-
> arch/powerpc/net/bpf_jit_comp64.c | 2 +-
> 4 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 89bd744c2bffd4..4023de1698b9f5 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -126,6 +126,7 @@
>
> #define SEEN_FUNC 0x20000000 /* might call external helpers */
> #define SEEN_TAILCALL 0x40000000 /* uses tail calls */
> +#define SEEN_BIG_PROG 0x80000000 /* large prog, >32MB */
>
> #define SEEN_VREG_MASK 0x1ff80000 /* Volatile registers r3-r12 */
> #define SEEN_NVREG_MASK 0x0003ffff /* Non volatile registers r14-r31 */
> @@ -179,6 +180,8 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> void bpf_jit_build_prologue(u32 *image, struct codegen_context *ctx);
> void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx);
> void bpf_jit_realloc_regs(struct codegen_context *ctx);
> +int bpf_jit_emit_exit_insn(u32 *image, struct codegen_context *ctx,
> + int tmp_reg, unsigned long exit_addr);
>
> #endif
>
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index fcbf7a917c566e..3204872fbf2738 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -72,6 +72,21 @@ static int bpf_jit_fixup_subprog_calls(struct bpf_prog *fp, u32 *image,
> return 0;
> }
>
> +int bpf_jit_emit_exit_insn(u32 *image, struct codegen_context *ctx,
> + int tmp_reg, unsigned long exit_addr)
> +{
> + if (!(ctx->seen & SEEN_BIG_PROG) && is_offset_in_branch_range(exit_addr)) {
> + PPC_JMP(exit_addr);
> + } else {
> + ctx->seen |= SEEN_BIG_PROG;
> + PPC_FUNC_ADDR(tmp_reg, (unsigned long)image + exit_addr);
> + EMIT(PPC_RAW_MTCTR(tmp_reg));
> + EMIT(PPC_RAW_BCTR());
> + }
> +
> + return 0;
> +}
> +
> struct powerpc64_jit_data {
> struct bpf_binary_header *header;
> u32 *addrs;
> @@ -155,12 +170,17 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
> goto out_addrs;
> }
>
> + if (!is_offset_in_branch_range((long)cgctx.idx * 4))
> + cgctx.seen |= SEEN_BIG_PROG;
> +
> /*
> * If we have seen a tail call, we need a second pass.
> * This is because bpf_jit_emit_common_epilogue() is called
> * from bpf_jit_emit_tail_call() with a not yet stable ctx->seen.
> + * We also need a second pass if we ended up with too large
> + * a program so as to fix branches.
> */
> - if (cgctx.seen & SEEN_TAILCALL) {
> + if (cgctx.seen & (SEEN_TAILCALL | SEEN_BIG_PROG)) {
> cgctx.idx = 0;
> if (bpf_jit_build_body(fp, 0, &cgctx, addrs, false)) {
> fp = org_fp;
> diff --git a/arch/powerpc/net/bpf_jit_comp32.c b/arch/powerpc/net/bpf_jit_comp32.c
> index a74d52204f8da2..d2a67574a23066 100644
> --- a/arch/powerpc/net/bpf_jit_comp32.c
> +++ b/arch/powerpc/net/bpf_jit_comp32.c
> @@ -852,7 +852,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> * we'll just fall through to the epilogue.
> */
> if (i != flen - 1)
> - PPC_JMP(exit_addr);
> + bpf_jit_emit_exit_insn(image, ctx, tmp_reg, exit_addr);
> /* else fall through to the epilogue */
> break;
>
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index f06c62089b1457..3351a866ef6207 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -761,7 +761,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> * we'll just fall through to the epilogue.
> */
> if (i != flen - 1)
> - PPC_JMP(exit_addr);
> + bpf_jit_emit_exit_insn(image, ctx, b2p[TMP_REG_1], exit_addr);
> /* else fall through to the epilogue */
> break;
>
> --
> 2.33.0
>
^ permalink raw reply
* Re: [PATCH 3/9] powerpc/bpf: Remove unused SEEN_STACK
From: Johan Almbladh @ 2021-10-02 17:30 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Daniel Borkmann, Nicholas Piggin, bpf, linuxppc-dev,
Alexei Starovoitov
In-Reply-To: <92fcd53a43dede52fbba52dc50c76042a6ce284c.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, Oct 1, 2021 at 11:15 PM Naveen N. Rao
<naveen.n.rao@linux.vnet.ibm.com> wrote:
>
> From: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
>
> SEEN_STACK is unused on PowerPC. Remove it. Also, have
> SEEN_TAILCALL use 0x40000000.
>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Acked-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
Tested-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
> ---
> arch/powerpc/net/bpf_jit.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 7e9b978b768ed9..89bd744c2bffd4 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -125,8 +125,7 @@
> #define COND_LE (CR0_GT | COND_CMP_FALSE)
>
> #define SEEN_FUNC 0x20000000 /* might call external helpers */
> -#define SEEN_STACK 0x40000000 /* uses BPF stack */
> -#define SEEN_TAILCALL 0x80000000 /* uses tail calls */
> +#define SEEN_TAILCALL 0x40000000 /* uses tail calls */
>
> #define SEEN_VREG_MASK 0x1ff80000 /* Volatile registers r3-r12 */
> #define SEEN_NVREG_MASK 0x0003ffff /* Non volatile registers r14-r31 */
> --
> 2.33.0
>
^ permalink raw reply
* Re: [PATCH 2/9] powerpc/bpf: Validate branch ranges
From: Johan Almbladh @ 2021-10-02 17:29 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Daniel Borkmann, Nicholas Piggin, bpf, linuxppc-dev,
Alexei Starovoitov
In-Reply-To: <d4a44c52712468b805cbf5c244b3c9ba0f802ab8.1633104510.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, Oct 1, 2021 at 11:15 PM Naveen N. Rao
<naveen.n.rao@linux.vnet.ibm.com> wrote:
>
> Add checks to ensure that we never emit branch instructions with
> truncated branch offsets.
>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
Tested-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
> ---
> arch/powerpc/net/bpf_jit.h | 26 ++++++++++++++++++++------
> arch/powerpc/net/bpf_jit_comp.c | 6 +++++-
> arch/powerpc/net/bpf_jit_comp32.c | 8 ++++++--
> arch/powerpc/net/bpf_jit_comp64.c | 8 ++++++--
> 4 files changed, 37 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 935ea95b66359e..7e9b978b768ed9 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -24,16 +24,30 @@
> #define EMIT(instr) PLANT_INSTR(image, ctx->idx, instr)
>
> /* Long jump; (unconditional 'branch') */
> -#define PPC_JMP(dest) EMIT(PPC_INST_BRANCH | \
> - (((dest) - (ctx->idx * 4)) & 0x03fffffc))
> +#define PPC_JMP(dest) \
> + do { \
> + long offset = (long)(dest) - (ctx->idx * 4); \
> + if (!is_offset_in_branch_range(offset)) { \
> + pr_err_ratelimited("Branch offset 0x%lx (@%u) out of range\n", offset, ctx->idx); \
> + return -ERANGE; \
> + } \
> + EMIT(PPC_INST_BRANCH | (offset & 0x03fffffc)); \
> + } while (0)
> +
> /* blr; (unconditional 'branch' with link) to absolute address */
> #define PPC_BL_ABS(dest) EMIT(PPC_INST_BL | \
> (((dest) - (unsigned long)(image + ctx->idx)) & 0x03fffffc))
> /* "cond" here covers BO:BI fields. */
> -#define PPC_BCC_SHORT(cond, dest) EMIT(PPC_INST_BRANCH_COND | \
> - (((cond) & 0x3ff) << 16) | \
> - (((dest) - (ctx->idx * 4)) & \
> - 0xfffc))
> +#define PPC_BCC_SHORT(cond, dest) \
> + do { \
> + long offset = (long)(dest) - (ctx->idx * 4); \
> + if (!is_offset_in_cond_branch_range(offset)) { \
> + pr_err_ratelimited("Conditional branch offset 0x%lx (@%u) out of range\n", offset, ctx->idx); \
> + return -ERANGE; \
> + } \
> + EMIT(PPC_INST_BRANCH_COND | (((cond) & 0x3ff) << 16) | (offset & 0xfffc)); \
> + } while (0)
> +
> /* Sign-extended 32-bit immediate load */
> #define PPC_LI32(d, i) do { \
> if ((int)(uintptr_t)(i) >= -32768 && \
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index 53aefee3fe70be..fcbf7a917c566e 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -210,7 +210,11 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
> /* Now build the prologue, body code & epilogue for real. */
> cgctx.idx = 0;
> bpf_jit_build_prologue(code_base, &cgctx);
> - bpf_jit_build_body(fp, code_base, &cgctx, addrs, extra_pass);
> + if (bpf_jit_build_body(fp, code_base, &cgctx, addrs, extra_pass)) {
> + bpf_jit_binary_free(bpf_hdr);
> + fp = org_fp;
> + goto out_addrs;
> + }
> bpf_jit_build_epilogue(code_base, &cgctx);
>
> if (bpf_jit_enable > 1)
> diff --git a/arch/powerpc/net/bpf_jit_comp32.c b/arch/powerpc/net/bpf_jit_comp32.c
> index beb12cbc8c2994..a74d52204f8da2 100644
> --- a/arch/powerpc/net/bpf_jit_comp32.c
> +++ b/arch/powerpc/net/bpf_jit_comp32.c
> @@ -200,7 +200,7 @@ void bpf_jit_emit_func_call_rel(u32 *image, struct codegen_context *ctx, u64 fun
> }
> }
>
> -static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 out)
> +static int bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 out)
> {
> /*
> * By now, the eBPF program has already setup parameters in r3-r6
> @@ -261,7 +261,9 @@ static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32
> bpf_jit_emit_common_epilogue(image, ctx);
>
> EMIT(PPC_RAW_BCTR());
> +
> /* out: */
> + return 0;
> }
>
> /* Assemble the body code between the prologue & epilogue */
> @@ -1090,7 +1092,9 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> */
> case BPF_JMP | BPF_TAIL_CALL:
> ctx->seen |= SEEN_TAILCALL;
> - bpf_jit_emit_tail_call(image, ctx, addrs[i + 1]);
> + ret = bpf_jit_emit_tail_call(image, ctx, addrs[i + 1]);
> + if (ret < 0)
> + return ret;
> break;
>
> default:
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index b87a63dba9c8fb..f06c62089b1457 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -206,7 +206,7 @@ void bpf_jit_emit_func_call_rel(u32 *image, struct codegen_context *ctx, u64 fun
> EMIT(PPC_RAW_BCTRL());
> }
>
> -static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 out)
> +static int bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 out)
> {
> /*
> * By now, the eBPF program has already setup parameters in r3, r4 and r5
> @@ -267,7 +267,9 @@ static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32
> bpf_jit_emit_common_epilogue(image, ctx);
>
> EMIT(PPC_RAW_BCTR());
> +
> /* out: */
> + return 0;
> }
>
> /* Assemble the body code between the prologue & epilogue */
> @@ -993,7 +995,9 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> */
> case BPF_JMP | BPF_TAIL_CALL:
> ctx->seen |= SEEN_TAILCALL;
> - bpf_jit_emit_tail_call(image, ctx, addrs[i + 1]);
> + ret = bpf_jit_emit_tail_call(image, ctx, addrs[i + 1]);
> + if (ret < 0)
> + return ret;
> break;
>
> default:
> --
> 2.33.0
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox