Merge tag 'v6.6.18' into dev-6.6

This is the 6.6.18 stable release

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 ...

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 ...

Merge branch 'next' into for-linus

Prepare input updates for 6.4 merge window.

Merge drm/drm-next into drm-intel-gt-next

Need to pull in commit from drm-next (earlier in drm-intel-next):

1eca0778f4b3 ("drm/i915: add struct i915_dsm to wrap dsm members together")

In order to

Merge drm/drm-next into drm-intel-gt-next

Need to pull in commit from drm-next (earlier in drm-intel-next):

1eca0778f4b3 ("drm/i915: add struct i915_dsm to wrap dsm members together")

In order to merge following patch to drm-intel-gt-next:

https://patchwork.freedesktop.org/patch/530942/?series=114925&rev=6

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

show more ...

Merge drm/drm-next into drm-intel-next

Catch up with 6.3-rc cycle...

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Merge remote-tracking branch 'drm/drm-next' into msm-next

Merge drm-next into msm-next to pick up external clk and PM dependencies
for improved a6xx GPU reset sequence.

Signed-off-by: Rob Clark <ro

Merge remote-tracking branch 'drm/drm-next' into msm-next

Merge drm-next into msm-next to pick up external clk and PM dependencies
for improved a6xx GPU reset sequence.

Signed-off-by: Rob Clark <robdclark@chromium.org>

show more ...

Merge tag 'v6.3-rc2' into next

Merge with mainline to get of_property_present() and other newer APIs.

Merge drm/drm-fixes into drm-misc-fixes

Backmerging to get latest upstream.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Merge drm/drm-next into drm-misc-next

Backmerging to get v6.3-rc1 and sync with the other DRM trees.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Merge remote-tracking branch 'acme/perf-tools' into perf-tools-next

To pick up perf-tools fixes just merged upstream.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Merge tag 'for-linus-2023022201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid

Pull HID updates from Benjamin Tissoires:

- HID-BPF infrastructure: this allows to start using HID-BPF. No

Merge tag 'for-linus-2023022201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid

Pull HID updates from Benjamin Tissoires:

- HID-BPF infrastructure: this allows to start using HID-BPF. Note that
the mechanism to ship HID-BPF program through the kernel tree is
still not implemented yet (but is planned).

This should be a no-op for 99% of users. Also we are gaining
kselftests for the HID tree (Benjamin Tissoires)

- Some UAF fixes in workers when using uhid (Pietro Borrello & Benjamin
Tissoires)

- Constify hid_ll_driver (Thomas Weißschuh)

- Allow more custom IIO sensors through HID (Philipp Jungkamp)

- Logitech HID++ fixes for scroll wheel, protocol and debug (Bastien
Nocera)

- Some new device support: Steam Deck (Vicki Pfau), UClogic (José
Expósito), Logitech G923 Xbox Edition steering wheel (Walt Holman),
EVision keyboards (Philippe Valembois)

- other assorted code cleanups and fixes

* tag 'for-linus-2023022201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: (99 commits)
HID: mcp-2221: prevent UAF in delayed work
hid: bigben_probe(): validate report count
HID: asus: use spinlock to safely schedule workers
HID: asus: use spinlock to protect concurrent accesses
HID: bigben: use spinlock to safely schedule workers
HID: bigben_worker() remove unneeded check on report_field
HID: bigben: use spinlock to protect concurrent accesses
HID: logitech-hidpp: Add myself to authors
HID: logitech-hidpp: Retry commands when device is busy
HID: logitech-hidpp: Add more debug statements
HID: Add support for Logitech G923 Xbox Edition steering wheel
HID: logitech-hidpp: Add Signature M650
HID: logitech-hidpp: Remove HIDPP_QUIRK_NO_HIDINPUT quirk
HID: logitech-hidpp: Don't restart communication if not necessary
HID: logitech-hidpp: Add constants for HID++ 2.0 error codes
Revert "HID: logitech-hidpp: add a module parameter to keep firmware gestures"
HID: logitech-hidpp: Hard-code HID++ 1.0 fast scroll support
HID: i2c-hid: goodix: Add mainboard-vddio-supply
dt-bindings: HID: i2c-hid: goodix: Add mainboard-vddio-supply
HID: i2c-hid: goodix: Stop tying the reset line to the regulator
...

show more ...

Merge branch 'for-6.3/hid-bpf' into for-linus

Initial support of HID-BPF (Benjamin Tissoires)

The history is a little long for this series, as it was intended to be
sent for v6.2. However some last

Merge branch 'for-6.3/hid-bpf' into for-linus

Initial support of HID-BPF (Benjamin Tissoires)

The history is a little long for this series, as it was intended to be
sent for v6.2. However some last minute issues forced us to postpone it
to v6.3.

Conflicts:
* drivers/hid/i2c-hid/Kconfig:
commit bf7660dab30d ("HID: stop drivers from selecting CONFIG_HID")
conflicts with commit 2afac81dd165 ("HID: fix I2C_HID not selected
when I2C_HID_OF_ELAN is")
the resolution is simple enough: just drop the "default" and "select"
lines as the new commit from Arnd is doing

show more ...

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 ...

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 ...

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 ...

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 ...

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 ...

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 ...

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 ...