2022-11-30 10:42:59

by Benjamin Tissoires

[permalink] [raw]
Subject: [PATCH 1/2] HID: bpf: enforce HID_BPF dependencies

As mentioned in the link below, having JIT and BPF is not enough to
have fmod_ret and error injection APIs. This resolves the error that
happens on a system without tracing enabled when hid-bpf tries to
load itself.

Link: https://lore.kernel.org/r/CABRcYmKyRchQhabi1Vd9RcMQFCcb=EtWyEbFDFRTc-L-U8WhgA@mail.gmail.com
Fixes: f5c27da4e3c8 ("HID: initial BPF implementation")
Signed-off-by: Benjamin Tissoires <[email protected]>
---
drivers/hid/bpf/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/bpf/Kconfig b/drivers/hid/bpf/Kconfig
index 298634fc3335..498232f9faa9 100644
--- a/drivers/hid/bpf/Kconfig
+++ b/drivers/hid/bpf/Kconfig
@@ -4,7 +4,9 @@ menu "HID-BPF support"
config HID_BPF
bool "HID-BPF support"
default HID_SUPPORT
- depends on BPF && BPF_SYSCALL
+ depends on BPF && BPF_SYSCALL && \
+ DYNAMIC_FTRACE_WITH_DIRECT_CALLS && \
+ FUNCTION_ERROR_INJECTION
help
This option allows to support eBPF programs on the HID subsystem.
eBPF programs can fix HID devices in a lighter way than a full
--
2.38.1


2022-12-01 14:43:33

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 1/2] HID: bpf: enforce HID_BPF dependencies


On 30/11/2022 10:10, Benjamin Tissoires wrote:
> As mentioned in the link below, having JIT and BPF is not enough to
> have fmod_ret and error injection APIs. This resolves the error that
> happens on a system without tracing enabled when hid-bpf tries to
> load itself.
>
> Link: https://lore.kernel.org/r/CABRcYmKyRchQhabi1Vd9RcMQFCcb=EtWyEbFDFRTc-L-U8WhgA@mail.gmail.com
> Fixes: f5c27da4e3c8 ("HID: initial BPF implementation")
> Signed-off-by: Benjamin Tissoires <[email protected]>
> ---
> drivers/hid/bpf/Kconfig | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/bpf/Kconfig b/drivers/hid/bpf/Kconfig
> index 298634fc3335..498232f9faa9 100644
> --- a/drivers/hid/bpf/Kconfig
> +++ b/drivers/hid/bpf/Kconfig
> @@ -4,7 +4,9 @@ menu "HID-BPF support"
> config HID_BPF
> bool "HID-BPF support"
> default HID_SUPPORT
> - depends on BPF && BPF_SYSCALL
> + depends on BPF && BPF_SYSCALL && \
> + DYNAMIC_FTRACE_WITH_DIRECT_CALLS && \
> + FUNCTION_ERROR_INJECTION
> help
> This option allows to support eBPF programs on the HID subsystem.
> eBPF programs can fix HID devices in a lighter way than a full


This fixes it for me!

Tested-by: Jon Hunter <[email protected]>

Thanks!
Jon

--
nvpublic

2022-12-02 01:40:27

by Jiri Kosina

[permalink] [raw]
Subject: Re: [PATCH 1/2] HID: bpf: enforce HID_BPF dependencies

On Wed, 30 Nov 2022, Benjamin Tissoires wrote:

> As mentioned in the link below, having JIT and BPF is not enough to
> have fmod_ret and error injection APIs. This resolves the error that
> happens on a system without tracing enabled when hid-bpf tries to
> load itself.
>
> Link: https://lore.kernel.org/r/CABRcYmKyRchQhabi1Vd9RcMQFCcb=EtWyEbFDFRTc-L-U8WhgA@mail.gmail.com
> Fixes: f5c27da4e3c8 ("HID: initial BPF implementation")
> Signed-off-by: Benjamin Tissoires <[email protected]>
> ---
> drivers/hid/bpf/Kconfig | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/bpf/Kconfig b/drivers/hid/bpf/Kconfig
> index 298634fc3335..498232f9faa9 100644
> --- a/drivers/hid/bpf/Kconfig
> +++ b/drivers/hid/bpf/Kconfig
> @@ -4,7 +4,9 @@ menu "HID-BPF support"
> config HID_BPF
> bool "HID-BPF support"
> default HID_SUPPORT
> - depends on BPF && BPF_SYSCALL
> + depends on BPF && BPF_SYSCALL && \
> + DYNAMIC_FTRACE_WITH_DIRECT_CALLS && \
> + FUNCTION_ERROR_INJECTION

FUNCTION_ERROR_INJECTION is a purely debugging feature, and not something
we want to have enabled in production kernels (which is where HID-BPF
should, on the other hand, be enabled). I am afraid this needs to go back
to the drawing board.

JFTR, to make sure this gets properly discussed before 6.2 merge window
opens up

Nacked-by: Jiri Kosina <[email protected]>

Which unfortunately means the whole hid-bpf implementation would need to
be revised and postponed for 6.3 at least.

Sorry,

--
Jiri Kosina
SUSE Labs