mbox series

[HID,for-next,v2,0/9] HID-BPF LLVM fixes, no more hacks

Message ID 20230113090935.1763477-1-benjamin.tissoires@redhat.com
Headers show
Series HID-BPF LLVM fixes, no more hacks | expand

Message

Benjamin Tissoires Jan. 13, 2023, 9:09 a.m. UTC 
Hi,

So this is the fix for the bug that actually prevented me to integrate
HID-BPF in v6.2.

While testing the code base with LLVM, I realized that clang was smarter
than I expected it to be, and it sometimes inlined a function or not
depending on the branch. This lead to segfaults because my current code
in linux-next is messing up the bpf programs refcounts assuming that I
had enough observability over the kernel.

So I came back to the drawing board and realized that what I was missing
was exactly a bpf_link, to represent the attachment of a bpf program to
a HID device. This is the bulk of the series, in patch 6/9.

The other patches are cleanups, tests, and also the addition of the
vmtests.sh script I run locally, largely inspired by the one in the bpf
selftests dir. This allows very fast development of HID-BPF, assuming we
have tests that cover the bugs :)


changes in v2:
- took Alexei's remarks into account and renamed the indexes into
  prog_table_index and hid_table_index
- fixed unused function as reported by the Intel kbuild bot


Cheers,
Benjamin


Benjamin Tissoires (9):
  selftests: hid: add vmtest.sh
  selftests: hid: allow to compile hid_bpf with LLVM
  selftests: hid: attach/detach 2 bpf programs, not just one
  selftests: hid: ensure the program is correctly pinned
  selftests: hid: prepare tests for HID_BPF API change
  HID: bpf: rework how programs are attached and stored in the kernel
  selftests: hid: enforce new attach API
  HID: bpf: clean up entrypoint
  HID: bpf: reorder BPF registration

 Documentation/hid/hid-bpf.rst                 |  12 +-
 drivers/hid/bpf/entrypoints/entrypoints.bpf.c |   9 -
 .../hid/bpf/entrypoints/entrypoints.lskel.h   | 188 ++++--------
 drivers/hid/bpf/hid_bpf_dispatch.c            |  28 +-
 drivers/hid/bpf/hid_bpf_dispatch.h            |   3 -
 drivers/hid/bpf/hid_bpf_jmp_table.c           | 129 ++++----
 include/linux/hid_bpf.h                       |   7 +
 tools/testing/selftests/hid/.gitignore        |   1 +
 tools/testing/selftests/hid/Makefile          |  10 +-
 tools/testing/selftests/hid/config.common     | 241 +++++++++++++++
 tools/testing/selftests/hid/config.x86_64     |   4 +
 tools/testing/selftests/hid/hid_bpf.c         |  32 +-
 tools/testing/selftests/hid/progs/hid.c       |  13 +
 tools/testing/selftests/hid/vmtest.sh         | 284 ++++++++++++++++++
 14 files changed, 728 insertions(+), 233 deletions(-)
 create mode 100644 tools/testing/selftests/hid/config.common
 create mode 100644 tools/testing/selftests/hid/config.x86_64
 create mode 100755 tools/testing/selftests/hid/vmtest.sh

Comments

Alexei Starovoitov Jan. 15, 2023, 5:59 p.m. UTC | #1 
On Fri, Jan 13, 2023 at 10:09:32AM +0100, Benjamin Tissoires wrote:
> Previously, HID-BPF was relying on a bpf tracing program to be notified
> when a program was released from userspace. This is error prone, as
> LLVM sometimes inline the function and sometimes not.
> 
> So instead of messing up with the bpf prog ref count, we can use the
> bpf_link concept which actually matches exactly what we want:
> - a bpf_link represents the fact that a given program is attached to a
>   given HID device
> - as long as the bpf_link has fd opened (either by the userspace program
>   still being around or by pinning the bpf object in the bpffs), the
>   program stays attached to the HID device
> - once every user has closed the fd, we get called by
>   hid_bpf_link_release() that we no longer have any users, and we can
>   disconnect the program to the device in 2 passes: first atomically clear
>   the bit saying that the link is active, and then calling release_work in
>   a scheduled work item.
> 
> This solves entirely the problems of BPF tracing not showing up and is
> definitely cleaner.
> 
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

Acked-by: Alexei Starovoitov <ast@kernel.org>
Alexei Starovoitov Jan. 15, 2023, 6 p.m. UTC | #2 
On Fri, Jan 13, 2023 at 10:09:34AM +0100, Benjamin Tissoires wrote:
> We don't need to watch for calls on bpf_prog_put_deferred(), so remove
> that from the entrypoints.bpf.c file.
> 
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

Acked-by: Alexei Starovoitov <ast@kernel.org>
Jiri Kosina Jan. 18, 2023, 9:12 p.m. UTC | #3 
On Fri, 13 Jan 2023, Benjamin Tissoires wrote:

> Hi,
> 
> So this is the fix for the bug that actually prevented me to integrate
> HID-BPF in v6.2.
> 
> While testing the code base with LLVM, I realized that clang was smarter
> than I expected it to be, and it sometimes inlined a function or not
> depending on the branch. This lead to segfaults because my current code
> in linux-next is messing up the bpf programs refcounts assuming that I
> had enough observability over the kernel.
> 
> So I came back to the drawing board and realized that what I was missing
> was exactly a bpf_link, to represent the attachment of a bpf program to
> a HID device. This is the bulk of the series, in patch 6/9.
> 
> The other patches are cleanups, tests, and also the addition of the
> vmtests.sh script I run locally, largely inspired by the one in the bpf
> selftests dir. This allows very fast development of HID-BPF, assuming we
> have tests that cover the bugs :)
> 
> 
> changes in v2:
> - took Alexei's remarks into account and renamed the indexes into
>   prog_table_index and hid_table_index
> - fixed unused function as reported by the Intel kbuild bot

I've now applied this on top of the previous work in 
hid.git#for-6.3/hid-bpf