Re: [PATCH bpf-next] bpf: x86: Explicitly zero-extend rax after 32-bit cmpxchg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 15, 2021 at 11:42 PM Ilya Leoshkevich <iii@xxxxxxxxxxxxx> wrote:
>

[...]

> > > >
> > > > How does the situation look on other archs when they need to
> > > > implement this in future?
> > > > Mainly asking whether it would be better to instead to move this
> > > > logic into the verifier
> > > > instead, so it'll be consistent across all archs.
> > >
> > > I have exactly the same check in my s390 wip patch.
> > > So having a common solution would be great.
> >
> > We do rewrites for various cases like div/mod handling, perhaps would
> > be
> > best to emit an explicit BPF_MOV32_REG(insn->dst_reg, insn->dst_reg)
> > there,
> > see the fixup_bpf_calls().

Agreed, this would be better.

>
> How about BPF_ZEXT_REG? Then arches that don't need this (I think
> aarch64's instruction always zero-extends) can detect this using
> insn_is_zext() and skip such insns.
>

+1



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux