HID: bpf: constify hid_ops

The hid_ops struct is never modified. Mark it as const.

Signed-off-by: Thomas Weißschuh <[email protected]>
Link: https://patch.msgid.link/20241127-hid-bpf-ops-v1-1-f9

HID: bpf: constify hid_ops

The hid_ops struct is never modified. Mark it as const.

Signed-off-by: Thomas Weißschuh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: move HID-BPF report descriptor fixup earlier

Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the dr

HID: bpf: move HID-BPF report descriptor fixup earlier

Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.

To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.

However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.

In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */

/* XXX 4 bytes hole, try to pack */

__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */

/* XXX 4 bytes hole, try to pack */

struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */

/* XXX 4 bytes hole, try to pack */

struct hid_report_enum report_enum[3]; /* 80 6216 */

Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.

In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.

Link: https://patch.msgid.link/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: constify parameter rdesc of call_hid_bpf_rdesc_fixup()

The parameter is never modified, so mark it as const.
Also inline the return statement to avoid a type mismatch error.

This is a pre

HID: bpf: constify parameter rdesc of call_hid_bpf_rdesc_fixup()

The parameter is never modified, so mark it as const.
Also inline the return statement to avoid a type mismatch error.

This is a prerequisite for constification changes in the HID core.

Signed-off-by: Thomas Weißschuh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

mm: add comments for allocation helpers explaining why they are macros

A number of allocation helper functions were converted into macros to
account them at the call sites. Add a comment for each c

mm: add comments for allocation helpers explaining why they are macros

A number of allocation helper functions were converted into macros to
account them at the call sites. Add a comment for each converted
allocation helper explaining why it has to be a macro and why we typecast
the return value wherever required. The patch also moves
acpi_os_acquire_object() closer to other allocation helpers to group them
together under the same comment. The patch has no functional changes.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 2c321f3f70bc ("mm: change inlined allocation helpers to account at the call site")
Signed-off-by: Suren Baghdasaryan <[email protected]>
Suggested-by: Andrew Morton <[email protected]>
Cc: Christian König <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Jan Kara <[email protected]>
Cc: Kent Overstreet <[email protected]>
Cc: Thorsten Blum <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

HID: bpf: doc fixes for hid_hw_request() hooks

We had the following errors while doing make htmldocs:

Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:167:
ERROR: Unexpected indentation.

Al

HID: bpf: doc fixes for hid_hw_request() hooks

We had the following errors while doing make htmldocs:

Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:167:
ERROR: Unexpected indentation.

Also ensure consistency with the rest of the __u64 vs u64.

Reported-by: Stephen Rothwell <[email protected]>
Fixes: 9286675a2aed ("HID: bpf: add HID-BPF hooks for hid_hw_output_report")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: doc fixes for hid_hw_request() hooks

We had the following errors while doing make htmldocs:
Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:144:
ERROR: Unexpected indentation.
Docu

HID: bpf: doc fixes for hid_hw_request() hooks

We had the following errors while doing make htmldocs:
Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:144:
ERROR: Unexpected indentation.
Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:145:
WARNING: Block quote ends without a blank line;
unexpected unindent.
Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:147:
ERROR: Unexpected indentation.

Reported-by: Stephen Rothwell <[email protected]>
Fixes: 8bd0488b5ea5 ("HID: bpf: add HID-BPF hooks for hid_hw_raw_requests")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: fix gcc warning and unify __u64 into u64

I've got multiple reports of:
error: cast from pointer to integer of different size
[-Werror=pointer-to-int-cast].

Let's use the same trick than k

HID: bpf: fix gcc warning and unify __u64 into u64

I've got multiple reports of:
error: cast from pointer to integer of different size
[-Werror=pointer-to-int-cast].

Let's use the same trick than kernel/bpf/helpers.c to shut up that warning.

Even if we were on an architecture with addresses on more than 64 bits,
this isn't much of an issue as the address is not used as a pointer,
but as an hash and the caller is not supposed to go back to the kernel
address ever.

And while we change those, make sure we use u64 instead of __u64 for
consistency

Reported-by: Stephen Rothwell <[email protected]>
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Reported-by: Mirsad Todorovac <[email protected]>
Fixes: 67eccf151d76 ("HID: add source argument to HID low level functions")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: allow hid_device_event hooks to inject input reports on self

This is the same logic than hid_hw_raw_request or hid_hw_output_report:
we can allow hid_bpf_try_input_report to be called from

HID: bpf: allow hid_device_event hooks to inject input reports on self

This is the same logic than hid_hw_raw_request or hid_hw_output_report:
we can allow hid_bpf_try_input_report to be called from a hook on
hid_input_report if we ensure that the call can not be made twice in a
row.

There is one extra subtlety in which there is a lock in hid_input_report.
But given that we can detect if we are already in the hook, we can notify
hid_input_report to not take the lock. This is done by checking if
ctx_kern data is valid or null, and if it is equal to the dedicated
incoming data buffer.

In order to have more control on whether the lock needs to be taken or not
we introduce a new kfunc for it: hid_bpf_try_input_report()

Link: https://patch.msgid.link/[email protected]
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: make hid_bpf_input_report() sleep until the device is ready

hid_bpf_input_report() is already marked to be used in sleepable context
only. So instead of hammering with timers the device to

HID: bpf: make hid_bpf_input_report() sleep until the device is ready

hid_bpf_input_report() is already marked to be used in sleepable context
only. So instead of hammering with timers the device to hopefully get
an available slot where the device is not sending events, we can make
that kfunc wait for the current event to be terminated before it goes in.

This allows to work with the following pseudo code:

in struct_ops/hid_device_event:
- schedule a bpf_wq, which calls hid_bpf_input_report()
- once this struct_ops function terminates, hid_bpf_input_report()
immediately starts before the next event

Link: https://patch.msgid.link/[email protected]
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: add HID-BPF hooks for hid_hw_output_report

Same story than hid_hw_raw_requests:

This allows to intercept and prevent or change the behavior of
hid_hw_output_report() from a bpf program.

HID: bpf: add HID-BPF hooks for hid_hw_output_report

Same story than hid_hw_raw_requests:

This allows to intercept and prevent or change the behavior of
hid_hw_output_report() from a bpf program.

The intent is to solve a couple of use case:
- firewalling a HID device: a firewall can monitor who opens the hidraw
nodes and then prevent or allow access to write operations on that
hidraw node.
- change the behavior of a device and emulate a new HID feature request

The hook is allowed to be run as sleepable so it can itself call
hid_hw_output_report(), which allows to "convert" one feature request into
another or even call the feature request on a different HID device on the
same physical device.

Link: https://patch.msgid.link/[email protected]
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

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

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/[email protected]
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: add HID-BPF hooks for hid_hw_raw_requests

This allows to intercept and prevent or change the behavior of
hid_hw_raw_request() from a bpf program.

The intent is to solve a couple of use ca

HID: bpf: add HID-BPF hooks for hid_hw_raw_requests

This allows to intercept and prevent or change the behavior of
hid_hw_raw_request() from a bpf program.

The intent is to solve a couple of use case:
- firewalling a HID device: a firewall can monitor who opens the hidraw
nodes and then prevent or allow access to write operations on that
hidraw node.
- change the behavior of a device and emulate a new HID feature request

The hook is allowed to be run as sleepable so it can itself call
hid_bpf_hw_request(), which allows to "convert" one feature request into
another or even call the feature request on a different HID device on the
same physical device.

Link: https://patch.msgid.link/[email protected]
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: protect HID-BPF prog_list access by a SRCU

We want to add sleepable callbacks for hid_hw_raw_request() and
hid_hw_output_report(), but we can not use a plain RCU for those.

Prepare for a

HID: bpf: protect HID-BPF prog_list access by a SRCU

We want to add sleepable callbacks for hid_hw_raw_request() and
hid_hw_output_report(), but we can not use a plain RCU for those.

Prepare for a SRCU so we can extend HID-BPF.

This changes a little bit how hid_bpf_device_init() behaves, as it may
now fail, so there is a tiny hid-core.c change to accommodate for this.

Link: https://patch.msgid.link/[email protected]
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: add source argument to HID low level functions

This allows to know who actually sent what when we process the request
to the device.
This will be useful for a BPF firewall program to allow or n

HID: add source argument to HID low level functions

This allows to know who actually sent what when we process the request
to the device.
This will be useful for a BPF firewall program to allow or not requests
coming from a dedicated hidraw node client.

Link: https://patch.msgid.link/[email protected]
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: make part of struct hid_device writable

It is useful to change the name, the phys and/or the uniq of a
struct hid_device during .rdesc_fixup().

For example, hid-uclogic.ko changes the uni

HID: bpf: make part of struct hid_device writable

It is useful to change the name, the phys and/or the uniq of a
struct hid_device during .rdesc_fixup().

For example, hid-uclogic.ko changes the uniq to store the firmware version
to differentiate between 2 devices sharing the same PID. In the same
way, changing the device name is useful when the device export 3 nodes,
all with the same name.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

Documentation: HID: amend HID-BPF for struct_ops

Now that we are using struct_ops, the docs need to be changed.

Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-10-6ac6ade58329@kernel

Documentation: HID: amend HID-BPF for struct_ops

Now that we are using struct_ops, the docs need to be changed.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: remove tracing HID-BPF capability

We can now rely on struct_ops as we cleared the users in-tree.

Link: https://lore.kernel.org/r/[email protected]
S

HID: bpf: remove tracing HID-BPF capability

We can now rely on struct_ops as we cleared the users in-tree.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: implement HID-BPF through bpf_struct_ops

We do this implementation in several steps to not have the CI failing:
- first (this patch), we add struct_ops while keeping the existing infra
a

HID: bpf: implement HID-BPF through bpf_struct_ops

We do this implementation in several steps to not have the CI failing:
- first (this patch), we add struct_ops while keeping the existing infra
available
- then we change the selftests, the examples and the existing in-tree
HID-BPF programs
- then we remove the existing trace points making old HID-BPF obsolete

There are a few advantages of struct_ops over tracing:
- compatibility with sleepable programs (for hid_hw_raw_request() in
a later patch)
- a lot simpler in the kernel: it's a simple rcu protected list
- we can add more parameters to the function called without much trouble
- the "attach" is now generic through BPF-core: the caller just needs to
set hid_id and flags before calling __load().
- all the BPF tough part is not handled in BPF-core through generic
processing
- hid_bpf_ctx is now only writable where it needs be

Acked-by: Alexei Starovoitov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: rename struct hid_bpf_ops into hid_ops

Those operations are the ones from HID, not HID-BPF, and I'd like to
reuse hid_bpf_ops as the user facing struct_ops API.

Link: https://lore.kernel.org/r

HID: rename struct hid_bpf_ops into hid_ops

Those operations are the ones from HID, not HID-BPF, and I'd like to
reuse hid_bpf_ops as the user facing struct_ops API.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

mm: change inlined allocation helpers to account at the call site

Main goal of memory allocation profiling patchset is to provide accounting
that is cheap enough to run in production. To achieve th

mm: change inlined allocation helpers to account at the call site

Main goal of memory allocation profiling patchset is to provide accounting
that is cheap enough to run in production. To achieve that we inject
counters using codetags at the allocation call sites to account every time
allocation is made. This injection allows us to perform accounting
efficiently because injected counters are immediately available as opposed
to the alternative methods, such as using _RET_IP_, which would require
counter lookup and appropriate locking that makes accounting much more
expensive. This method requires all allocation functions to inject
separate counters at their call sites so that their callers can be
individually accounted. Counter injection is implemented by allocation
hooks which should wrap all allocation functions.

Inlined functions which perform allocations but do not use allocation
hooks are directly charged for the allocations they perform. In most
cases these functions are just specialized allocation wrappers used from
multiple places to allocate objects of a specific type. It would be more
useful to do the accounting at their call sites instead. Instrument these
helpers to do accounting at the call site. Simple inlined allocation
wrappers are converted directly into macros. More complex allocators or
allocators with documentation are converted into _noprof versions and
allocation hooks are added. This allows memory allocation profiling
mechanism to charge allocations to the callers of these functions.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Suren Baghdasaryan <[email protected]>
Acked-by: Jan Kara <[email protected]> [jbd2]
Cc: Anna Schumaker <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Benjamin Tissoires <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Dennis Zhou <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Jakub Kicinski <[email protected]>
Cc: Jakub Sitnicki <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Cc: Kent Overstreet <[email protected]>
Cc: Matthew Wilcox (Oracle) <[email protected]>
Cc: Paolo Abeni <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: Theodore Ts'o <[email protected]>
Cc: Trond Myklebust <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

HID: bpf: allow to inject HID event from BPF

It can be interesting to inject events from BPF as if the event were
to come from the device.
For example, some multitouch devices do not all the time se

HID: bpf: allow to inject HID event from BPF

It can be interesting to inject events from BPF as if the event were
to come from the device.
For example, some multitouch devices do not all the time send a proximity
out event, and we might want to send it for the physical device.

Compared to uhid, we can now inject events on any physical device, not
just uhid virtual ones.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: export hid_hw_output_report as a BPF kfunc

We currently only export hid_hw_raw_request() as a BPF kfunc.
However, some devices require an explicit write on the Output Report
instead of the

HID: bpf: export hid_hw_output_report as a BPF kfunc

We currently only export hid_hw_raw_request() as a BPF kfunc.
However, some devices require an explicit write on the Output Report
instead of the use of the control channel.

So also export hid_hw_output_report to BPF

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: use __bpf_kfunc instead of noinline

Follow the docs at Documentation/bpf/kfuncs.rst:
- declare the function with `__bpf_kfunc`
- disables missing prototype warnings, which allows to remove

HID: bpf: use __bpf_kfunc instead of noinline

Follow the docs at Documentation/bpf/kfuncs.rst:
- declare the function with `__bpf_kfunc`
- disables missing prototype warnings, which allows to remove them from
include/linux/hid-bpf.h

Removing the prototypes is not an issue because we currently have to
redeclare them when writing the BPF program. They will eventually be
generated by bpftool directly AFAIU.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

HID: bpf: make bus_type const in struct hid_bpf_ops

The struct bus_type pointer in hid_bpf_ops just passes the pointer to
the driver core, and the driver core can handle, and expects, a constant
poi

HID: bpf: make bus_type const in struct hid_bpf_ops

The struct bus_type pointer in hid_bpf_ops just passes the pointer to
the driver core, and the driver core can handle, and expects, a constant
pointer, so also make the pointer constant in hid_bpf_ops.

Part of the process of moving all usages of struct bus_type to be
constant to move them all to read-only memory.

Cc: Jiri Kosina <[email protected]>
Cc: Benjamin Tissoires <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...

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 <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...