Turns out that on some professional distributions, with things partly
backported (not sure exactly), loading this kernel bpf program might
enter a RCU task deadlock.
Given that it actually does not make sense to preload this in every
environment, we can lazy load it the first time we need it, i.e. the
first time the kfunc hid_bpf_attach_prog() is called.
Cc: stable@xxxxxxxxxxxxxxx
Signed-off-by: Benjamin Tissoires <bentiss@xxxxxxxxxx>
---
drivers/hid/bpf/hid_bpf_dispatch.c | 6 ------
drivers/hid/bpf/hid_bpf_jmp_table.c | 7 +++++++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index 10289f44d0cc..1946ad962d03 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -642,12 +642,6 @@ static int __init hid_bpf_init(void)
return 0;
}
- err = hid_bpf_preload_skel();
- if (err) {
- pr_warn("error while preloading HID BPF dispatcher: %d", err);
- return 0;
- }
-
/* register tracing kfuncs after we are sure we can load our preloaded bpf program */
err = register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, &hid_bpf_kfunc_set);
if (err) {
diff --git a/drivers/hid/bpf/hid_bpf_jmp_table.c b/drivers/hid/bpf/hid_bpf_jmp_table.c
index 301ac79db241..75ce215f0ada 100644
--- a/drivers/hid/bpf/hid_bpf_jmp_table.c
+++ b/drivers/hid/bpf/hid_bpf_jmp_table.c
@@ -404,6 +404,13 @@ __hid_bpf_attach_prog(struct hid_device *hdev, enum hid_bpf_prog_type prog_type,
mutex_lock(&hid_bpf_attach_lock);
+ if (!jmp_table.map) {
+ err = hid_bpf_preload_skel();
+ WARN_ONCE(err, "error while preloading HID BPF dispatcher: %d", err);
+ if (err)
+ goto err_unlock;
+ }
+
link = kzalloc(sizeof(*link), GFP_USER);
if (!link) {
err = -ENOMEM;
--
2.44.0
