| Message ID | 20230912224654.6556-6-puranjay12@gmail.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | bpf: verifier: stop emitting zext for LDX | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/cover_letter | success | Series has a cover letter |
| conchuod/tree_selection | success | Guessed tree name to be for-next at HEAD 0bb80ecc33a8 |
| conchuod/fixes_present | success | Fixes tag not required for -next series |
| conchuod/maintainers_pattern | success | MAINTAINERS pattern errors before the patch: 5 and now 5 |
| conchuod/verify_signedoff | success | Signed-off-by tag matches author and committer |
| conchuod/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| conchuod/build_rv64_clang_allmodconfig | success | Errors and warnings before: 9 this patch: 9 |
| conchuod/module_param | success | Was 0 now: 0 |
| conchuod/build_rv64_gcc_allmodconfig | success | Errors and warnings before: 9 this patch: 9 |
| conchuod/build_rv32_defconfig | success | Build OK |
| conchuod/dtb_warn_rv64 | success | Errors and warnings before: 25 this patch: 25 |
| conchuod/header_inline | success | No static functions without inline keyword in header files |
| conchuod/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 23 lines checked |
| conchuod/build_rv64_nommu_k210_defconfig | success | Build OK |
| conchuod/verify_fixes | success | No Fixes tag |
| conchuod/build_rv64_nommu_virt_defconfig | success | Build OK |
On Tue, Sep 12, 2023 at 10:46:53PM +0000, Puranjay Mohan wrote: > The JITs should not depend on the verifier for zero extending the upper > 32 bits of the destination register when loading a byte, half-word, or > word. > > A following patch will make the verifier stop patching zext instructions > after LDX. This was introduced by: 163541e6ba34 ("arm: bpf: eliminate zero extension code-gen") along with an additional function. So three points: 1) the commit should probably explain why it has now become undesirable to access this verifier state, whereas it appears it was explicitly added to permit this optimisation. 2) you state that jits should not depend on this state, but the above commit adds more references than you're removing, so aren't there still references to the verifier remaining after this patch? I count a total of 10, and the patch below removes three. 3) what about the bpf_jit_needs_zext() function that was added to support the export of this zext state? Essentially, the logic stated in the commit message doesn't seem to be reflected by the proposed code change.
On Wed, Sep 13, 2023 at 1:04 AM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Tue, Sep 12, 2023 at 10:46:53PM +0000, Puranjay Mohan wrote: > > The JITs should not depend on the verifier for zero extending the upper > > 32 bits of the destination register when loading a byte, half-word, or > > word. > > > > A following patch will make the verifier stop patching zext instructions > > after LDX. > > This was introduced by: > > 163541e6ba34 ("arm: bpf: eliminate zero extension code-gen") > > along with an additional function. So three points: > > 1) the commit should probably explain why it has now become undesirable > to access this verifier state, whereas it appears it was explicitly > added to permit this optimisation. I added some details in the cover letter. For the complete discussion see: [1] > 2) you state that jits should not depend on this state, but the above > commit adds more references than you're removing, so aren't there still > references to the verifier remaining after this patch? I count a total > of 10, and the patch below removes three. The JITs should not depend on this state for LDX (loading a B/H/W. This patch removes the usage only for LDX. > 3) what about the bpf_jit_needs_zext() function that was added to > support the export of this zext state? That is still applicable, The verifier will still emit zext instructions for other instructions like BPF_ALU / BPF_ALU64 > > Essentially, the logic stated in the commit message doesn't seem to be > reflected by the proposed code change. I will try to provide more information. Currently I have asked Alexei if we really need this in [2]. I still think this optimization is useful and we should keep it. Thanks, Puranjay [1] https://lore.kernel.org/all/CANk7y0j2f-gPgZwd+YfTL71-6wfvky+f=kBC_ccqsS0EHAysyA@mail.gmail.com/ [2] https://lore.kernel.org/bpf/CANk7y0hK9sQJ-kRx3nQpVJSxpP=NzzFaLitOYq8=Pb6Dvk9fpg@mail.gmail.com/
On Tue, Sep 12, 2023 at 4:17 PM Puranjay Mohan <puranjay12@gmail.com> wrote: > > On Wed, Sep 13, 2023 at 1:04 AM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > On Tue, Sep 12, 2023 at 10:46:53PM +0000, Puranjay Mohan wrote: > > > The JITs should not depend on the verifier for zero extending the upper > > > 32 bits of the destination register when loading a byte, half-word, or > > > word. > > > > > > A following patch will make the verifier stop patching zext instructions > > > after LDX. > > > > This was introduced by: > > > > 163541e6ba34 ("arm: bpf: eliminate zero extension code-gen") > > > > along with an additional function. So three points: > > > > 1) the commit should probably explain why it has now become undesirable > > to access this verifier state, whereas it appears it was explicitly > > added to permit this optimisation. > > I added some details in the cover letter. > > For the complete discussion see: [1] > > > 2) you state that jits should not depend on this state, but the above > > commit adds more references than you're removing, so aren't there still > > references to the verifier remaining after this patch? I count a total > > of 10, and the patch below removes three. > > The JITs should not depend on this state for LDX (loading > a B/H/W. > This patch removes the usage only for LDX. > > > 3) what about the bpf_jit_needs_zext() function that was added to > > support the export of this zext state? > > That is still applicable, The verifier will still emit zext > instructions for other > instructions like BPF_ALU / BPF_ALU64 > > > > > Essentially, the logic stated in the commit message doesn't seem to be > > reflected by the proposed code change. > > I will try to provide more information. > Currently I have asked Alexei if we really need this in [2]. > I still think this optimization is useful and we should keep it. Right. subreg tracking is indeed functional for narrow loads. Let's drop this patch set.
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c index 6a1c9fca5260..757a99febba5 100644 --- a/arch/arm/net/bpf_jit_32.c +++ b/arch/arm/net/bpf_jit_32.c @@ -1081,20 +1081,17 @@ static inline void emit_ldx_r(const s8 dst[], const s8 src, case BPF_B: /* Load a Byte */ emit(ARM_LDRB_I(rd[1], rm, off), ctx); - if (!ctx->prog->aux->verifier_zext) - emit_a32_mov_i(rd[0], 0, ctx); + emit_a32_mov_i(rd[0], 0, ctx); break; case BPF_H: /* Load a HalfWord */ emit(ARM_LDRH_I(rd[1], rm, off), ctx); - if (!ctx->prog->aux->verifier_zext) - emit_a32_mov_i(rd[0], 0, ctx); + emit_a32_mov_i(rd[0], 0, ctx); break; case BPF_W: /* Load a Word */ emit(ARM_LDR_I(rd[1], rm, off), ctx); - if (!ctx->prog->aux->verifier_zext) - emit_a32_mov_i(rd[0], 0, ctx); + emit_a32_mov_i(rd[0], 0, ctx); break; case BPF_DW: /* Load a Double Word */
The JITs should not depend on the verifier for zero extending the upper 32 bits of the destination register when loading a byte, half-word, or word. A following patch will make the verifier stop patching zext instructions after LDX. Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> --- arch/arm/net/bpf_jit_32.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)