Merge branch 'error checking where helpers call bpf_map_ops'
authorAlexei Starovoitov <ast@kernel.org>
Wed, 22 Mar 2023 22:11:07 +0000 (15:11 -0700)
committerAlexei Starovoitov <ast@kernel.org>
Wed, 22 Mar 2023 22:12:03 +0000 (15:12 -0700)
JP Kobryn says:

====================

Within bpf programs, the bpf helper functions can make inline calls to
kernel functions. In this scenario there can be a disconnect between the
register the kernel function writes a return value to and the register the
bpf program uses to evaluate that return value.

As an example, this bpf code:

long err = bpf_map_update_elem(...);
if (err && err != -EEXIST)
// got some error other than -EEXIST

...can result in the bpf assembly:

; err = bpf_map_update_elem(&mymap, &key, &val, BPF_NOEXIST);
  37: movabs $0xffff976a10730400,%rdi
  41: mov    $0x1,%ecx
  46: call   0xffffffffe103291c ; htab_map_update_elem
; if (err && err != -EEXIST) {
  4b: cmp    $0xffffffffffffffef,%rax ; cmp -EEXIST,%rax
  4f: je     0x000000000000008e
  51: test   %rax,%rax
  54: je     0x000000000000008e

The compare operation here evaluates %rax, while in the preceding call to
htab_map_update_elem the corresponding assembly returns -EEXIST via %eax
(the lower 32 bits of %rax):

movl $0xffffffef, %r9d
...
movl %r9d, %eax

...since it's returning int (32-bit). So the resulting comparison becomes:

cmp $0xffffffffffffffef, $0x00000000ffffffef

...making it not possible to check for negative errors or specific errors,
since the sign value is left at the 32nd bit. It means in the original
example, the conditional branch will be entered even when the error is
-EEXIST, which was not intended.

The selftests added cover these cases for the different bpf_map_ops
functions. When the second patch is applied, changing the return type of
those functions to long, the comparison works as intended and the tests
pass.
====================

Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Trivial merge