summaryrefslogtreecommitdiff
path: root/drivers/clk/analogbits
diff options
context:
space:
mode:
authorBenjamin Tissoires <bentiss@kernel.org>2024-06-26 16:46:26 +0300
committerBenjamin Tissoires <bentiss@kernel.org>2024-06-27 12:00:12 +0300
commit75839101ce52e319cb2154a027d14f1f0aa3be09 (patch)
tree37b05cb095474429cd80940e2c7b2e6d6d3a92a7 /drivers/clk/analogbits
parent8bd0488b5ea58655ad6fdcbe0408ef49b16882b1 (diff)
downloadlinux-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