Re: [PATCH v3 bpf-next 08/19] bpf: insert explicit zero extension insn when hardware doesn't do it implicitly

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

 



> On 15 Apr 2019, at 19:21, Naveen N. Rao <naveen.n.rao@xxxxxxxxxxxxxxxxxx> wrote:
> 
> Jiong Wang wrote:
>> It will be great if you could test the latest set on PowerPC to see if
>> there is any regression for example for those under test_progs and
>> test_verifier.
> 
> With test_bpf, I am seeing a few failures with this patchset.
> 
>> And it will be even greater if you also use latest llvm snapshot for the
>> testing, which then will enable test_progs_32 etc.
> 
> Is a newer llvm a dependency? Or, is this also expected to work with older llvm levels?

There is no newer LLVM dependency. This set should work with older llvm.        
                                                                                
It is just newer LLVM has better sub-register code-gen support that could       
the generate bpf program contains more elimination opportunities for verifier.

> 
> The set of tests that are failing are listed further below. I looked into MUL_X2 and it looks like zero extension for the two initial ALU32 loads (-1) are being removed, resulting in the failure.
> 
> I didn't get to look into this in detail -- am I missing something?

Hmm, I guess the issue is:
                                                                                
  1. test_bpf.c is a testsuite running inside kernel space, it is calling some
     kernel eBPF jit interface directly without calling verifier first, so this
     set actually hasn’t been triggered.

  2. However, the elimination information at the moment is passed from verifier
     to JIT backend through

       fp->aux->no_verifier_zext

     “no_verifier_zext” is initially false, and once verifier inserted zero
     extension, it will be set to true.

     Now, for test_bpf, because it doesn’t go through verifier at all, so
     “no_verifier_zext” is left at default value which is false, meaning
     verifier has inserted zero-extension, so PPC backend then thinks it is
     safe to eliminate zero-extension by himself.

     Perhaps should change “no_verifier_zext” to “verifier_zext”, then default
     is false and will only be true when verifier really has inserted zext.
      
     Was thinking, this will cause JIT backend writing the check like
        if (no_verifier_zext)
          insert_zext_by_JIT
     
     is better than:
        
        if (!verifier_zext)
          insert_zext_by_JIT

BTW, does test_progs and test_verifier has a full pass on PowerPC?
On arch without hardware zext like PowerPC, verifier will insert zext and test
mode will still randomisation high 32-bit for those sub-registers not zext,
this is very stressful test.

Regards,
Jiong

> 
> 
> - Naveen
> 
> 
> ---
> $ cat ~/jit_fail.out | grep -v "JIT code" | grep -B4 FAIL
> test_bpf: #38 INT: MUL_X2 Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=9 proglen=64 pass=3 image=d000000006bfca9c from=insmod pid=8923
> jited:1 ret -1 != 1 FAIL (1 times)
> test_bpf: #39 INT: MUL32_X Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=9 proglen=64 pass=3 image=d000000006c335fc from=insmod pid=8923
> jited:1 ret -1 != 1 FAIL (1 times)
> 
> test_bpf: #49 INT: shifts by register Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=30 proglen=192 pass=3 image=d000000006eb80e4 from=insmod pid=8923
> jited:1 ret -1234 != -1 FAIL (1 times)
> 
> test_bpf: #68 ALU_MOV_K: 0x0000ffffffff0000 = 0x00000000ffffffff Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=10 proglen=76 pass=3 image=d000000007290e48 from=insmod pid=8923
> jited:1 ret 2 != 1 FAIL (1 times)
> 
> test_bpf: #75 ALU_ADD_X: 2 + 4294967294 = 0 Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=10 proglen=64 pass=3 image=d0000000074537b0 from=insmod pid=8923
> jited:1 ret 0 != 1 FAIL (1 times)
> 
> test_bpf: #82 ALU_ADD_K: 4294967294 + 2 = 0 Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=8 proglen=60 pass=3 image=d00000000761af8c from=insmod pid=8923
> jited:1 ret 0 != 1 FAIL (1 times)
> test_bpf: #83 ALU_ADD_K: 0 + (-1) = 0x00000000ffffffff Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=10 proglen=64 pass=3 image=d0000000076579dc from=insmod pid=8923
> jited:1 ret 2 != 1 FAIL (1 times)
> 
> test_bpf: #86 ALU_ADD_K: 0 + 0x80000000 = 0x80000000 Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=10 proglen=64 pass=3 image=d000000007719958 from=insmod pid=8923
> jited:1 ret 2 != 1 FAIL (1 times)
> test_bpf: #87 ALU_ADD_K: 0 + 0x80008000 = 0x80008000 Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=10 proglen=72 pass=3 image=d000000007752510 from=insmod pid=8923
> jited:1 ret 2 != 1 FAIL (1 times)
> 
> test_bpf: #118 ALU_MUL_K: 1 * (-1) = 0x00000000ffffffff Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=10 proglen=64 pass=3 image=d000000007f184f8 from=insmod pid=8923
> jited:1 ret 2 != 1 FAIL (1 times)
> 
> test_bpf: #371 JNE signed compare, test 1 Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=8 proglen=60 pass=3 image=d000000002394ab8 from=insmod pid=8923
> jited:1 ret 2 != 1 FAIL (1 times)
> test_bpf: #372 JNE signed compare, test 2 Pass 1: shrink = 0, seen = 0x0
> Pass 2: shrink = 0, seen = 0x0
> flen=8 proglen=60 pass=3 image=d0000000023d98b4 from=insmod pid=8923
> jited:1 ret 2 != 1 FAIL (1 times)
> 
> Pass 1: shrink = 0, seen = 0x18
> Pass 2: shrink = 0, seen = 0x18
> flen=13 proglen=92 pass=3 image=d0000000025105f8 from=insmod pid=8923
> jited:1 12 PASS
> test_bpf: Summary: 366 PASSED, 12 FAILED, [366/366 JIT'ed]
> 
> 
> 





[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