Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14 |
|
#
467fce63 |
| 24-Jan-2024 |
Benjamin Tissoires <bentiss@kernel.org> |
HID: bpf: actually free hdev memory after attaching a HID-BPF program
commit 89be8aa5b0ecb3b729c7bcff64bb2af7921fec63 upstream.
Turns out that I got my reference counts wrong and each successful bu
HID: bpf: actually free hdev memory after attaching a HID-BPF program
commit 89be8aa5b0ecb3b729c7bcff64bb2af7921fec63 upstream.
Turns out that I got my reference counts wrong and each successful bus_find_device() actually calls get_device(), and we need to manually call put_device().
Ensure each bus_find_device() gets a matching put_device() when releasing the bpf programs and fix all the error paths.
Cc: <stable@vger.kernel.org> Fixes: f5c27da4e3c8 ("HID: initial BPF implementation") Link: https://lore.kernel.org/r/20240124-b4-hid-bpf-fixes-v2-2-052520b1e5e6@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d83a7e59 |
| 24-Jan-2024 |
Benjamin Tissoires <bentiss@kernel.org> |
HID: bpf: remove double fdget()
commit 7cdd2108903a4e369eb37579830afc12a6877ec2 upstream.
When the kfunc hid_bpf_attach_prog() is called, we called twice fdget(): one for fetching the type of the b
HID: bpf: remove double fdget()
commit 7cdd2108903a4e369eb37579830afc12a6877ec2 upstream.
When the kfunc hid_bpf_attach_prog() is called, we called twice fdget(): one for fetching the type of the bpf program, and one for actually attaching the program to the device.
The problem is that between those two calls, we have no guarantees that the prog_fd is still the same file descriptor for the given program.
Solve this by calling bpf_prog_get() earlier, and use this to fetch the program type.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/bpf/CAO-hwJJ8vh8JD3-P43L-_CLNmPx0hWj44aom0O838vfP4=_1CA@mail.gmail.com/T/#t Cc: <stable@vger.kernel.org> Fixes: f5c27da4e3c8 ("HID: initial BPF implementation") Link: https://lore.kernel.org/r/20240124-b4-hid-bpf-fixes-v2-1-052520b1e5e6@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22 |
|
#
fb2211a5 |
| 25-Mar-2023 |
David Vernet <void@manifault.com> |
bpf: Remove now-unnecessary NULL checks for KF_RELEASE kfuncs
Now that we're not invoking kfunc destructors when the kptr in a map was NULL, we no longer require NULL checks in many of our KF_RELEAS
bpf: Remove now-unnecessary NULL checks for KF_RELEASE kfuncs
Now that we're not invoking kfunc destructors when the kptr in a map was NULL, we no longer require NULL checks in many of our KF_RELEASE kfuncs. This patch removes those NULL checks.
Signed-off-by: David Vernet <void@manifault.com> Link: https://lore.kernel.org/r/20230325213144.486885-3-void@manifault.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
show more ...
|
Revision tags: v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6 |
|
#
0c2d5728 |
| 13-Jan-2023 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: bpf: reorder BPF registration
Given that our initial BPF program is not using any kfuncs anymore, we can reorder the initialization to first try to load it and then register the kfuncs. This ha
HID: bpf: reorder BPF registration
Given that our initial BPF program is not using any kfuncs anymore, we can reorder the initialization to first try to load it and then register the kfuncs. This has the advantage of not exporting kfuncs when HID-BPF is not working.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|
#
bb2c0aea |
| 13-Jan-2023 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: bpf: clean up entrypoint
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@redh
HID: bpf: clean up entrypoint
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> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|
#
4b9a3f49 |
| 13-Jan-2023 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: bpf: rework how programs are attached and stored in the kernel
Previously, HID-BPF was relying on a bpf tracing program to be notified when a program was released from userspace. This is error
HID: bpf: rework how programs are attached and stored in the kernel
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> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|
Revision tags: v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12 |
|
#
86020156 |
| 06-Dec-2022 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: bpf: do not rely on ALLOW_ERROR_INJECTION
Now that we have aproper non debug API to declare which function is fmodret, we can rely on it.
Link: https://lore.kernel.org/all/20221121104403.1545
HID: bpf: do not rely on ALLOW_ERROR_INJECTION
Now that we have aproper non debug API to declare which function is fmodret, we can rely on it.
Link: https://lore.kernel.org/all/20221121104403.1545f9b5@gandalf.local.home/ Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221206145936.922196-3-benjamin.tissoires@redhat.com
show more ...
|
Revision tags: v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78 |
|
#
ad190df1 |
| 03-Nov-2022 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: bpf: allow to change the report descriptor
Add a new tracepoint hid_bpf_rdesc_fixup() so we can trigger a report descriptor fixup in the bpf world.
Whenever the program gets attached/detached,
HID: bpf: allow to change the report descriptor
Add a new tracepoint hid_bpf_rdesc_fixup() so we can trigger a report descriptor fixup in the bpf world.
Whenever the program gets attached/detached, the device is reconnected meaning that userspace will see it disappearing and reappearing with the new report descriptor.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|
#
91a7f802 |
| 03-Nov-2022 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: bpf: introduce hid_hw_request()
This function can not be called under IRQ, thus it is only available while in SEC("syscall"). For consistency, this function requires a HID-BPF context to work w
HID: bpf: introduce hid_hw_request()
This function can not be called under IRQ, thus it is only available while in SEC("syscall"). For consistency, this function requires a HID-BPF context to work with, and so we also provide a helper to create one based on the HID unique ID.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
--
changes in v12: - variable dereferenced before check 'ctx' |Reported-by: kernel test robot <lkp@intel.com> |Reported-by: Dan Carpenter <error27@gmail.com>
no changes in v11
no changes in v10
changes in v9: - fixed kfunc declaration aaccording to latest upstream changes
no changes in v8
changes in v7: - hid_bpf_allocate_context: remove unused variable - ensures buf is not NULL
changes in v6: - rename parameter size into buf__sz to teach the verifier about the actual buffer size used by the call - remove the allocated data in the user created context, it's not used
new-ish in v5 Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|
#
658ee5a6 |
| 03-Nov-2022 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: bpf: allocate data memory for device_event BPF programs
We need to also be able to change the size of the report. Reducing it is easy, because we already have the incoming buffer that is big en
HID: bpf: allocate data memory for device_event BPF programs
We need to also be able to change the size of the report. Reducing it is easy, because we already have the incoming buffer that is big enough, but extending it is harder.
Pre-allocate a buffer that is big enough to handle all reports of the device, and use that as the primary buffer for BPF programs. To be able to change the size of the buffer, we change the device_event API and request it to return the size of the buffer.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|
#
0baef373 |
| 03-Nov-2022 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: bpf jmp table: simplify the logic of cleaning up programs
Kind of a hack, but works for now:
Instead of listening for any close of eBPF program, we now decrement the refcount when we insert it
HID: bpf jmp table: simplify the logic of cleaning up programs
Kind of a hack, but works for now:
Instead of listening for any close of eBPF program, we now decrement the refcount when we insert it in our internal map of fd progs.
This is safe to do because: - we listen to any call of destructor of programs - when a program is being destroyed, we disable it by removing it from any RCU list used by any HID device (so it will never be called) - we then trigger a job to cleanup the prog fd map, but we overwrite the removal of the elements to not do anything on the programs, just remove the allocated space
This is better than previously because we can remove the map of known programs and their usage count. We now rely on the refcount of bpf, which has greater chances of being accurate.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|
#
f5c27da4 |
| 03-Nov-2022 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: initial BPF implementation
Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data.
A simpler implementation would consist in just cal
HID: initial BPF implementation
Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data.
A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device.
The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes.
For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf.
Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users.
HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call().
To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned).
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|