This series is a followup of the struct_ops conversion.
Therefore, it is based on top of the for-6.11/bpf branch of the hid.git
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-6.11…
The first patch should go in ASAP, it's a fix that was detected by Dan
and which is actually breaking some use cases.
The rest is adding new capabilities to HID-BPF: being able to intercept
hid_hw_raw_request() and hid_hw_ouptut_report(). Both operations are
write operations to the device.
Having those new hooks allows to implement the "firewall" of HID
devices: this way a bpf program can selectively authorize an hidraw
client to write or not to the device depending on what is requested.
This also allows to completely emulate new behavior: we can now create a
"fake" feature on a HID device, and when we receive a request on this
feature, we can emulate the answer by either statically answering or
even by communicating with the device from bpf, as those new hooks are
sleepable.
Last, there is one change in the kfunc hid_bpf_input_report, in which it
actually waits for the device to be ready. This will not break any
potential users as the function was already declared as sleepable.
Cheers,
Benjamin
Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org>
---
Changes in v2:
- made use of srcu, for sleepable users
- Link to v1: https://lore.kernel.org/r/20240621-hid_hw_req_bpf-v1-0-d7ab8b885a0b@kernel.…
---
Benjamin Tissoires (13):
HID: bpf: fix dispatch_hid_bpf_device_event uninitialized ret value
HID: add source argument to HID low level functions
HID: bpf: protect HID-BPF prog_list access by a SRCU
HID: bpf: add HID-BPF hooks for hid_hw_raw_requests
HID: bpf: prevent infinite recursions with hid_hw_raw_requests hooks
selftests/hid: add tests for hid_hw_raw_request HID-BPF hooks
HID: bpf: add HID-BPF hooks for hid_hw_output_report
selftests/hid: add tests for hid_hw_output_report HID-BPF hooks
HID: bpf: make hid_bpf_input_report() sleep until the device is ready
selftests/hid: add wq test for hid_bpf_input_report()
HID: bpf: allow hid_device_event hooks to inject input reports on self
selftests/hid: add another test for injecting an event from an event hook
selftests/hid: add an infinite loop test for hid_bpf_try_input_report
Documentation/hid/hid-bpf.rst | 2 +-
drivers/hid/bpf/hid_bpf_dispatch.c | 165 ++++++++++-
drivers/hid/bpf/hid_bpf_dispatch.h | 1 +
drivers/hid/bpf/hid_bpf_struct_ops.c | 6 +-
drivers/hid/hid-core.c | 118 +++++---
drivers/hid/hidraw.c | 10 +-
include/linux/hid.h | 7 +
include/linux/hid_bpf.h | 80 ++++-
tools/testing/selftests/hid/hid_bpf.c | 326 +++++++++++++++++++++
tools/testing/selftests/hid/progs/hid.c | 292 ++++++++++++++++++
.../testing/selftests/hid/progs/hid_bpf_helpers.h | 13 +
11 files changed, 955 insertions(+), 65 deletions(-)
---
base-commit: 33c0fb85b571b0f1bbdbf466e770eebeb29e6f41
change-id: 20240614-hid_hw_req_bpf-df0b95aeb425
Best regards,
--
Benjamin Tissoires <bentiss(a)kernel.org>
** Background **
Currently, OVS supports several packet sampling mechanisms (sFlow,
per-bridge IPFIX, per-flow IPFIX). These end up being translated into a
userspace action that needs to be handled by ovs-vswitchd's handler
threads only to be forwarded to some third party application that
will somehow process the sample and provide observability on the
datapath.
A particularly interesting use-case is controller-driven
per-flow IPFIX sampling where the OpenFlow controller can add metadata
to samples (via two 32bit integers) and this metadata is then available
to the sample-collecting system for correlation.
** Problem **
The fact that sampled traffic share netlink sockets and handler thread
time with upcalls, apart from being a performance bottleneck in the
sample extraction itself, can severely compromise the datapath,
yielding this solution unfit for highly loaded production systems.
Users are left with little options other than guessing what sampling
rate will be OK for their traffic pattern and system load and dealing
with the lost accuracy.
Looking at available infrastructure, an obvious candidated would be
to use psample. However, it's current state does not help with the
use-case at stake because sampled packets do not contain user-defined
metadata.
** Proposal **
This series is an attempt to fix this situation by extending the
existing psample infrastructure to carry a variable length
user-defined cookie.
The main existing user of psample is tc's act_sample. It is also
extended to forward the action's cookie to psample.
Finally, a new OVS action (OVS_SAMPLE_ATTR_EMIT_SAMPLE) is created.
It accepts a group and an optional cookie and uses psample to
multicast the packet and the metadata.
--
v4 -> v5:
- Rebased.
- Removed lefover enum value and wrapped some long lines in selftests.
v3 -> v4:
- Rebased.
- Addressed Jakub's comment on private and unused nla attributes.
v2 -> v3:
- Addressed comments from Simon, Aaron and Ilya.
- Dropped probability propagation in nested sample actions.
- Dropped patch v2's 7/9 in favor of a userspace implementation and
consume skb if emit_sample is the last action, same as we do with
userspace.
- Split ovs-dpctl.py features in independent patches.
v1 -> v2:
- Create a new action ("emit_sample") rather than reuse existing
"sample" one.
- Add probability semantics to psample's sampling rate.
- Store sampling probability in skb's cb area and use it in emit_sample.
- Test combining "emit_sample" with "trunc"
- Drop group_id filtering and tracepoint in psample.
rfc_v2 -> v1:
- Accommodate Ilya's comments.
- Split OVS's attribute in two attributes and simplify internal
handling of psample arguments.
- Extend psample and tc with a user-defined cookie.
- Add a tracepoint to psample to facilitate troubleshooting.
rfc_v1 -> rfc_v2:
- Use psample instead of a new OVS-only multicast group.
- Extend psample and tc with a user-defined cookie.
Adrian Moreno (10):
net: psample: add user cookie
net: sched: act_sample: add action cookie to sample
net: psample: skip packet copy if no listeners
net: psample: allow using rate as probability
net: openvswitch: add emit_sample action
net: openvswitch: store sampling probability in cb.
selftests: openvswitch: add emit_sample action
selftests: openvswitch: add userspace parsing
selftests: openvswitch: parse trunc action
selftests: openvswitch: add emit_sample test
Documentation/netlink/specs/ovs_flow.yaml | 17 ++
include/net/psample.h | 5 +-
include/uapi/linux/openvswitch.h | 31 +-
include/uapi/linux/psample.h | 11 +-
net/openvswitch/Kconfig | 1 +
net/openvswitch/actions.c | 63 +++-
net/openvswitch/datapath.h | 3 +
net/openvswitch/flow_netlink.c | 33 ++-
net/openvswitch/vport.c | 1 +
net/psample/psample.c | 16 +-
net/sched/act_sample.c | 12 +
.../selftests/net/openvswitch/openvswitch.sh | 114 +++++++-
.../selftests/net/openvswitch/ovs-dpctl.py | 272 +++++++++++++++++-
13 files changed, 563 insertions(+), 16 deletions(-)
--
2.45.1
From: Geliang Tang <tanggeliang(a)kylinos.cn>
v2:
- add patch 2, a new fix for sk_msg_memcopy_from_iter.
- update patch 3, only test "sk->sk_prot->close" as Eric suggested.
- update patch 4, use "goto err" instead of "return" as Eduard
suggested.
- add "fixes" tag for patch 1-3.
- change subject prefixes as "bpf-next" to trigger BPF CI.
- cc Loongarch maintainers too.
BPF selftests seem to have not been fully tested on Loongarch. When I
ran these tests on Loongarch recently, some errors occur. This patch set
contains some null-check related fixes for these errors.
Geliang Tang (4):
skmsg: null check for sg_page in sk_msg_recvmsg
skmsg: null check for sg_page in sk_msg_memcopy_from_iter
inet: null check for close in inet_release
selftests/bpf: Null checks for link in bpf_tcp_ca
net/core/skmsg.c | 4 ++++
net/ipv4/af_inet.c | 3 ++-
.../selftests/bpf/prog_tests/bpf_tcp_ca.c | 16 ++++++++++++----
3 files changed, 18 insertions(+), 5 deletions(-)
--
2.43.0
serial_test_fexit_stress() has a non-robust handling of file descriptor
closure. If an error occurs, the function may exit without closing open
file descriptors, potentially causing resource leaks.
Fix the issue by closing file descriptors in reverse order and starting
from the last opened. Ensure proper closure even if an error occurs early.
Fixes: 8fb9fb2f1728 ("selftests/bpf: Query BPF_MAX_TRAMP_LINKS using BTF")
Signed-off-by: Ma Ke <make24(a)iscas.ac.cn>
---
tools/testing/selftests/bpf/prog_tests/fexit_stress.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/fexit_stress.c b/tools/testing/selftests/bpf/prog_tests/fexit_stress.c
index 596536def43d..b1980bd61583 100644
--- a/tools/testing/selftests/bpf/prog_tests/fexit_stress.c
+++ b/tools/testing/selftests/bpf/prog_tests/fexit_stress.c
@@ -49,11 +49,14 @@ void serial_test_fexit_stress(void)
ASSERT_OK(err, "bpf_prog_test_run_opts");
out:
- for (i = 0; i < bpf_max_tramp_links; i++) {
+ if (i >= bpf_max_tramp_links)
+ i = bpf_max_tramp_links - 1;
+ while (i >= 0) {
if (link_fd[i])
close(link_fd[i]);
if (fexit_fd[i])
close(fexit_fd[i]);
+ i--;
}
free(fd);
}
--
2.25.1
The selftest noncont_cat_run_test fails on AMD with the warnings. Reason
is, AMD supports non contiguous CBM masks but does not report it via CPUID.
Update noncont_cat_run_test to check for the vendor when verifying CPUID.
Fixes: ae638551ab64 ("selftests/resctrl: Add non-contiguous CBMs CAT test")
Signed-off-by: Babu Moger <babu.moger(a)amd.com>
---
This was part of the series
https://lore.kernel.org/lkml/cover.1708637563.git.babu.moger@amd.com/
Sending this as a separate fix per review comments.
---
tools/testing/selftests/resctrl/cat_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/resctrl/cat_test.c b/tools/testing/selftests/resctrl/cat_test.c
index d4dffc934bc3..b2988888786e 100644
--- a/tools/testing/selftests/resctrl/cat_test.c
+++ b/tools/testing/selftests/resctrl/cat_test.c
@@ -308,7 +308,7 @@ static int noncont_cat_run_test(const struct resctrl_test *test,
else
return -EINVAL;
- if (sparse_masks != ((ecx >> 3) & 1)) {
+ if ((get_vendor() == ARCH_INTEL) && sparse_masks != ((ecx >> 3) & 1)) {
ksft_print_msg("CPUID output doesn't match 'sparse_masks' file content!\n");
return 1;
}
--
2.34.1
The open() function returns -1 on error. openat() and open() initialize
'from' and 'to', and only 'from' validated with 'if' statement. If the
initialization of variable 'to' fails, we should better check the value
of 'to' and close 'from' to avoid possible file leak.
Fixes: 32ae976ed3b5 ("selftests/capabilities: Add tests for capability evolution")
Signed-off-by: Ma Ke <make24(a)iscas.ac.cn>
---
Found this error through static analysis.
---
tools/testing/selftests/capabilities/test_execve.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/capabilities/test_execve.c b/tools/testing/selftests/capabilities/test_execve.c
index 47bad7ddc5bc..de187eff177d 100644
--- a/tools/testing/selftests/capabilities/test_execve.c
+++ b/tools/testing/selftests/capabilities/test_execve.c
@@ -149,6 +149,10 @@ static void copy_fromat_to(int fromfd, const char *fromname, const char *toname)
ksft_exit_fail_msg("open copy source - %s\n", strerror(errno));
int to = open(toname, O_CREAT | O_WRONLY | O_EXCL, 0700);
+ if (to == -1) {
+ close(from);
+ ksft_exit_fail_msg("open copy destination - %s\n", strerror(errno));
+ }
while (true) {
char buf[4096];
--
2.25.1
This patch series is motivated by the following observation:
Raise a signal, jump to signal handler. The ucontext_t structure dumped
by kernel to userspace has a uc_sigmask field having the mask of blocked
signals. If you run a fresh minimalistic program doing this, this field
is empty, even if you block some signals while registering the handler
with sigaction().
Here is what the man-pages have to say:
sigaction(2): "sa_mask specifies a mask of signals which should be blocked
(i.e., added to the signal mask of the thread in which the signal handler
is invoked) during execution of the signal handler. In addition, the
signal which triggered the handler will be blocked, unless the SA_NODEFER
flag is used."
signal(7): Under "Execution of signal handlers", (1.3) implies:
"The thread's current signal mask is accessible via the ucontext_t
object that is pointed to by the third argument of the signal handler."
But, (1.4) states:
"Any signals specified in act->sa_mask when registering the handler with
sigprocmask(2) are added to the thread's signal mask. The signal being
delivered is also added to the signal mask, unless SA_NODEFER was
specified when registering the handler. These signals are thus blocked
while the handler executes."
There clearly is no distinction being made in the man pages between
"Thread's signal mask" and ucontext_t; this logically should imply
that a signal blocked by populating struct sigaction should be visible
in ucontext_t.
Here is what the kernel code does (for Aarch64):
do_signal() -> handle_signal() -> sigmask_to_save(), which returns
¤t->blocked, is passed to setup_rt_frame() -> setup_sigframe() ->
__copy_to_user(). Hence, ¤t->blocked is copied to ucontext_t
exposed to userspace. Returning back to handle_signal(),
signal_setup_done() -> signal_delivered() -> sigorsets() and
set_current_blocked() are responsible for using information from
struct ksignal ksig, which was populated through the sigaction()
system call in kernel/signal.c:
copy_from_user(&new_sa.sa, act, sizeof(new_sa.sa)),
to update ¤t->blocked; hence, the set of blocked signals for the
current thread is updated AFTER the kernel dumps ucontext_t to
userspace.
Assuming that the above is indeed the intended behaviour, because it
semantically makes sense, since the signals blocked using sigaction()
remain blocked only till the execution of the handler, and not in the
context present before jumping to the handler (but nothing can be
confirmed from the man-pages), the series introduces a test for
mangling with uc_sigmask. I will send a separate series to fix the
man-pages.
The proposed selftest has been tested out on Aarch32, Aarch64 and x86_64.
v2->v3:
- ucontext describes current state -> ucontext describes interrupted context
- Add a comment for blockage of USR2 even after return from handler
- Describe blockage of signals in a better way
v1->v2:
- Replace all occurrences of SIGPIPE with SIGSEGV
- Fixed a mismatch between code comment and ksft log
- Add a testcase: Raise the same signal again; it must not be queued
- Remove unneeded <assert.h>, <unistd.h>
- Give a detailed test description in the comments; also describe the
exact meaning of delivered and blocked
- Handle errors for all libc functions/syscalls
- Mention tests in Makefile and .gitignore in alphabetical order
v1:
- https://lore.kernel.org/all/20240607122319.768640-1-dev.jain@arm.com/
Dev Jain (2):
selftests: Rename sigaltstack to generic signal
selftests: Add a test mangling with uc_sigmask
tools/testing/selftests/Makefile | 2 +-
.../{sigaltstack => signal}/.gitignore | 3 +-
.../{sigaltstack => signal}/Makefile | 3 +-
.../current_stack_pointer.h | 0
.../selftests/signal/mangle_uc_sigmask.c | 194 ++++++++++++++++++
.../sas.c => signal/sigaltstack.c} | 0
6 files changed, 199 insertions(+), 3 deletions(-)
rename tools/testing/selftests/{sigaltstack => signal}/.gitignore (57%)
rename tools/testing/selftests/{sigaltstack => signal}/Makefile (53%)
rename tools/testing/selftests/{sigaltstack => signal}/current_stack_pointer.h (100%)
create mode 100644 tools/testing/selftests/signal/mangle_uc_sigmask.c
rename tools/testing/selftests/{sigaltstack/sas.c => signal/sigaltstack.c} (100%)
--
2.34.1