On Fri, Mar 25, 2022 at 6:00 PM Andrii Nakryiko andrii.nakryiko@gmail.com wrote:
On Wed, Mar 23, 2022 at 9:08 AM Benjamin Tissoires benjamin.tissoires@redhat.com wrote:
Hi Alexei,
On Tue, Mar 22, 2022 at 11:51 PM Alexei Starovoitov alexei.starovoitov@gmail.com wrote:
On Fri, Mar 18, 2022 at 9:16 AM Benjamin Tissoires benjamin.tissoires@redhat.com wrote:
+u8 *hid_bpf_report_fixup(struct hid_device *hdev, u8 *rdesc, unsigned int *size) +{
int ret;struct hid_bpf_ctx_kern ctx = {.type = HID_BPF_RDESC_FIXUP,.hdev = hdev,.size = *size,};if (bpf_hid_link_empty(&hdev->bpf, BPF_HID_ATTACH_RDESC_FIXUP))goto ignore_bpf;ctx.data = kmemdup(rdesc, HID_MAX_DESCRIPTOR_SIZE, GFP_KERNEL);if (!ctx.data)goto ignore_bpf;ctx.allocated_size = HID_MAX_DESCRIPTOR_SIZE;ret = hid_bpf_run_progs(hdev, &ctx);if (ret)goto ignore_bpf;if (ctx.size > ctx.allocated_size)goto ignore_bpf;*size = ctx.size;if (*size) {rdesc = krealloc(ctx.data, *size, GFP_KERNEL);} else {rdesc = NULL;kfree(ctx.data);}return rdesc;- ignore_bpf:
kfree(ctx.data);return kmemdup(rdesc, *size, GFP_KERNEL);+}
int __init hid_bpf_module_init(void) { struct bpf_hid_hooks hooks = { .hdev_from_fd = hid_bpf_fd_to_hdev, .pre_link_attach = hid_bpf_pre_link_attach,
.post_link_attach = hid_bpf_post_link_attach, .array_detach = hid_bpf_array_detach, };diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 937fab7eb9c6..3182c39db006 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1213,7 +1213,8 @@ int hid_open_report(struct hid_device *device) return -ENODEV; size = device->dev_rsize;
buf = kmemdup(start, size, GFP_KERNEL);
/* hid_bpf_report_fixup() ensures we work on a copy of rdesc */buf = hid_bpf_report_fixup(device, start, &size);Looking at this patch and the majority of other patches... the code is doing a lot of work to connect HID side with bpf. At the same time the evolution of the patch series suggests that these hook points are not quite stable. More hooks and helpers are being added. It tells us that it's way too early to introduce a stable interface between HID and bpf.
I understand that you might be under the impression that the interface is changing a lot, but this is mostly due to my poor knowledge of all the arcanes of eBPF. The overall way HID-BPF works is to work on a single array, and we should pretty much be sorted out. There are a couple of helpers to be able to communicate with the device, but the API has been stable in the kernel for those for quite some time now.
The variations in the hooks is mostly because I don't know what is the best representation we can use in eBPF for those, and the review process is changing that.
I think such a big feature as this one, especially that most BPF folks are (probably) not familiar with the HID subsystem in the kernel, would benefit from a bit of live discussion during BPF office hours. Do you think you can give a short overview of what you are trying to achieve with some background context on HID specifics at one of the next BPF office hours? We have a meeting scheduled every week on Thursday, 9am Pacific time. But people need to put their topic onto the agenda, otherwise the meeting is cancelled. See [0] for spreadsheet and links to Zoom meeting, agenda, etc.
This sounds like a good idea. I just added my topic on the agenda and will prepare some slides.
Cheers, Benjamin
[0] https://docs.google.com/spreadsheets/d/1LfrDXZ9-fdhvPEp_LHkxAMYyxxpwBXjywWa0...
[...]