diff options
author | Benjamin Tissoires <bentiss@kernel.org> | 2024-06-26 16:46:26 +0300 |
---|---|---|
committer | Benjamin Tissoires <bentiss@kernel.org> | 2024-06-27 12:00:12 +0300 |
commit | 75839101ce52e319cb2154a027d14f1f0aa3be09 (patch) | |
tree | 37b05cb095474429cd80940e2c7b2e6d6d3a92a7 /drivers/clk/analogbits | |
parent | 8bd0488b5ea58655ad6fdcbe0408ef49b16882b1 (diff) | |
download | linux-75839101ce52e319cb2154a027d14f1f0aa3be09.tar.xz |
HID: bpf: prevent infinite recursions with hid_hw_raw_requests hooks
When we attach a sleepable hook to hid_hw_raw_requests, we can (and in
many cases should) call ourself hid_bpf_raw_request(), to actually fetch
data from the device itself.
However, this means that we might enter an infinite loop between
hid_hw_raw_requests hooks and hid_bpf_hw_request() call.
To prevent that, if a hid_bpf_hw_request() call is emitted, we prevent
any new call of this kfunc by storing the information in the context.
This way we can always trace/monitor/filter the incoming bpf requests,
while preventing those loops to happen.
I don't think exposing "from_bpf" is very interesting because while
writing such a bpf program, you need to match at least the report number
and/or the source of the call. So a blind "if there is a
hid_hw_raw_request() call, I'm emitting another one" makes no real
sense.
Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-5-cfd60fb6c79f@kernel.org
Acked-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Diffstat (limited to 'drivers/clk/analogbits')
0 files changed, 0 insertions, 0 deletions