Add support for synchronous signals on perf events
Subsystems (11)
v4 cover Add support for synchronous signals on perf events
The perf subsystem today unifies various tracing and monitoring features, from both software and hardware. One benefit of the perf subsystem is automatically inheriting events to child tasks, which enables process-wide events monitoring with low overheads. By default perf events are non-intrusive, not affecting behaviour of the tasks being monitored.
For certain use-cases, however, it makes sense to leverage the generality of the perf events subsystem and optionally allow the tasks being monitored to receive signals on events they are interested in. This patch series adds the option to synchronously signal user space on events.
To better support process-wide synchronous self-monitoring, without events propagating to children that do not share the current process's shared environment, two pre-requisite patches are added to optionally restrict inheritance to CLONE_THREAD, and remove events on exec (without affecting the parent).
Examples how to use these features can be found in the tests added at the end of the series. In addition to the tests added, the series has also been subjected to syzkaller fuzzing (focus on 'kernel/events/' coverage).
Motivation and Example Uses
---------------------------
1. Our immediate motivation is low-overhead sampling-based race
detection for user space [1]. By using perf_event_open() at process initialization, we can create hardware breakpoint/watchpoint events that are propagated automatically to all threads in a process. As far as we are aware, today no existing kernel facility (such as ptrace) allows us to set up process-wide watchpoints with minimal overheads (that are comparable to mprotect() of whole pages).
2. Other low-overhead error detectors that rely on detecting
accesses to certain memory locations or code, process-wide and also only in a specific set of subtasks or threads.
[1] https://llvm.org/devmtg/2020-09/slides/Morehouse-GWP-Tsan.pdf
Other ideas for use-cases we found interesting, but should only illustrate the range of potential to further motivate the utility (we're sure there are more):
3. Code hot patching without full stop-the-world. Specifically, by
setting a code breakpoint to entry to the patched routine, then send signals to threads and check that they are not in the routine, but without stopping them further. If any of the threads will enter the routine, it will receive SIGTRAP and pause.
4. Safepoints without mprotect(). Some Java implementations use
"load from a known memory location" as a safepoint. When threads need to be stopped, the page containing the location is mprotect()ed and threads get a signal. This could be replaced with a watchpoint, which does not require a whole page nor DTLB shootdowns.
5. Threads receiving signals on performance events to
throttle/unthrottle themselves.
6. Tracking data flow globally.
Changelog
---------
v4:
* Fix for parent and child racing to exit in sync_child_event().
* Fix race between irq_work running and task's sighand being released by release_task().
* Generalize setting si_perf and si_addr independent of event type; introduces perf_event_attr::sig_data, which can be set by user space to be propagated to si_perf.
* Warning in perf_sigtrap() if ctx->task and current mismatch; we expect this on architectures that do not properly implement arch_irq_work_raise().
* Require events that want sigtrap to be associated with a task.
* Dropped "perf: Add breakpoint information to siginfo on SIGTRAP" in favor of more generic solution (perf_event_attr::sig_data).
v3:
* Add patch "perf: Rework perf_event_exit_event()" to beginning of series, courtesy of Peter Zijlstra.
* Rework "perf: Add support for event removal on exec" based on the added "perf: Rework perf_event_exit_event()".
* Fix kselftests to work with more recent libc, due to the way it forces using the kernel's own siginfo_t.
* Add basic perf-tool built-in test.
v2/RFC: https://lkml.kernel.org/r/[email protected]
* Patch "Support only inheriting events if cloned with CLONE_THREAD" added to series.
* Patch "Add support for event removal on exec" added to series.
* Patch "Add kselftest for process-wide sigtrap handling" added to series.
* Patch "Add kselftest for remove_on_exec" added to series.
* Implicitly restrict inheriting events if sigtrap, but the child was cloned with CLONE_CLEAR_SIGHAND, because it is not generally safe if the child cleared all signal handlers to continue sending SIGTRAP.
* Various minor fixes (see details in patches).
v1/RFC: https://lkml.kernel.org/r/[email protected]
Pre-series: The discussion at [2] led to the changes in this series. The approach taken in "Add support for SIGTRAP on perf events" to trigger the signal was suggested by Peter Zijlstra in [3].
[2] https://lore.kernel.org/lkml/CACT4Y+YPrXGw+AtESxAgPyZ84TYkNZdP0xpocX2jwVAbZD=-XQ@mail.gmail.com/
[3] https://lore.kernel.org/lkml/[email protected]/
Marco Elver (9):
perf: Apply PERF_EVENT_IOC_MODIFY_ATTRIBUTES to children
perf: Support only inheriting events if cloned with CLONE_THREAD
perf: Add support for event removal on exec
signal: Introduce TRAP_PERF si_code and si_perf to siginfo
perf: Add support for SIGTRAP on perf events selftests/perf_events: Add kselftest for process-wide sigtrap handling selftests/perf_events: Add kselftest for remove_on_exec tools headers uapi: Sync tools/include/uapi/linux/perf_event.h perf test: Add basic stress test for sigtrap handling
Peter Zijlstra (1):
perf: Rework perf_event_exit_event()
arch/m68k/kernel/signal.c | 3 + arch/x86/kernel/signal_compat.c | 5 +- fs/signalfd.c | 4 + include/linux/compat.h | 2 + include/linux/perf_event.h | 9 +- include/linux/signal.h | 1 + include/uapi/asm-generic/siginfo.h | 6 +- include/uapi/linux/perf_event.h | 12 +- include/uapi/linux/signalfd.h | 4 +- kernel/events/core.c | 302 +++++++++++++----- kernel/fork.c | 2 +- kernel/signal.c | 11 + tools/include/uapi/linux/perf_event.h | 12 +- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 5 + tools/perf/tests/sigtrap.c | 150 +++++++++ tools/perf/tests/tests.h | 1 + .../testing/selftests/perf_events/.gitignore | 3 + tools/testing/selftests/perf_events/Makefile | 6 + tools/testing/selftests/perf_events/config | 1 + .../selftests/perf_events/remove_on_exec.c | 260 +++++++++++++++ tools/testing/selftests/perf_events/settings | 1 + .../selftests/perf_events/sigtrap_threads.c | 210 ++++++++++++ 23 files changed, 924 insertions(+), 87 deletions(-) create mode 100644 tools/perf/tests/sigtrap.c create mode 100644 tools/testing/selftests/perf_events/.gitignore create mode 100644 tools/testing/selftests/perf_events/Makefile create mode 100644 tools/testing/selftests/perf_events/config create mode 100644 tools/testing/selftests/perf_events/remove_on_exec.c create mode 100644 tools/testing/selftests/perf_events/settings create mode 100644 tools/testing/selftests/perf_events/sigtrap_threads.c
Signature · 1 line
2.31.0.208.g409f899ff0-goog
PATCH v4 1/10 perf: Rework perf_event_exit_event()
From: Peter Zijlstra <[email protected]>
Make perf_event_exit_event() more robust, such that we can use it from other contexts. Specifically the up and coming remove_on_exec.
For this to work we need to address a few issues. Remove_on_exec will not destroy the entire context, so we cannot rely on TASK_TOMBSTONE to disable event_function_call() and we thus have to use perf_remove_from_context().
When using perf_remove_from_context(), there's two races to consider. The first is against close(), where we can have concurrent tear-down of the event. The second is against child_list iteration, which should not find a half baked event.
To address this, teach perf_remove_from_context() to special case !ctx->is_active and about DETACH_CHILD.
---
v4:
* Fix for parent and child racing to exit in sync_child_event().
v3:
* New dependency for series:
https://lkml.kernel.org/r/YFn/[email protected]
--- include/linux/perf_event.h | 1 + kernel/events/core.c | 142 +++++++++++++++++++++---------------- 2 files changed, 80 insertions(+), 63 deletions(-)
include/linux/perf_event.h +1 -0
@@ -607,6 +607,7 @@ struct swevent_hlist {#define PERF_ATTACH_TASK_DATA 0x08#define PERF_ATTACH_ITRACE 0x10#define PERF_ATTACH_SCHED_CB 0x20 +#define PERF_ATTACH_CHILD 0x40struct perf_cgroup ;struct perf_buffer ;
kernel/events/core.c +79 -63
209 lines not on this page · raw message
Signature · 1 line
2.31.0.208.g409f899ff0-goog
[tip: perf/core] perf: Rework perf_event_exit_event()
The following commit has been merged into the perf/core branch of tip:
The following commit has been merged into the perf/core branch of tip:
Commit-ID: ef54c1a476aef7eef26fe13ea10dc090952c00f8 Gitweb: https://git.kernel.org/tip/ef54c1a476aef7eef26fe13ea10dc090952c00f8 Author: Peter Zijlstra <[email protected]> AuthorDate: Thu, 08 Apr 2021 12:35:56 +02:00 Committer: Peter Zijlstra <[email protected]> CommitterDate: Fri, 16 Apr 2021 16:32:40 +02:00
perf: Rework perf_event_exit_event()
Make perf_event_exit_event() more robust, such that we can use it from other contexts. Specifically the up and coming remove_on_exec.
For this to work we need to address a few issues. Remove_on_exec will not destroy the entire context, so we cannot rely on TASK_TOMBSTONE to disable event_function_call() and we thus have to use perf_remove_from_context().
When using perf_remove_from_context(), there's two races to consider. The first is against close(), where we can have concurrent tear-down of the event. The second is against child_list iteration, which should not find a half baked event.
To address this, teach perf_remove_from_context() to special case !ctx->is_active and about DETACH_CHILD.
--- include/linux/perf_event.h | 1 +- kernel/events/core.c | 142 ++++++++++++++++++++---------------- 2 files changed, 80 insertions(+), 63 deletions(-)
include/linux/perf_event.h +1 -0
@@ -607,6 +607,7 @@ struct swevent_hlist {#define PERF_ATTACH_TASK_DATA 0x08#define PERF_ATTACH_ITRACE 0x10#define PERF_ATTACH_SCHED_CB 0x20 +#define PERF_ATTACH_CHILD 0x40struct perf_cgroup ;struct perf_buffer ;
kernel/events/core.c +79 -63
209 lines not on this page · raw message
PATCH v4 2/10 perf: Apply PERF_EVENT_IOC_MODIFY_ATTRIBUTES to children
In reply to Marco ElverAs with other ioctls (such as PERF_EVENT_IOC_{ENABLE,DISABLE}), fix up handling of PERF_EVENT_IOC_MODIFY_ATTRIBUTES to also apply to children.
--- kernel/events/core.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
kernel/events/core.c +21 -1
@@ -3199,16 +3199,36 @@ static int perf_event_modify_breakpoint(struct perf_event *bp,static int perf_event_modify_attr (struct perf_event *event,struct perf_event_attr *attr) { +int (*func)(struct perf_event *,struct perf_event_attr *); +struct perf_event *child; +int err; +if (event->attr.type != attr->type)return -EINVAL ;switch (event->attr.type) {case PERF_TYPE_BREAKPOINT : -return perf_event_modify_breakpoint (event, attr); + func = perf_event_modify_breakpoint; +break ;default :/* Place holder for future additions. */ return -EOPNOTSUPP ; } + +WARN_ON_ONCE (event->ctx->parent_ctx); + +mutex_lock (&event->child_mutex); + err =func (event, attr); +if (err) + goto out; +list_for_each_entry (child, &event->child_list, child_list) { + err =func (child, attr); +if (err) + goto out; + } +out: +mutex_unlock (&event->child_mutex); +return err; } static void ctx_sched_out(struct perf_event_context *ctx,
Signature · 1 line
2.31.0.208.g409f899ff0-goog
[tip: perf/core] perf: Apply PERF_EVENT_IOC_MODIFY_ATTRIBUTES to children
The following commit has been merged into the perf/core branch of tip:
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 47f661eca0700928012e11c57ea0328f5ccfc3b9 Gitweb: https://git.kernel.org/tip/47f661eca0700928012e11c57ea0328f5ccfc3b9 Author: Marco Elver <[email protected]> AuthorDate: Thu, 08 Apr 2021 12:35:57 +02:00 Committer: Peter Zijlstra <[email protected]> CommitterDate: Fri, 16 Apr 2021 16:32:40 +02:00
perf: Apply PERF_EVENT_IOC_MODIFY_ATTRIBUTES to children
As with other ioctls (such as PERF_EVENT_IOC_{ENABLE,DISABLE}), fix up handling of PERF_EVENT_IOC_MODIFY_ATTRIBUTES to also apply to children.
--- kernel/events/core.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
kernel/events/core.c +21 -1
@@ -3200,16 +3200,36 @@ static int perf_event_modify_breakpoint(struct perf_event *bp,static int perf_event_modify_attr (struct perf_event *event,struct perf_event_attr *attr) { +int (*func)(struct perf_event *,struct perf_event_attr *); +struct perf_event *child; +int err; +if (event->attr.type != attr->type)return -EINVAL ;switch (event->attr.type) {case PERF_TYPE_BREAKPOINT : -return perf_event_modify_breakpoint (event, attr); + func = perf_event_modify_breakpoint; +break ;default :/* Place holder for future additions. */ return -EOPNOTSUPP ; } + +WARN_ON_ONCE (event->ctx->parent_ctx); + +mutex_lock (&event->child_mutex); + err =func (event, attr); +if (err) + goto out; +list_for_each_entry (child, &event->child_list, child_list) { + err =func (child, attr); +if (err) + goto out; + } +out: +mutex_unlock (&event->child_mutex); +return err; } static void ctx_sched_out(struct perf_event_context *ctx,
PATCH v4 3/10 perf: Support only inheriting events if cloned with CLONE_THREAD
In reply to Marco ElverAdds bit perf_event_attr::inherit_thread, to restricting inheriting events only if the child was cloned with CLONE_THREAD.
This option supports the case where an event is supposed to be process-wide only (including subthreads), but should not propagate beyond the current process's shared environment.
---
v2:
* Add patch to series.
--- include/linux/perf_event.h | 5 +++-- include/uapi/linux/perf_event.h | 3 ++- kernel/events/core.c | 21 ++++++++++++++------- kernel/fork.c | 2 +- 4 files changed, 20 insertions(+), 11 deletions(-)
include/linux/perf_event.h +3 -2
@@ -958,7 +958,7 @@ extern void __perf_event_task_sched_in(struct task_struct *prev, struct task_struct *task);extern void __perf_event_task_sched_out (struct task_struct *prev,struct task_struct *next); -extern int perf_event_init_task (struct task_struct *child); +extern int perf_event_init_task (struct task_struct *child,u64 clone_flags);extern void perf_event_exit_task (struct task_struct *child);extern void perf_event_free_task (struct task_struct *task);extern void perf_event_delayed_put (struct task_struct *task);
@@ -1449,7 +1449,8 @@ perf_event_task_sched_in(struct task_struct *prev,static inline void perf_event_task_sched_out (struct task_struct *prev,struct task_struct *next) { } -static inline int perf_event_init_task (struct task_struct *child) {return 0 ; } +static inline int perf_event_init_task (struct task_struct *child, +u64 clone_flags) {return 0 ; }static inline void perf_event_exit_task (struct task_struct *child) { }static inline void perf_event_free_task (struct task_struct *task) { }static inline void perf_event_delayed_put (struct task_struct *task) { }
include/uapi/linux/perf_event.h +2 -1
@@ -389,7 +389,8 @@ struct perf_event_attr { cgroup : 1, /* include cgroup events */ text_poke : 1, /* include text poke events */ build_id : 1, /* use build id in mmap2 events */ - __reserved_1 : 29; + inherit_thread : 1, /* children only inherit if cloned with CLONE_THREAD */ + __reserved_1 : 28;union {__u32 wakeup_events;/* wakeup every n events */
kernel/events/core.c +14 -7
@@ -11649,6 +11649,9 @@ static int perf_copy_attr(struct perf_event_attr __user *uattr, (attr->sample_type & PERF_SAMPLE_WEIGHT_STRUCT))return -EINVAL ; +if (!attr->inherit && attr->inherit_thread) +return -EINVAL ; + out:return ret;
@@ -12869,12 +12872,13 @@ static int inherit_task_group(struct perf_event *event, struct task_struct *parent, struct perf_event_context *parent_ctx, struct task_struct *child, int ctxn, - int *inherited_all) + u64 clone_flags, int *inherited_all) { int ret;struct perf_event_context *child_ctx; -if (!event->attr.inherit) { +if (!event->attr.inherit || + (event->attr.inherit_thread && !(clone_flags &CLONE_THREAD ))) { *inherited_all =0 ;return 0 ; }
@@ -12906,7 +12910,8 @@ inherit_task_group(struct perf_event *event, struct task_struct *parent,/* * Initialize the perf_event context in task_struct */ -static int perf_event_init_context (struct task_struct *child,int ctxn) +static int perf_event_init_context (struct task_struct *child,int ctxn, +u64 clone_flags) {struct perf_event_context *child_ctx, *parent_ctx;struct perf_event_context *cloned_ctx;
@@ -12946,7 +12951,8 @@ static int perf_event_init_context(struct task_struct *child, int ctxn)*/ perf_event_groups_for_each (event, &parent_ctx->pinned_groups) { ret =inherit_task_group (event, parent, parent_ctx, - child, ctxn, &inherited_all); + child, ctxn, clone_flags, + &inherited_all);if (ret) goto out_unlock; }
@@ -12962,7 +12968,8 @@ static int perf_event_init_context(struct task_struct *child, int ctxn)perf_event_groups_for_each (event, &parent_ctx->flexible_groups) { ret =inherit_task_group (event, parent, parent_ctx, - child, ctxn, &inherited_all); + child, ctxn, clone_flags, + &inherited_all);if (ret) goto out_unlock; }
@@ -13004,7 +13011,7 @@ static int perf_event_init_context(struct task_struct *child, int ctxn)/* * Initialize the perf_event context in task_struct */ -int perf_event_init_task (struct task_struct *child) +int perf_event_init_task (struct task_struct *child,u64 clone_flags) {int ctxn, ret;
@@ -13013,7 +13020,7 @@ int perf_event_init_task(struct task_struct *child)INIT_LIST_HEAD (&child->perf_event_list);for_each_task_context_nr (ctxn) { - ret =perf_event_init_context (child, ctxn); + ret =perf_event_init_context (child, ctxn, clone_flags);if (ret) {perf_event_free_task (child);return ret;
kernel/fork.c +1 -1
@@ -2084,7 +2084,7 @@ static __latent_entropy struct task_struct *copy_process(if (retval) goto bad_fork_cleanup_policy; - retval =perf_event_init_task (p); + retval =perf_event_init_task (p, clone_flags);if (retval) goto bad_fork_cleanup_policy; retval =audit_alloc (p);
Signature · 1 line
2.31.0.208.g409f899ff0-goog
PATCH v4 4/10 perf: Add support for event removal on exec
In reply to Marco ElverAdds bit perf_event_attr::remove_on_exec, to support removing an event from a task on exec.
This option supports the case where an event is supposed to be process-wide only, and should not propagate beyond exec, to limit monitoring to the original process image only.
---
v3:
* Rework based on Peter's "perf: Rework perf_event_exit_event()" added to the beginning of the series. Intermediate attempts between v2 and this v3 can be found here:
https://lkml.kernel.org/r/[email protected]
v2:
* Add patch to series.
--- include/uapi/linux/perf_event.h | 3 +- kernel/events/core.c | 70 +++++++++++++++++++++++++++++---- 2 files changed, 64 insertions(+), 9 deletions(-)
include/uapi/linux/perf_event.h +2 -1
@@ -390,7 +390,8 @@ struct perf_event_attr { text_poke : 1, /* include text poke events */ build_id : 1, /* use build id in mmap2 events */ inherit_thread : 1, /* children only inherit if cloned with CLONE_THREAD */ - __reserved_1 : 28; + remove_on_exec : 1, /* event is removed from task on exec */ + __reserved_1 : 27;union {__u32 wakeup_events;/* wakeup every n events */
kernel/events/core.c +62 -8
92 lines not on this page · raw message
Signature · 1 line
2.31.0.208.g409f899ff0-goog
[tip: perf/core] perf: Add support for event removal on exec
The following commit has been merged into the perf/core branch of tip:
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 2e498d0a74e5b88a6689ae1b811f247f91ff188e Gitweb: https://git.kernel.org/tip/2e498d0a74e5b88a6689ae1b811f247f91ff188e Author: Marco Elver <[email protected]> AuthorDate: Thu, 08 Apr 2021 12:35:59 +02:00 Committer: Peter Zijlstra <[email protected]> CommitterDate: Fri, 16 Apr 2021 16:32:41 +02:00
perf: Add support for event removal on exec
Adds bit perf_event_attr::remove_on_exec, to support removing an event from a task on exec.
This option supports the case where an event is supposed to be process-wide only, and should not propagate beyond exec, to limit monitoring to the original process image only.
--- include/uapi/linux/perf_event.h | 3 +- kernel/events/core.c | 70 ++++++++++++++++++++++++++++---- 2 files changed, 64 insertions(+), 9 deletions(-)
include/uapi/linux/perf_event.h +2 -1
@@ -390,7 +390,8 @@ struct perf_event_attr { text_poke : 1, /* include text poke events */ build_id : 1, /* use build id in mmap2 events */ inherit_thread : 1, /* children only inherit if cloned with CLONE_THREAD */ - __reserved_1 : 28; + remove_on_exec : 1, /* event is removed from task on exec */ + __reserved_1 : 27;union {__u32 wakeup_events;/* wakeup every n events */
kernel/events/core.c +62 -8
92 lines not on this page · raw message
PATCH v4 5/10 signal: Introduce TRAP_PERF si_code and si_perf to siginfo
In reply to Marco ElverIntroduces the TRAP_PERF si_code, and associated siginfo_t field si_perf. These will be used by the perf event subsystem to send signals (if requested) to the task where an event occurred.
--- arch/m68k/kernel/signal.c | 3 +++ arch/x86/kernel/signal_compat.c | 5 ++++- fs/signalfd.c | 4 ++++ include/linux/compat.h | 2 ++ include/linux/signal.h | 1 + include/uapi/asm-generic/siginfo.h | 6 +++++- include/uapi/linux/signalfd.h | 4 +++- kernel/signal.c | 11 +++++++++++ 8 files changed, 33 insertions(+), 3 deletions(-)
arch/m68k/kernel/signal.c +3 -0
@@ -622,6 +622,9 @@ static inline void siginfo_build_tests(void)/* _sigfault._addr_pkey */ BUILD_BUG_ON (offsetof(siginfo_t , si_pkey) !=0x12 ); +/* _sigfault._perf */ +BUILD_BUG_ON (offsetof(siginfo_t , si_perf) !=0x10 ); +/* _sigpoll */ BUILD_BUG_ON (offsetof(siginfo_t , si_band) !=0x0c );BUILD_BUG_ON (offsetof(siginfo_t , si_fd) !=0x10 );
arch/x86/kernel/signal_compat.c +4 -1
@@ -29,7 +29,7 @@ static inline void signal_compat_build_tests(void)BUILD_BUG_ON (NSIGFPE !=15 );BUILD_BUG_ON (NSIGSEGV !=9 );BUILD_BUG_ON (NSIGBUS !=5 ); -BUILD_BUG_ON (NSIGTRAP !=5 ); +BUILD_BUG_ON (NSIGTRAP !=6 );BUILD_BUG_ON (NSIGCHLD !=6 );BUILD_BUG_ON (NSIGSYS !=2 );
@@ -138,6 +138,9 @@ static inline void signal_compat_build_tests(void)BUILD_BUG_ON (offsetof(siginfo_t , si_pkey) !=0x20 );BUILD_BUG_ON (offsetof(compat_siginfo_t , si_pkey) !=0x14 ); +BUILD_BUG_ON (offsetof(siginfo_t , si_perf) !=0x18 ); +BUILD_BUG_ON (offsetof(compat_siginfo_t , si_perf) !=0x10 ); +CHECK_CSI_OFFSET (_sigpoll);CHECK_CSI_SIZE (_sigpoll,2 *sizeof (int ));CHECK_SI_SIZE (_sigpoll,4 *sizeof (int ));
fs/signalfd.c +4 -0
@@ -134,6 +134,10 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,#endif new.ssi_addr_lsb = (short ) kinfo->si_addr_lsb;break ; +case SIL_PERF_EVENT : + new.ssi_addr = (long ) kinfo->si_addr; + new.ssi_perf = kinfo->si_perf; +break ;case SIL_CHLD : new.ssi_pid = kinfo->si_pid; new.ssi_uid = kinfo->si_uid;
include/linux/compat.h +2 -0
@@ -236,6 +236,8 @@ typedef struct compat_siginfo {char _dummy_pkey[__COMPAT_ADDR_BND_PKEY_PAD];u32 _pkey; } _addr_pkey; +/* used when si_code=TRAP_PERF */ +compat_u64 _perf; }; } _sigfault;
include/linux/signal.h +1 -0
@@ -43,6 +43,7 @@ enum siginfo_layout {SIL_FAULT_MCEERR ,SIL_FAULT_BNDERR ,SIL_FAULT_PKUERR , +SIL_PERF_EVENT ,SIL_CHLD ,SIL_RT , SIL_SYS,
include/uapi/asm-generic/siginfo.h +5 -1
@@ -91,6 +91,8 @@ union __sifields {char _dummy_pkey[__ADDR_BND_PKEY_PAD];__u32 _pkey; } _addr_pkey; +/* used when si_code=TRAP_PERF */ +__u64 _perf; }; } _sigfault;
@@ -155,6 +157,7 @@ typedef struct siginfo {#define si_lower _sifields._sigfault._addr_bnd._lower#define si_upper _sifields._sigfault._addr_bnd._upper#define si_pkey _sifields._sigfault._addr_pkey._pkey +#define si_perf _sifields._sigfault._perf#define si_band _sifields._sigpoll._band#define si_fd _sifields._sigpoll._fd#define si_call_addr _sifields._sigsys._call_addr
@@ -253,7 +256,8 @@ typedef struct siginfo {#define TRAP_BRANCH 3/* process taken branch trap */ #define TRAP_HWBKPT 4/* hardware breakpoint/watchpoint */ #define TRAP_UNK 5/* undiagnosed trap */ -#define NSIGTRAP 5 +#define TRAP_PERF 6/* perf event with sigtrap=1 */ +#define NSIGTRAP 6/* * There is an additional set of SIGTRAP si_codes used by ptrace
include/uapi/linux/signalfd.h +3 -1
@@ -39,6 +39,8 @@ struct signalfd_siginfo {__s32 ssi_syscall;__u64 ssi_call_addr;__u32 ssi_arch; +__u32 __pad3; +__u64 ssi_perf;/* * Pad strcture to 128 bytes. Remember to update the
@@ -49,7 +51,7 @@ struct signalfd_siginfo {* comes out of a read(2) and we really don't want to have * a compat on read(2). */ -__u8 __pad[28 ]; +__u8 __pad[16 ]; };
kernel/signal.c +11 -0
@@ -1199,6 +1199,7 @@ static inline bool has_si_pid_and_uid(struct kernel_siginfo *info)case SIL_FAULT_MCEERR :case SIL_FAULT_BNDERR :case SIL_FAULT_PKUERR : +case SIL_PERF_EVENT :case SIL_SYS : ret = false;break ;
@@ -2531,6 +2532,7 @@ static void hide_si_addr_tag_bits(struct ksignal *ksig)case SIL_FAULT_MCEERR :case SIL_FAULT_BNDERR :case SIL_FAULT_PKUERR : +case SIL_PERF_EVENT : ksig->info.si_addr =arch_untagged_si_addr ( ksig->info.si_addr, ksig->sig, ksig->info.si_code);break ;
@@ -3341,6 +3343,10 @@ void copy_siginfo_to_external32(struct compat_siginfo *to,#endif to->si_pkey = from->si_pkey;break ; +case SIL_PERF_EVENT : + to->si_addr =ptr_to_compat (from->si_addr); + to->si_perf = from->si_perf; +break ;case SIL_CHLD : to->si_pid = from->si_pid; to->si_uid = from->si_uid;
@@ -3421,6 +3427,10 @@ static int post_copy_siginfo_from_user32(kernel_siginfo_t *to,#endif to->si_pkey = from->si_pkey;break ; +case SIL_PERF_EVENT : + to->si_addr =compat_ptr (from->si_addr); + to->si_perf = from->si_perf; +break ;case SIL_CHLD : to->si_pid = from->si_pid; to->si_uid = from->si_uid;
@@ -4601,6 +4611,7 @@ static inline void siginfo_buildtime_checks(void)CHECK_OFFSET (si_lower);CHECK_OFFSET (si_upper);CHECK_OFFSET (si_pkey); +CHECK_OFFSET (si_perf);/* sigpoll */ CHECK_OFFSET (si_band);
Signature · 1 line
2.31.0.208.g409f899ff0-goog
[tip: perf/core] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
The following commit has been merged into the perf/core branch of tip:
The following commit has been merged into the perf/core branch of tip:
Commit-ID: fb6cc127e0b6e629252cdd0f77d5a1f49db95b92 Gitweb: https://git.kernel.org/tip/fb6cc127e0b6e629252cdd0f77d5a1f49db95b92 Author: Marco Elver <[email protected]> AuthorDate: Thu, 08 Apr 2021 12:36:00 +02:00 Committer: Peter Zijlstra <[email protected]> CommitterDate: Fri, 16 Apr 2021 16:32:41 +02:00
signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Introduces the TRAP_PERF si_code, and associated siginfo_t field si_perf. These will be used by the perf event subsystem to send signals (if requested) to the task where an event occurred.
--- arch/m68k/kernel/signal.c | 3 +++ arch/x86/kernel/signal_compat.c | 5 ++++- fs/signalfd.c | 4 ++++ include/linux/compat.h | 2 ++ include/linux/signal.h | 1 + include/uapi/asm-generic/siginfo.h | 6 +++++- include/uapi/linux/signalfd.h | 4 +++- kernel/signal.c | 11 +++++++++++ 8 files changed, 33 insertions(+), 3 deletions(-)
arch/m68k/kernel/signal.c +3 -0
@@ -622,6 +622,9 @@ static inline void siginfo_build_tests(void)/* _sigfault._addr_pkey */ BUILD_BUG_ON (offsetof(siginfo_t , si_pkey) !=0x12 ); +/* _sigfault._perf */ +BUILD_BUG_ON (offsetof(siginfo_t , si_perf) !=0x10 ); +/* _sigpoll */ BUILD_BUG_ON (offsetof(siginfo_t , si_band) !=0x0c );BUILD_BUG_ON (offsetof(siginfo_t , si_fd) !=0x10 );
arch/x86/kernel/signal_compat.c +4 -1
@@ -29,7 +29,7 @@ static inline void signal_compat_build_tests(void)BUILD_BUG_ON (NSIGFPE !=15 );BUILD_BUG_ON (NSIGSEGV !=9 );BUILD_BUG_ON (NSIGBUS !=5 ); -BUILD_BUG_ON (NSIGTRAP !=5 ); +BUILD_BUG_ON (NSIGTRAP !=6 );BUILD_BUG_ON (NSIGCHLD !=6 );BUILD_BUG_ON (NSIGSYS !=2 );
@@ -138,6 +138,9 @@ static inline void signal_compat_build_tests(void)BUILD_BUG_ON (offsetof(siginfo_t , si_pkey) !=0x20 );BUILD_BUG_ON (offsetof(compat_siginfo_t , si_pkey) !=0x14 ); +BUILD_BUG_ON (offsetof(siginfo_t , si_perf) !=0x18 ); +BUILD_BUG_ON (offsetof(compat_siginfo_t , si_perf) !=0x10 ); +CHECK_CSI_OFFSET (_sigpoll);CHECK_CSI_SIZE (_sigpoll,2 *sizeof (int ));CHECK_SI_SIZE (_sigpoll,4 *sizeof (int ));
fs/signalfd.c +4 -0
@@ -134,6 +134,10 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,#endif new.ssi_addr_lsb = (short ) kinfo->si_addr_lsb;break ; +case SIL_PERF_EVENT : + new.ssi_addr = (long ) kinfo->si_addr; + new.ssi_perf = kinfo->si_perf; +break ;case SIL_CHLD : new.ssi_pid = kinfo->si_pid; new.ssi_uid = kinfo->si_uid;
include/linux/compat.h +2 -0
@@ -236,6 +236,8 @@ typedef struct compat_siginfo {char _dummy_pkey[__COMPAT_ADDR_BND_PKEY_PAD];u32 _pkey; } _addr_pkey; +/* used when si_code=TRAP_PERF */ +compat_u64 _perf; }; } _sigfault;
include/linux/signal.h +1 -0
@@ -43,6 +43,7 @@ enum siginfo_layout {SIL_FAULT_MCEERR ,SIL_FAULT_BNDERR ,SIL_FAULT_PKUERR , +SIL_PERF_EVENT ,SIL_CHLD ,SIL_RT , SIL_SYS,
include/uapi/asm-generic/siginfo.h +5 -1
@@ -91,6 +91,8 @@ union __sifields {char _dummy_pkey[__ADDR_BND_PKEY_PAD];__u32 _pkey; } _addr_pkey; +/* used when si_code=TRAP_PERF */ +__u64 _perf; }; } _sigfault;
@@ -155,6 +157,7 @@ typedef struct siginfo {#define si_lower _sifields._sigfault._addr_bnd._lower#define si_upper _sifields._sigfault._addr_bnd._upper#define si_pkey _sifields._sigfault._addr_pkey._pkey +#define si_perf _sifields._sigfault._perf#define si_band _sifields._sigpoll._band#define si_fd _sifields._sigpoll._fd#define si_call_addr _sifields._sigsys._call_addr
@@ -253,7 +256,8 @@ typedef struct siginfo {#define TRAP_BRANCH 3/* process taken branch trap */ #define TRAP_HWBKPT 4/* hardware breakpoint/watchpoint */ #define TRAP_UNK 5/* undiagnosed trap */ -#define NSIGTRAP 5 +#define TRAP_PERF 6/* perf event with sigtrap=1 */ +#define NSIGTRAP 6/* * There is an additional set of SIGTRAP si_codes used by ptrace
include/uapi/linux/signalfd.h +3 -1
@@ -39,6 +39,8 @@ struct signalfd_siginfo {__s32 ssi_syscall;__u64 ssi_call_addr;__u32 ssi_arch; +__u32 __pad3; +__u64 ssi_perf;/* * Pad strcture to 128 bytes. Remember to update the
@@ -49,7 +51,7 @@ struct signalfd_siginfo {* comes out of a read(2) and we really don't want to have * a compat on read(2). */ -__u8 __pad[28 ]; +__u8 __pad[16 ]; };
kernel/signal.c +11 -0
@@ -1199,6 +1199,7 @@ static inline bool has_si_pid_and_uid(struct kernel_siginfo *info)case SIL_FAULT_MCEERR :case SIL_FAULT_BNDERR :case SIL_FAULT_PKUERR : +case SIL_PERF_EVENT :case SIL_SYS : ret = false;break ;
@@ -2531,6 +2532,7 @@ static void hide_si_addr_tag_bits(struct ksignal *ksig)case SIL_FAULT_MCEERR :case SIL_FAULT_BNDERR :case SIL_FAULT_PKUERR : +case SIL_PERF_EVENT : ksig->info.si_addr =arch_untagged_si_addr ( ksig->info.si_addr, ksig->sig, ksig->info.si_code);break ;
@@ -3333,6 +3335,10 @@ void copy_siginfo_to_external32(struct compat_siginfo *to,#endif to->si_pkey = from->si_pkey;break ; +case SIL_PERF_EVENT : + to->si_addr =ptr_to_compat (from->si_addr); + to->si_perf = from->si_perf; +break ;case SIL_CHLD : to->si_pid = from->si_pid; to->si_uid = from->si_uid;
@@ -3413,6 +3419,10 @@ static int post_copy_siginfo_from_user32(kernel_siginfo_t *to,#endif to->si_pkey = from->si_pkey;break ; +case SIL_PERF_EVENT : + to->si_addr =compat_ptr (from->si_addr); + to->si_perf = from->si_perf; +break ;case SIL_CHLD : to->si_pid = from->si_pid; to->si_uid = from->si_uid;
@@ -4593,6 +4603,7 @@ static inline void siginfo_buildtime_checks(void)CHECK_OFFSET (si_lower);CHECK_OFFSET (si_upper);CHECK_OFFSET (si_pkey); +CHECK_OFFSET (si_perf);/* sigpoll */ CHECK_OFFSET (si_band);
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
In reply to Marco ElverHi Marco,
Quoted 7 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals (if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>
This patch landed in linux-next as commit fb6cc127e0b6 ("signal:
Introduce TRAP_PERF si_code and si_perf to siginfo"). It causes regression on my test systems (arm 32bit and 64bit). Most systems fails to boot in the given time frame. I've observed that there is a timeout waiting for udev to populate /dev and then also during the network interfaces configuration. Reverting this commit, together with 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") to let it compile, on top of next-20210420 fixes the issue.
Quoted 184 lines
--- arch/m68k/kernel/signal.c | 3 +++ arch/x86/kernel/signal_compat.c | 5 ++++- fs/signalfd.c | 4 ++++ include/linux/compat.h | 2 ++ include/linux/signal.h | 1 + include/uapi/asm-generic/siginfo.h | 6 +++++- include/uapi/linux/signalfd.h | 4 +++- kernel/signal.c | 11 +++++++++++ 8 files changed, 33 insertions(+), 3 deletions(-)arch/m68k/kernel/signal.c +3
-0@@ -622,6 +622,9 @@ static inline void siginfo_build_tests(void)/* _sigfault._addr_pkey */ BUILD_BUG_ON (offsetof(siginfo_t , si_pkey) !=0x12 ); +/* _sigfault._perf */ +BUILD_BUG_ON (offsetof(siginfo_t , si_perf) !=0x10 ); +/* _sigpoll */ BUILD_BUG_ON (offsetof(siginfo_t , si_band) !=0x0c );BUILD_BUG_ON (offsetof(siginfo_t , si_fd) !=0x10 );arch/x86/kernel/signal_compat.c +4
-1@@ -29,7 +29,7 @@ static inline void signal_compat_build_tests(void)BUILD_BUG_ON (NSIGFPE !=15 );BUILD_BUG_ON (NSIGSEGV !=9 );BUILD_BUG_ON (NSIGBUS !=5 ); -BUILD_BUG_ON (NSIGTRAP !=5 ); +BUILD_BUG_ON (NSIGTRAP !=6 );BUILD_BUG_ON (NSIGCHLD !=6 );BUILD_BUG_ON (NSIGSYS !=2 );@@ -138,6 +138,9 @@ static inline void signal_compat_build_tests(void)BUILD_BUG_ON (offsetof(siginfo_t , si_pkey) !=0x20 );BUILD_BUG_ON (offsetof(compat_siginfo_t , si_pkey) !=0x14 ); +BUILD_BUG_ON (offsetof(siginfo_t , si_perf) !=0x18 ); +BUILD_BUG_ON (offsetof(compat_siginfo_t , si_perf) !=0x10 ); +CHECK_CSI_OFFSET (_sigpoll);CHECK_CSI_SIZE (_sigpoll,2 *sizeof (int ));CHECK_SI_SIZE (_sigpoll,4 *sizeof (int ));fs/signalfd.c +4
-0@@ -134,6 +134,10 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,#endif new.ssi_addr_lsb = (short ) kinfo->si_addr_lsb;break ; +case SIL_PERF_EVENT : + new.ssi_addr = (long ) kinfo->si_addr; + new.ssi_perf = kinfo->si_perf; +break ;case SIL_CHLD : new.ssi_pid = kinfo->si_pid; new.ssi_uid = kinfo->si_uid;include/linux/compat.h +2
-0@@ -236,6 +236,8 @@ typedef struct compat_siginfo {char _dummy_pkey[__COMPAT_ADDR_BND_PKEY_PAD];u32 _pkey; } _addr_pkey; +/* used when si_code=TRAP_PERF */ +compat_u64 _perf; }; } _sigfault;include/linux/signal.h +1
-0@@ -43,6 +43,7 @@ enum siginfo_layout {SIL_FAULT_MCEERR ,SIL_FAULT_BNDERR ,SIL_FAULT_PKUERR , +SIL_PERF_EVENT ,SIL_CHLD ,SIL_RT , SIL_SYS,include/uapi/asm-generic/siginfo.h +5
-1@@ -91,6 +91,8 @@ union __sifields {char _dummy_pkey[__ADDR_BND_PKEY_PAD];__u32 _pkey; } _addr_pkey; +/* used when si_code=TRAP_PERF */ +__u64 _perf; }; } _sigfault;@@ -155,6 +157,7 @@ typedef struct siginfo {#define si_lower _sifields._sigfault._addr_bnd._lower#define si_upper _sifields._sigfault._addr_bnd._upper#define si_pkey _sifields._sigfault._addr_pkey._pkey +#define si_perf _sifields._sigfault._perf#define si_band _sifields._sigpoll._band#define si_fd _sifields._sigpoll._fd#define si_call_addr _sifields._sigsys._call_addr@@ -253,7 +256,8 @@ typedef struct siginfo {#define TRAP_BRANCH 3/* process taken branch trap */ #define TRAP_HWBKPT 4/* hardware breakpoint/watchpoint */ #define TRAP_UNK 5/* undiagnosed trap */ -#define NSIGTRAP 5 +#define TRAP_PERF 6/* perf event with sigtrap=1 */ +#define NSIGTRAP 6/* * There is an additional set of SIGTRAP si_codes used by ptrace include/uapi/linux/signalfd.h +3
-1@@ -39,6 +39,8 @@ struct signalfd_siginfo {__s32 ssi_syscall;__u64 ssi_call_addr;__u32 ssi_arch; +__u32 __pad3; +__u64 ssi_perf;/* * Pad strcture to 128 bytes. Remember to update the @@ -49,7 +51,7 @@ struct signalfd_siginfo {* comes out of a read(2) and we really don't want to have * a compat on read(2). */ -__u8 __pad[28 ]; +__u8 __pad[16 ]; };kernel/signal.c +10
-0@@ -1199,6 +1199,7 @@ static inline bool has_si_pid_and_uid(struct kernel_siginfo *info)case SIL_FAULT_MCEERR :case SIL_FAULT_BNDERR :case SIL_FAULT_PKUERR : +case SIL_PERF_EVENT :case SIL_SYS : ret = false;break ;@@ -2531,6 +2532,7 @@ static void hide_si_addr_tag_bits(struct ksignal *ksig)case SIL_FAULT_MCEERR :case SIL_FAULT_BNDERR :case SIL_FAULT_PKUERR : +case SIL_PERF_EVENT : ksig->info.si_addr =arch_untagged_si_addr ( ksig->info.si_addr, ksig->sig, ksig->info.si_code);break ;@@ -3341,6 +3343,10 @@ void copy_siginfo_to_external32(struct compat_siginfo *to,#endif to->si_pkey = from->si_pkey;break ; +case SIL_PERF_EVENT : + to->si_addr =ptr_to_compat (from->si_addr); + to->si_perf = from->si_perf; +break ;case SIL_CHLD : to->si_pid = from->si_pid; to->si_uid = from->si_uid;@@ -3421,6 +3427,10 @@ static int post_copy_siginfo_from_user32(kernel_siginfo_t *to,#endif to->si_pkey = from->si_pkey;break ; +case SIL_PERF_EVENT : + to->si_addr =compat_ptr (from->si_addr); + to->si_perf = from->si_perf; +break ;case SIL_CHLD : to->si_pid = from->si_pid; to->si_uid = from->si_uid;
kernel/signal.c static inline void siginfo_buildtime_checks(void) · line 4617
Quoted 7 lines
kernel/signal.c +1
-0@@ -4601,6 +4611,7 @@ static inline void siginfo_buildtime_checks(void)CHECK_OFFSET (si_lower);CHECK_OFFSET (si_upper);CHECK_OFFSET (si_pkey); +CHECK_OFFSET (si_perf);/* sigpoll */ CHECK_OFFSET (si_band);
Best regards
Signature · 2 lines
Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Quoted 12 lines · Marek Szyprowski
Hi Marco,
Quoted 7 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals (if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>
Quoted 8 lines
This patch landed in linux-next as commit
fb6cc127e0b6("signal:
IntroduceTRAP_PERFsi_codeandsi_perfto siginfo"). It causes regression on my test systems (arm 32bit and 64bit). Most systems fails to boot in the given time frame. I've observed that there is a timeout waiting for udev to populate /dev and then also during the network interfaces configuration. Reverting this commit, together with97ba62b27867("perf: Add support for SIGTRAP on perf events") to let it compile, on top of next-20210420 fixes the issue.
Thanks, this is weird for sure and nothing in particular stands out.
I have questions:
-- Can you please share your config?
-- Also, can you share how you run this? Can it be reproduced in qemu? -- How did you derive this patch to be at fault? Why not just 97ba62b27867, given you also need to revert it?
If you are unsure which patch exactly it is, can you try just reverting 97ba62b27867 and see what happens?
Thanks,
-- Marco
Quoted 197 lines
Quoted 184 lines
--- arch/m68k/kernel/signal.c | 3 +++ arch/x86/kernel/signal_compat.c | 5 ++++- fs/signalfd.c | 4 ++++ include/linux/compat.h | 2 ++ include/linux/signal.h | 1 + include/uapi/asm-generic/siginfo.h | 6 +++++- include/uapi/linux/signalfd.h | 4 +++- kernel/signal.c | 11 +++++++++++ 8 files changed, 33 insertions(+), 3 deletions(-)arch/m68k/kernel/signal.c +3
-0@@ -622,6 +622,9 @@ static inline void siginfo_build_tests(void)/* _sigfault._addr_pkey */ BUILD_BUG_ON (offsetof(siginfo_t , si_pkey) !=0x12 ); +/* _sigfault._perf */ +BUILD_BUG_ON (offsetof(siginfo_t , si_perf) !=0x10 ); +/* _sigpoll */ BUILD_BUG_ON (offsetof(siginfo_t , si_band) !=0x0c );BUILD_BUG_ON (offsetof(siginfo_t , si_fd) !=0x10 );arch/x86/kernel/signal_compat.c +4
-1@@ -29,7 +29,7 @@ static inline void signal_compat_build_tests(void)BUILD_BUG_ON (NSIGFPE !=15 );BUILD_BUG_ON (NSIGSEGV !=9 );BUILD_BUG_ON (NSIGBUS !=5 ); -BUILD_BUG_ON (NSIGTRAP !=5 ); +BUILD_BUG_ON (NSIGTRAP !=6 );BUILD_BUG_ON (NSIGCHLD !=6 );BUILD_BUG_ON (NSIGSYS !=2 );@@ -138,6 +138,9 @@ static inline void signal_compat_build_tests(void)BUILD_BUG_ON (offsetof(siginfo_t , si_pkey) !=0x20 );BUILD_BUG_ON (offsetof(compat_siginfo_t , si_pkey) !=0x14 ); +BUILD_BUG_ON (offsetof(siginfo_t , si_perf) !=0x18 ); +BUILD_BUG_ON (offsetof(compat_siginfo_t , si_perf) !=0x10 ); +CHECK_CSI_OFFSET (_sigpoll);CHECK_CSI_SIZE (_sigpoll,2 *sizeof (int ));CHECK_SI_SIZE (_sigpoll,4 *sizeof (int ));fs/signalfd.c +4
-0@@ -134,6 +134,10 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,#endif new.ssi_addr_lsb = (short ) kinfo->si_addr_lsb;break ; +case SIL_PERF_EVENT : + new.ssi_addr = (long ) kinfo->si_addr; + new.ssi_perf = kinfo->si_perf; +break ;case SIL_CHLD : new.ssi_pid = kinfo->si_pid; new.ssi_uid = kinfo->si_uid;include/linux/compat.h +2
-0@@ -236,6 +236,8 @@ typedef struct compat_siginfo {char _dummy_pkey[__COMPAT_ADDR_BND_PKEY_PAD];u32 _pkey; } _addr_pkey; +/* used when si_code=TRAP_PERF */ +compat_u64 _perf; }; } _sigfault;include/linux/signal.h +1
-0@@ -43,6 +43,7 @@ enum siginfo_layout {SIL_FAULT_MCEERR ,SIL_FAULT_BNDERR ,SIL_FAULT_PKUERR , +SIL_PERF_EVENT ,SIL_CHLD ,SIL_RT , SIL_SYS,include/uapi/asm-generic/siginfo.h +5
-1@@ -91,6 +91,8 @@ union __sifields {char _dummy_pkey[__ADDR_BND_PKEY_PAD];__u32 _pkey; } _addr_pkey; +/* used when si_code=TRAP_PERF */ +__u64 _perf; }; } _sigfault;@@ -155,6 +157,7 @@ typedef struct siginfo {#define si_lower _sifields._sigfault._addr_bnd._lower#define si_upper _sifields._sigfault._addr_bnd._upper#define si_pkey _sifields._sigfault._addr_pkey._pkey +#define si_perf _sifields._sigfault._perf#define si_band _sifields._sigpoll._band#define si_fd _sifields._sigpoll._fd#define si_call_addr _sifields._sigsys._call_addr@@ -253,7 +256,8 @@ typedef struct siginfo {#define TRAP_BRANCH 3/* process taken branch trap */ #define TRAP_HWBKPT 4/* hardware breakpoint/watchpoint */ #define TRAP_UNK 5/* undiagnosed trap */ -#define NSIGTRAP 5 +#define TRAP_PERF 6/* perf event with sigtrap=1 */ +#define NSIGTRAP 6/* * There is an additional set of SIGTRAP si_codes used by ptrace include/uapi/linux/signalfd.h +3
-1@@ -39,6 +39,8 @@ struct signalfd_siginfo {__s32 ssi_syscall;__u64 ssi_call_addr;__u32 ssi_arch; +__u32 __pad3; +__u64 ssi_perf;/* * Pad strcture to 128 bytes. Remember to update the @@ -49,7 +51,7 @@ struct signalfd_siginfo {* comes out of a read(2) and we really don't want to have * a compat on read(2). */ -__u8 __pad[28 ]; +__u8 __pad[16 ]; };kernel/signal.c +10
-0@@ -1199,6 +1199,7 @@ static inline bool has_si_pid_and_uid(struct kernel_siginfo *info)case SIL_FAULT_MCEERR :case SIL_FAULT_BNDERR :case SIL_FAULT_PKUERR : +case SIL_PERF_EVENT :case SIL_SYS : ret = false;break ;@@ -2531,6 +2532,7 @@ static void hide_si_addr_tag_bits(struct ksignal *ksig)case SIL_FAULT_MCEERR :case SIL_FAULT_BNDERR :case SIL_FAULT_PKUERR : +case SIL_PERF_EVENT : ksig->info.si_addr =arch_untagged_si_addr ( ksig->info.si_addr, ksig->sig, ksig->info.si_code);break ;@@ -3341,6 +3343,10 @@ void copy_siginfo_to_external32(struct compat_siginfo *to,#endif to->si_pkey = from->si_pkey;break ; +case SIL_PERF_EVENT : + to->si_addr =ptr_to_compat (from->si_addr); + to->si_perf = from->si_perf; +break ;case SIL_CHLD : to->si_pid = from->si_pid; to->si_uid = from->si_uid;@@ -3421,6 +3427,10 @@ static int post_copy_siginfo_from_user32(kernel_siginfo_t *to,#endif to->si_pkey = from->si_pkey;break ; +case SIL_PERF_EVENT : + to->si_addr =compat_ptr (from->si_addr); + to->si_perf = from->si_perf; +break ;case SIL_CHLD : to->si_pid = from->si_pid; to->si_uid = from->si_uid;kernel/signal.c static inline void siginfo_buildtime_checks(void) · line 4617
Quoted 7 lines
kernel/signal.c +1
-0@@ -4601,6 +4611,7 @@ static inline void siginfo_buildtime_checks(void)CHECK_OFFSET (si_lower);CHECK_OFFSET (si_upper);CHECK_OFFSET (si_pkey); +CHECK_OFFSET (si_perf);/* sigpoll */ CHECK_OFFSET (si_band);Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Hi,
Quoted 17 lines · Marco Elver
Quoted 8 lines · Marek Szyprowski
Quoted 7 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals (if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>Quoted 8 lines
This patch landed in linux-next as commit
fb6cc127e0b6("signal:
IntroduceTRAP_PERFsi_codeandsi_perfto siginfo"). It causes regression on my test systems (arm 32bit and 64bit). Most systems fails to boot in the given time frame. I've observed that there is a timeout waiting for udev to populate /dev and then also during the network interfaces configuration. Reverting this commit, together with97ba62b27867("perf: Add support for SIGTRAP on perf events") to let it compile, on top of next-20210420 fixes the issue.
Quoted 4 lines
Thanks, this is weird for sure and nothing in particular stands out.
I have questions:
-- Can you please share your config?
This happens with standard multi_v7_defconfig (arm) or just defconfig for arm64.
Quoted 1 line
-- Also, can you share how you run this? Can it be reproduced in qemu?
Nothing special. I just boot my test systems and see that they are waiting lots of time during the udev populating /dev and network interfaces configuration. I didn't try with qemu yet.
Quoted 2 lines
-- How did you derive this patch to be at fault? Why not just
97ba62b27867, given you also need to revert it?
Well, I've just run my boot tests with automated 'git bisect' and that was its result. It was a bit late in the evening, so I didn't analyze it further, I've just posted a report about the issue I've found. It looks that bisecting pointed to a wrong commit somehow.
Quoted 2 lines
If you are unsure which patch exactly it is, can you try just reverting
97ba62b27867and see what happens?
Indeed, this is a real faulty commit. Initially I've decided to revert it to let kernel compile (it uses some symbols introduced by this commit). Reverting only it on top of linux-next 20210420 also fixes the issue. I'm sorry for the noise in this thread. I hope we will find what really causes the issue.
Best regards
Signature · 2 lines
Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Quoted 38 lines · Marek Szyprowski
Quoted 19 lines · Marco Elver
Quoted 9 lines · Marek Szyprowski
Quoted 8 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>Quoted 8 lines
This patch landed in linux-next as commit
fb6cc127e0b6("signal:
IntroduceTRAP_PERFsi_codeandsi_perfto siginfo"). It causes regression on my test systems (arm 32bit and 64bit). Most systems fails to boot in the given time frame. I've observed that there is a timeout waiting for udev to populate /dev and then also during the network interfaces configuration. Reverting this commit, together with97ba62b27867("perf: Add support for SIGTRAP on perf events") to let it compile, on top of next-20210420 fixes the issue.Quoted 4 lines
Thanks, this is weird for sure and nothing in particular stands out.
I have questions:
-- Can you please share your config?This happens with standard
multi_v7_defconfig(arm) or just defconfig for arm64.Quoted 1 line
-- Also, can you share how you run this? Can it be reproduced in qemu?
Nothing special. I just boot my test systems and see that they are waiting lots of time during the udev populating /dev and network interfaces configuration. I didn't try with qemu yet.
Quoted 2 lines
-- How did you derive this patch to be at fault? Why not just
97ba62b27867, given you also need to revert it?Well, I've just run my boot tests with automated 'git bisect' and that was its result. It was a bit late in the evening, so I didn't analyze it further, I've just posted a report about the issue I've found. It looks that bisecting pointed to a wrong commit somehow.
Quoted 8 lines
Quoted 2 lines
If you are unsure which patch exactly it is, can you try just reverting
97ba62b27867and see what happens?Indeed, this is a real faulty commit. Initially I've decided to revert it to let kernel compile (it uses some symbols introduced by this commit). Reverting only it on top of linux-next 20210420 also fixes the issue. I'm sorry for the noise in this thread. I hope we will find what really causes the issue.
This was a premature conclusion. It looks that during the test I've did while writing that reply, the modules were not deployed properly and a test board (RPi4) booted without modules. In that case the board booted fine and there was no udev timeout. After deploying kernel modules, the udev timeout is back.
Best regards
Signature · 2 lines
Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Quoted 49 lines · Marek Szyprowski
Quoted 38 lines · Marek Szyprowski
Quoted 19 lines · Marco Elver
Quoted 9 lines · Marek Szyprowski
Quoted 8 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>Quoted 8 lines
This patch landed in linux-next as commit
fb6cc127e0b6("signal:
IntroduceTRAP_PERFsi_codeandsi_perfto siginfo"). It causes regression on my test systems (arm 32bit and 64bit). Most systems fails to boot in the given time frame. I've observed that there is a timeout waiting for udev to populate /dev and then also during the network interfaces configuration. Reverting this commit, together with97ba62b27867("perf: Add support for SIGTRAP on perf events") to let it compile, on top of next-20210420 fixes the issue.Quoted 4 lines
Thanks, this is weird for sure and nothing in particular stands out.
I have questions:
-- Can you please share your config?This happens with standard
multi_v7_defconfig(arm) or just defconfig for arm64.Quoted 1 line
-- Also, can you share how you run this? Can it be reproduced in qemu?
Nothing special. I just boot my test systems and see that they are waiting lots of time during the udev populating /dev and network interfaces configuration. I didn't try with qemu yet.
Quoted 2 lines
-- How did you derive this patch to be at fault? Why not just
97ba62b27867, given you also need to revert it?Well, I've just run my boot tests with automated 'git bisect' and that was its result. It was a bit late in the evening, so I didn't analyze it further, I've just posted a report about the issue I've found. It looks that bisecting pointed to a wrong commit somehow.
Quoted 8 lines
Quoted 2 lines
If you are unsure which patch exactly it is, can you try just reverting
97ba62b27867and see what happens?Indeed, this is a real faulty commit. Initially I've decided to revert it to let kernel compile (it uses some symbols introduced by this commit). Reverting only it on top of linux-next 20210420 also fixes the issue. I'm sorry for the noise in this thread. I hope we will find what really causes the issue.
Quoted 5 lines
This was a premature conclusion. It looks that during the test I've did while writing that reply, the modules were not deployed properly and a test board (RPi4) booted without modules. In that case the board booted fine and there was no udev timeout. After deploying kernel modules, the udev timeout is back.
I'm confused now. Can you confirm that the problem is due to your kernel modules, or do you think it's still due to 97ba62b27867? Or fb6cc127e0b6 (this patch)?
Thanks,
-- Marco
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Hi Marco,
Quoted 46 lines · Marco Elver
Quoted 45 lines · Marek Szyprowski
Quoted 44 lines · Marek Szyprowski
Quoted 19 lines · Marco Elver
Quoted 9 lines · Marek Szyprowski
Quoted 8 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>Quoted 8 lines
This patch landed in linux-next as commit
fb6cc127e0b6("signal:
IntroduceTRAP_PERFsi_codeandsi_perfto siginfo"). It causes regression on my test systems (arm 32bit and 64bit). Most systems fails to boot in the given time frame. I've observed that there is a timeout waiting for udev to populate /dev and then also during the network interfaces configuration. Reverting this commit, together with97ba62b27867("perf: Add support for SIGTRAP on perf events") to let it compile, on top of next-20210420 fixes the issue.Quoted 4 lines
Thanks, this is weird for sure and nothing in particular stands out.
I have questions:
-- Can you please share your config?This happens with standard
multi_v7_defconfig(arm) or just defconfig for arm64.Quoted 1 line
-- Also, can you share how you run this? Can it be reproduced in qemu?
Nothing special. I just boot my test systems and see that they are waiting lots of time during the udev populating /dev and network interfaces configuration. I didn't try with qemu yet.
Quoted 2 lines
-- How did you derive this patch to be at fault? Why not just
97ba62b27867, given you also need to revert it?Well, I've just run my boot tests with automated 'git bisect' and that was its result. It was a bit late in the evening, so I didn't analyze it further, I've just posted a report about the issue I've found. It looks that bisecting pointed to a wrong commit somehow.
Quoted 2 lines
If you are unsure which patch exactly it is, can you try just reverting
97ba62b27867and see what happens?Indeed, this is a real faulty commit. Initially I've decided to revert it to let kernel compile (it uses some symbols introduced by this commit). Reverting only it on top of linux-next 20210420 also fixes the issue. I'm sorry for the noise in this thread. I hope we will find what really causes the issue.
Quoted 8 lines
Quoted 5 lines
This was a premature conclusion. It looks that during the test I've did while writing that reply, the modules were not deployed properly and a test board (RPi4) booted without modules. In that case the board booted fine and there was no udev timeout. After deploying kernel modules, the udev timeout is back.
I'm confused now. Can you confirm that the problem is due to your kernel modules, or do you think it's still due to
97ba62b27867? Orfb6cc127e0b6(this patch)?
I don't use any custom kernel modules. I just deploy all modules that are being built from the given kernel defconfig (arm multi_v7_defconfig or arm64 default) and they are automatically loaded during the boot by udev. I've checked again and bisect was right. The kernel built from fb6cc127e0b6 suffers from the described issue, while the one build from the previous commit (2e498d0a74e5) works fine.
Best regards
Signature · 2 lines
Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Quoted 61 lines · Marek Szyprowski
Quoted 51 lines · Marco Elver
Quoted 49 lines · Marek Szyprowski
Quoted 48 lines · Marek Szyprowski
Quoted 22 lines · Marco Elver
Quoted 9 lines · Marek Szyprowski
Quoted 8 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>Quoted 11 lines
This patch landed in linux-next as commit
fb6cc127e0b6("signal:
IntroduceTRAP_PERFsi_codeandsi_perfto siginfo"). It causes regression on my test systems (arm 32bit and 64bit). Most systems fails
to boot in the given time frame. I've observed that there is a timeout
waiting for udev to populate /dev and then also during the network interfaces configuration. Reverting this commit, together with97ba62b27867("perf: Add support for SIGTRAP on perf events") to let it
compile, on top of next-20210420 fixes the issue.Quoted 4 lines
Thanks, this is weird for sure and nothing in particular stands out.
I have questions:
-- Can you please share your config?This happens with standard
multi_v7_defconfig(arm) or just defconfig for arm64.Quoted 2 lines
-- Also, can you share how you run this? Can it be reproduced in qemu?
Nothing special. I just boot my test systems and see that they are waiting lots of time during the udev populating /dev and network interfaces configuration. I didn't try with qemu yet.
Quoted 2 lines
-- How did you derive this patch to be at fault? Why not just
97ba62b27867, given you also need to revert it?Well, I've just run my boot tests with automated 'git bisect' and that was its result. It was a bit late in the evening, so I didn't analyze it further, I've just posted a report about the issue I've found. It looks that bisecting pointed to a wrong commit somehow.
Quoted 2 lines
If you are unsure which patch exactly it is, can you try just reverting
97ba62b27867and see what happens?Indeed, this is a real faulty commit. Initially I've decided to revert it to let kernel compile (it uses some symbols introduced by this commit). Reverting only it on top of linux-next 20210420 also fixes the issue. I'm sorry for the noise in this thread. I hope we will find what really causes the issue.
Quoted 8 lines
Quoted 5 lines
This was a premature conclusion. It looks that during the test I've did while writing that reply, the modules were not deployed properly and a test board (RPi4) booted without modules. In that case the board booted fine and there was no udev timeout. After deploying kernel modules, the udev timeout is back.
I'm confused now. Can you confirm that the problem is due to your kernel modules, or do you think it's still due to
97ba62b27867? Orfb6cc127e0b6(this patch)?
Quoted 6 lines
I don't use any custom kernel modules. I just deploy all modules that are being built from the given kernel defconfig (arm
multi_v7_defconfigor arm64 default) and they are automatically loaded during the boot by udev. I've checked again and bisect was right. The kernel built fromfb6cc127e0b6suffers from the described issue, while the one build from the previous commit (2e498d0a74e5) works fine.
I've managed to reproduce this issue with qemu. I've compiled the kernel for arm 32bit with multi_v7_defconfig and used some older Debian rootfs image. The log and qemu parameters are here:
https://paste.debian.net/1194526/
Check the timestamp for the 'EXT4-fs (vda): re-mounted' message and 'done (timeout)' status for the 'Waiting for /dev to be fully populated' message. This happens only when kernel modules build from the multi_v7_defconfig are deployed on the rootfs.
Best regards
Signature · 2 lines
Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Quoted 75 lines · Marek Szyprowski
Quoted 61 lines · Marek Szyprowski
Quoted 51 lines · Marco Elver
Quoted 49 lines · Marek Szyprowski
Quoted 48 lines · Marek Szyprowski
Quoted 22 lines · Marco Elver
Quoted 9 lines · Marek Szyprowski
Quoted 8 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>Quoted 11 lines
This patch landed in linux-next as commit
fb6cc127e0b6("signal:
IntroduceTRAP_PERFsi_codeandsi_perfto siginfo"). It causes regression on my test systems (arm 32bit and 64bit). Most systems fails
to boot in the given time frame. I've observed that there is a timeout
waiting for udev to populate /dev and then also during the network interfaces configuration. Reverting this commit, together with97ba62b27867("perf: Add support for SIGTRAP on perf events") to let it
compile, on top of next-20210420 fixes the issue.Quoted 4 lines
Thanks, this is weird for sure and nothing in particular stands out.
I have questions:
-- Can you please share your config?This happens with standard
multi_v7_defconfig(arm) or just defconfig for arm64.Quoted 2 lines
-- Also, can you share how you run this? Can it be reproduced in qemu?
Nothing special. I just boot my test systems and see that they are waiting lots of time during the udev populating /dev and network interfaces configuration. I didn't try with qemu yet.
Quoted 2 lines
-- How did you derive this patch to be at fault? Why not just
97ba62b27867, given you also need to revert it?Well, I've just run my boot tests with automated 'git bisect' and that was its result. It was a bit late in the evening, so I didn't analyze it further, I've just posted a report about the issue I've found. It looks that bisecting pointed to a wrong commit somehow.
Quoted 2 lines
If you are unsure which patch exactly it is, can you try just reverting
97ba62b27867and see what happens?Indeed, this is a real faulty commit. Initially I've decided to revert it to let kernel compile (it uses some symbols introduced by this commit). Reverting only it on top of linux-next 20210420 also fixes the issue. I'm sorry for the noise in this thread. I hope we will find what really causes the issue.
Quoted 8 lines
Quoted 5 lines
This was a premature conclusion. It looks that during the test I've did while writing that reply, the modules were not deployed properly and a test board (RPi4) booted without modules. In that case the board booted fine and there was no udev timeout. After deploying kernel modules, the udev timeout is back.
I'm confused now. Can you confirm that the problem is due to your kernel modules, or do you think it's still due to
97ba62b27867? Orfb6cc127e0b6(this patch)?Quoted 6 lines
I don't use any custom kernel modules. I just deploy all modules that are being built from the given kernel defconfig (arm
multi_v7_defconfigor arm64 default) and they are automatically loaded during the boot by udev. I've checked again and bisect was right. The kernel built fromfb6cc127e0b6suffers from the described issue, while the one build from the previous commit (2e498d0a74e5) works fine.I've managed to reproduce this issue with qemu. I've compiled the kernel for arm 32bit with
multi_v7_defconfigand used some older Debian rootfs image. The log and qemu parameters are here:
https://paste.debian.net/1194526/
Quoted 4 lines
Check the timestamp for the 'EXT4-fs (vda): re-mounted' message and 'done (timeout)' status for the 'Waiting for /dev to be fully populated' message. This happens only when kernel modules build from the
multi_v7_defconfigare deployed on the rootfs.
Still hard to say what is going on and what is at fault. But being able to repro this in qemu helps debug quicker -- would you also be able to share the precise rootfs.img, i.e. upload it somewhere I can fetch it? And just to be sure, please also share your .config, as it might have compiler-version dependent configuration that might help repro (unlikely, but you never know).
Thanks,
-- Marco
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Hi Marco,
Quoted 77 lines · Marco Elver
Quoted 72 lines · Marek Szyprowski
Quoted 60 lines · Marek Szyprowski
Quoted 51 lines · Marco Elver
Quoted 49 lines · Marek Szyprowski
Quoted 48 lines · Marek Szyprowski
Quoted 22 lines · Marco Elver
Quoted 9 lines · Marek Szyprowski
Quoted 8 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>Quoted 11 lines
This patch landed in linux-next as commit
fb6cc127e0b6("signal:
IntroduceTRAP_PERFsi_codeandsi_perfto siginfo"). It causes regression on my test systems (arm 32bit and 64bit). Most systems fails
to boot in the given time frame. I've observed that there is a timeout
waiting for udev to populate /dev and then also during the network interfaces configuration. Reverting this commit, together with97ba62b27867("perf: Add support for SIGTRAP on perf events") to let it
compile, on top of next-20210420 fixes the issue.Quoted 4 lines
Thanks, this is weird for sure and nothing in particular stands out.
I have questions:
-- Can you please share your config?This happens with standard
multi_v7_defconfig(arm) or just defconfig for arm64.Quoted 2 lines
-- Also, can you share how you run this? Can it be reproduced in qemu?
Nothing special. I just boot my test systems and see that they are waiting lots of time during the udev populating /dev and network interfaces configuration. I didn't try with qemu yet.
Quoted 2 lines
-- How did you derive this patch to be at fault? Why not just
97ba62b27867, given you also need to revert it?Well, I've just run my boot tests with automated 'git bisect' and that was its result. It was a bit late in the evening, so I didn't analyze it further, I've just posted a report about the issue I've found. It looks that bisecting pointed to a wrong commit somehow.
Quoted 2 lines
If you are unsure which patch exactly it is, can you try just reverting
97ba62b27867and see what happens?Indeed, this is a real faulty commit. Initially I've decided to revert it to let kernel compile (it uses some symbols introduced by this commit). Reverting only it on top of linux-next 20210420 also fixes the issue. I'm sorry for the noise in this thread. I hope we will find what really causes the issue.
Quoted 8 lines
Quoted 5 lines
This was a premature conclusion. It looks that during the test I've did while writing that reply, the modules were not deployed properly and a test board (RPi4) booted without modules. In that case the board booted fine and there was no udev timeout. After deploying kernel modules, the udev timeout is back.
I'm confused now. Can you confirm that the problem is due to your kernel modules, or do you think it's still due to
97ba62b27867? Orfb6cc127e0b6(this patch)?Quoted 6 lines
I don't use any custom kernel modules. I just deploy all modules that are being built from the given kernel defconfig (arm
multi_v7_defconfigor arm64 default) and they are automatically loaded during the boot by udev. I've checked again and bisect was right. The kernel built fromfb6cc127e0b6suffers from the described issue, while the one build from the previous commit (2e498d0a74e5) works fine.I've managed to reproduce this issue with qemu. I've compiled the kernel for arm 32bit with
multi_v7_defconfigand used some older Debian rootfs image. The log and qemu parameters are here:
https://protect2.fireeye.com/v1/url?k=7cfc23a2-23671aa9-7cfda8ed-002590f5b904-dab7e2ec39dae1f9&q=1&e=36a5ed13-6ad5-430c-8f44-e95c4f0af5c3&u=https%3A%2F%2Fpaste.debian.net%2F1194526%2FQuoted 4 lines
Check the timestamp for the 'EXT4-fs (vda): re-mounted' message and 'done (timeout)' status for the 'Waiting for /dev to be fully populated' message. This happens only when kernel modules build from the
multi_v7_defconfigare deployed on the rootfs.
Quoted 6 lines
Still hard to say what is going on and what is at fault. But being able to repro this in qemu helps debug quicker -- would you also be able to share the precise rootfs.img, i.e. upload it somewhere I can fetch it? And just to be sure, please also share your .config, as it might have compiler-version dependent configuration that might help repro (unlikely, but you never know).
I've managed to reproduce this issue with a public Raspberry Pi OS Lite rootfs image, even without deploying kernel modules:
# qemu-system-arm -M virt -smp 2 -m 512 -kernel zImage -append "earlycon console=ttyAMA0 root=/dev/vda2 rw rootwait" -serial stdio -display none -monitor null -device virtio-blk-device,drive=virtio-blk -drive file=/tmp/2021-03-04-raspios-buster-armhf-lite.img,id=virtio-blk,if=none,format=raw -netdev user,id=user -device virtio-net-device,netdev=user
The above one doesn't boot if zImage z compiled from commit fb6cc127e0b6 and boots if compiled from 2e498d0a74e5. In both cases I've used default arm/multi_v7_defconfig and gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabi toolchain.
Best regards
Signature · 2 lines
Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
+Cc linux-arm-kernel
Quoted 99 lines · Marek Szyprowski
Hi Marco,
Quoted 77 lines · Marco Elver
Quoted 72 lines · Marek Szyprowski
Quoted 60 lines · Marek Szyprowski
Quoted 51 lines · Marco Elver
Quoted 49 lines · Marek Szyprowski
Quoted 48 lines · Marek Szyprowski
Quoted 22 lines · Marco Elver
Quoted 9 lines · Marek Szyprowski
Quoted 8 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>Quoted 11 lines
This patch landed in linux-next as commit
fb6cc127e0b6("signal:
IntroduceTRAP_PERFsi_codeandsi_perfto siginfo"). It causes regression on my test systems (arm 32bit and 64bit). Most systems fails
to boot in the given time frame. I've observed that there is a timeout
waiting for udev to populate /dev and then also during the network interfaces configuration. Reverting this commit, together with97ba62b27867("perf: Add support for SIGTRAP on perf events") to let it
compile, on top of next-20210420 fixes the issue.Quoted 4 lines
Thanks, this is weird for sure and nothing in particular stands out.
I have questions:
-- Can you please share your config?This happens with standard
multi_v7_defconfig(arm) or just defconfig for arm64.Quoted 2 lines
-- Also, can you share how you run this? Can it be reproduced in qemu?
Nothing special. I just boot my test systems and see that they are waiting lots of time during the udev populating /dev and network interfaces configuration. I didn't try with qemu yet.
Quoted 2 lines
-- How did you derive this patch to be at fault? Why not just
97ba62b27867, given you also need to revert it?Well, I've just run my boot tests with automated 'git bisect' and that was its result. It was a bit late in the evening, so I didn't analyze it further, I've just posted a report about the issue I've found. It looks that bisecting pointed to a wrong commit somehow.
Quoted 2 lines
If you are unsure which patch exactly it is, can you try just reverting
97ba62b27867and see what happens?Indeed, this is a real faulty commit. Initially I've decided to revert it to let kernel compile (it uses some symbols introduced by this commit). Reverting only it on top of linux-next 20210420 also fixes the issue. I'm sorry for the noise in this thread. I hope we will find what really causes the issue.
Quoted 8 lines
Quoted 5 lines
This was a premature conclusion. It looks that during the test I've did while writing that reply, the modules were not deployed properly and a test board (RPi4) booted without modules. In that case the board booted fine and there was no udev timeout. After deploying kernel modules, the udev timeout is back.
I'm confused now. Can you confirm that the problem is due to your kernel modules, or do you think it's still due to
97ba62b27867? Orfb6cc127e0b6(this patch)?Quoted 6 lines
I don't use any custom kernel modules. I just deploy all modules that are being built from the given kernel defconfig (arm
multi_v7_defconfigor arm64 default) and they are automatically loaded during the boot by udev. I've checked again and bisect was right. The kernel built fromfb6cc127e0b6suffers from the described issue, while the one build from the previous commit (2e498d0a74e5) works fine.I've managed to reproduce this issue with qemu. I've compiled the kernel for arm 32bit with
multi_v7_defconfigand used some older Debian rootfs image. The log and qemu parameters are here:
https://protect2.fireeye.com/v1/url?k=7cfc23a2-23671aa9-7cfda8ed-002590f5b904-dab7e2ec39dae1f9&q=1&e=36a5ed13-6ad5-430c-8f44-e95c4f0af5c3&u=https%3A%2F%2Fpaste.debian.net%2F1194526%2FQuoted 4 lines
Check the timestamp for the 'EXT4-fs (vda): re-mounted' message and 'done (timeout)' status for the 'Waiting for /dev to be fully populated' message. This happens only when kernel modules build from the
multi_v7_defconfigare deployed on the rootfs.Quoted 6 lines
Still hard to say what is going on and what is at fault. But being able to repro this in qemu helps debug quicker -- would you also be able to share the precise rootfs.img, i.e. upload it somewhere I can fetch it? And just to be sure, please also share your .config, as it might have compiler-version dependent configuration that might help repro (unlikely, but you never know).
I've managed to reproduce this issue with a public Raspberry Pi OS Lite rootfs image, even without deploying kernel modules:
# qemu-system-arm -M virt -smp 2 -m 512 -kernel zImage -append "earlycon console=ttyAMA0 root=/dev/vda2 rw rootwait" -serial stdio -display none -monitor null -device virtio-blk-device,drive=virtio-blk -drive file=/tmp/2021-03-04-raspios-buster-armhf-lite.img,id=virtio-blk,if=none,format=raw -netdev user,id=user -device virtio-net-device,netdev=user
Quoted 4 lines
The above one doesn't boot if zImage z compiled from commit
fb6cc127e0b6and boots if compiled from2e498d0a74e5. In both cases I've used default arm/multi_v7_defconfig and gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabi toolchain.
Yup, I've narrowed it down to the addition of "__u64 _perf" to siginfo_t. My guess is the __u64 causes a different alignment for a bunch of adjacent fields. It seems that x86 and m68k are the only ones that have compile-time tests for the offsets. Arm should probably add those -- I have added a bucket of static_assert() in arch/arm/kernel/signal.c and see that something's off.
I'll hopefully have a fix in a day or so.
Thanks,
-- Marco
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Quoted 2 lines · Marco Elver
+Cc linux-arm-kernel
[...]
Quoted 24 lines
Quoted 12 lines
I've managed to reproduce this issue with a public Raspberry Pi OS Lite rootfs image, even without deploying kernel modules:
# qemu-system-arm -M virt -smp 2 -m 512 -kernel zImage -append "earlycon console=ttyAMA0 root=/dev/vda2 rw rootwait" -serial stdio -display none -monitor null -device virtio-blk-device,drive=virtio-blk -drive file=/tmp/2021-03-04-raspios-buster-armhf-lite.img,id=virtio-blk,if=none,format=raw -netdev user,id=user -device virtio-net-device,netdev=userQuoted 4 lines
The above one doesn't boot if zImage z compiled from commit
fb6cc127e0b6and boots if compiled from2e498d0a74e5. In both cases I've used default arm/multi_v7_defconfig and gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabi toolchain.Yup, I've narrowed it down to the addition of "
__u64_perf" tosiginfo_t. My guess is the__u64causes a different alignment for a bunch of adjacent fields. It seems that x86 and m68k are the only ones that have compile-time tests for the offsets. Arm should probably add those -- I have added a bucket ofstatic_assert()inarch/arm/kernel/signal.cand see that something's off.
Quoted 1 line
I'll hopefully have a fix in a day or so.
Arm and compiler folks: are there some special alignment requirement for __u64 on arm 32-bit? (And if there is for arm64, please shout as well.)
With the static-asserts below, the only thing that I can do to fix it is to completely remove the __u64. Padding it before or after with __u32 just does not work. It seems that the use of __u64 shifts everything in __sifields by 4 bytes.
include/uapi/asm-generic/siginfo.h +4 -1
@@ -92,7 +92,10 @@ union __sifields {__u32 _pkey; } _addr_pkey;/* used when si_code=TRAP_PERF */ -__u64 _perf; +struct { +__u32 _perf1; +__u32 _perf2; + } _perf; }; } _sigfault;
^^ works, but I'd hate to have to split this into 2 __u32 because it makes the whole design worse.
What alignment trick do we have to do here to fix it for __u64?
------ >8 ------
arch/arm/kernel/signal.c +38 -0
@@ -725,3 +725,41 @@ asmlinkage void do_rseq_syscall(struct pt_regs *regs)rseq_syscall (regs); }#endif + +/* +* Compile-time tests for siginfo_t offsets. Changes to NSIG* likely come with +* new fields; new fields should be added below. +*/ +static_assert (NSIGILL ==11 ); +static_assert (NSIGFPE ==15 ); +static_assert (NSIGSEGV ==9 ); +static_assert (NSIGBUS ==5 ); +static_assert (NSIGTRAP ==6 ); +static_assert (NSIGCHLD ==6 ); +static_assert (NSIGSYS ==2 ); +static_assert (offsetof(siginfo_t , si_signo) ==0x00 ); +static_assert (offsetof(siginfo_t , si_errno) ==0x04 ); +static_assert (offsetof(siginfo_t , si_code) ==0x08 ); +static_assert (offsetof(siginfo_t , si_pid) ==0x0c ); +#if 0 +static_assert (offsetof(siginfo_t , si_uid) ==0x10 ); +static_assert (offsetof(siginfo_t , si_tid) ==0x0c ); +static_assert (offsetof(siginfo_t , si_overrun) ==0x10 ); +static_assert (offsetof(siginfo_t , si_status) ==0x14 ); +static_assert (offsetof(siginfo_t , si_utime) ==0x18 ); +static_assert (offsetof(siginfo_t , si_stime) ==0x1c ); +static_assert (offsetof(siginfo_t , si_value) ==0x14 ); +static_assert (offsetof(siginfo_t , si_int) ==0x14 ); +static_assert (offsetof(siginfo_t , si_ptr) ==0x14 ); +static_assert (offsetof(siginfo_t , si_addr) ==0x0c ); +static_assert (offsetof(siginfo_t , si_addr_lsb) ==0x10 ); +static_assert (offsetof(siginfo_t , si_lower) ==0x14 ); +static_assert (offsetof(siginfo_t , si_upper) ==0x18 ); +static_assert (offsetof(siginfo_t , si_pkey) ==0x14 ); +static_assert (offsetof(siginfo_t , si_perf) ==0x10 ); +static_assert (offsetof(siginfo_t , si_band) ==0x0c ); +static_assert (offsetof(siginfo_t , si_fd) ==0x10 ); +static_assert (offsetof(siginfo_t , si_call_addr) ==0x0c ); +static_assert (offsetof(siginfo_t , si_syscall) ==0x10 ); +static_assert (offsetof(siginfo_t , si_arch) ==0x14 ); +#endif
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Quoted 57 lines · Marco Elver
Quoted 2 lines · Marco Elver
+Cc linux-arm-kernel
[...]
Quoted 24 lines
Quoted 12 lines
I've managed to reproduce this issue with a public Raspberry Pi OS Lite rootfs image, even without deploying kernel modules:
# qemu-system-arm -M virt -smp 2 -m 512 -kernel zImage -append "earlycon console=ttyAMA0 root=/dev/vda2 rw rootwait" -serial stdio -display none -monitor null -device virtio-blk-device,drive=virtio-blk -drive file=/tmp/2021-03-04-raspios-buster-armhf-lite.img,id=virtio-blk,if=none,format=raw -netdev user,id=user -device virtio-net-device,netdev=userQuoted 4 lines
The above one doesn't boot if zImage z compiled from commit
fb6cc127e0b6and boots if compiled from2e498d0a74e5. In both cases I've used default arm/multi_v7_defconfig and gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabi toolchain.Yup, I've narrowed it down to the addition of "
__u64_perf" tosiginfo_t. My guess is the__u64causes a different alignment for a bunch of adjacent fields. It seems that x86 and m68k are the only ones that have compile-time tests for the offsets. Arm should probably add those -- I have added a bucket ofstatic_assert()inarch/arm/kernel/signal.cand see that something's off.Quoted 1 line
I'll hopefully have a fix in a day or so.
Arm and compiler folks: are there some special alignment requirement for
__u64on arm 32-bit? (And if there is for arm64, please shout as well.)With the static-asserts below, the only thing that I can do to fix it is to completely remove the
__u64. Padding it before or after with__u32just does not work. It seems that the use of__u64shifts everything in__sifieldsby 4 bytes.include/uapi/asm-generic/siginfo.h +4
-1@@ -92,7 +92,10 @@ union __sifields {__u32 _pkey; } _addr_pkey;/* used when si_code=TRAP_PERF */ -__u64 _perf; +struct { +__u32 _perf1; +__u32 _perf2; + } _perf; }; } _sigfault;^^ works, but I'd hate to have to split this into 2
__u32because it makes the whole design worse.
Quoted 1 line
What alignment trick do we have to do here to fix it for
__u64?
So I think we just have to settle on 'unsigned long' here. On many architectures, like 32-bit Arm, the alignment of a structure is that of its largest member. This means that there is no portable way to add 64-bit integers to siginfo_t on 32-bit architectures.
In the case of the si_perf field, word size is sufficient since the data it contains is user-defined. On 32-bit architectures, any excess bits of perf_event_attr::sig_data will therefore be truncated when copying into si_perf.
Feel free to test the below if you have time, but the below lets me boot 32-bit arm which previously timed out. It also passes all the static_asserts() I added (will send those as separate patches).
Once I'm convinced this passes all others tests too, I'll send a patch.
Thanks,
-- Marco
include/linux/compat.h +1 -1
@@ -237,7 +237,7 @@ typedef struct compat_siginfo {u32 _pkey; } _addr_pkey;/* used when si_code=TRAP_PERF */ -compat_u64 _perf; +compat_ulong_t _perf; }; } _sigfault;
include/uapi/asm-generic/siginfo.h +1 -1
@@ -92,7 +92,7 @@ union __sifields {__u32 _pkey; } _addr_pkey;/* used when si_code=TRAP_PERF */ -__u64 _perf; +unsigned long _perf; }; } _sigfault;
Marek Szyprowski
Tested-byRe: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Hi Marco,
Quoted 66 lines · Marco Elver
Quoted 54 lines · Marco Elver
Quoted 2 lines · Marco Elver
+Cc linux-arm-kernel
[...]
Quoted 22 lines
Quoted 11 lines
I've managed to reproduce this issue with a public Raspberry Pi OS Lite rootfs image, even without deploying kernel modules:
# qemu-system-arm -M virt -smp 2 -m 512 -kernel zImage -append "earlycon console=ttyAMA0 root=/dev/vda2 rw rootwait" -serial stdio -display none -monitor null -device virtio-blk-device,drive=virtio-blk -drive file=/tmp/2021-03-04-raspios-buster-armhf-lite.img,id=virtio-blk,if=none,format=raw -netdev user,id=user -device virtio-net-device,netdev=userQuoted 4 lines
The above one doesn't boot if zImage z compiled from commit
fb6cc127e0b6and boots if compiled from2e498d0a74e5. In both cases I've used default arm/multi_v7_defconfig and gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabi toolchain.Yup, I've narrowed it down to the addition of "
__u64_perf" tosiginfo_t. My guess is the__u64causes a different alignment for a bunch of adjacent fields. It seems that x86 and m68k are the only ones that have compile-time tests for the offsets. Arm should probably add those -- I have added a bucket ofstatic_assert()inarch/arm/kernel/signal.cand see that something's off.Quoted 1 line
I'll hopefully have a fix in a day or so.
Arm and compiler folks: are there some special alignment requirement for
__u64on arm 32-bit? (And if there is for arm64, please shout as well.)With the static-asserts below, the only thing that I can do to fix it is to completely remove the
__u64. Padding it before or after with__u32just does not work. It seems that the use of__u64shifts everything in__sifieldsby 4 bytes.include/uapi/asm-generic/siginfo.h +4
-1@@ -92,7 +92,10 @@ union __sifields {__u32 _pkey; } _addr_pkey;/* used when si_code=TRAP_PERF */ -__u64 _perf; +struct { +__u32 _perf1; +__u32 _perf2; + } _perf; }; } _sigfault;^^ works, but I'd hate to have to split this into 2
__u32because it makes the whole design worse.Quoted 1 line
What alignment trick do we have to do here to fix it for
__u64?So I think we just have to settle on 'unsigned long' here. On many architectures, like 32-bit Arm, the alignment of a structure is that of its largest member. This means that there is no portable way to add 64-bit integers to
siginfo_ton 32-bit architectures.In the case of the
si_perffield, word size is sufficient since the data it contains is user-defined. On 32-bit architectures, any excess bits ofperf_event_attr::sig_datawill therefore be truncated when copying intosi_perf.
Quoted 5 lines
Feel free to test the below if you have time, but the below lets me boot 32-bit arm which previously timed out. It also passes all the
static_asserts()I added (will send those as separate patches).Once I'm convinced this passes all others tests too, I'll send a patch.
This fixes the issue I've observed on my test systems. Feel free to add:
Quoted 23 lines
Thanks,
-- Marcoinclude/linux/compat.h +1
-1@@ -237,7 +237,7 @@ typedef struct compat_siginfo {u32 _pkey; } _addr_pkey;/* used when si_code=TRAP_PERF */ -compat_u64 _perf; +compat_ulong_t _perf; }; } _sigfault;include/uapi/asm-generic/siginfo.h +0
-0
include/uapi/asm-generic/siginfo.h union __sifields { · line 98
Quoted 8 lines
include/uapi/asm-generic/siginfo.h +1
-1@@ -92,7 +92,7 @@ union __sifields {__u32 _pkey; } _addr_pkey;/* used when si_code=TRAP_PERF */ -__u64 _perf; +unsigned long _perf; }; } _sigfault;
Best regards
Signature · 2 lines
Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
On Thu, 22 Apr 2021 at 08:12, Marek Szyprowski <[email protected]> wrote:
[...]
Quoted 14 lines
Quoted 14 lines
So I think we just have to settle on 'unsigned long' here. On many architectures, like 32-bit Arm, the alignment of a structure is that of its largest member. This means that there is no portable way to add 64-bit integers to
siginfo_ton 32-bit architectures.In the case of the
si_perffield, word size is sufficient since the data it contains is user-defined. On 32-bit architectures, any excess bits ofperf_event_attr::sig_datawill therefore be truncated when copying intosi_perf.Feel free to test the below if you have time, but the below lets me boot 32-bit arm which previously timed out. It also passes all the
static_asserts()I added (will send those as separate patches).
Quoted 7 lines
Quoted 1 line
Once I'm convinced this passes all others tests too, I'll send a patch.
This fixes the issue I've observed on my test systems. Feel free to add:
Reported-by Marek Szyprowski <[email protected]>Tested-by Marek Szyprowski <[email protected]>
Thank you for testing! It's been sent:
https://lkml.kernel.org/r/[email protected]
Thanks,
-- Marco
Jon Hunter
maintainerRe: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Quoted 18 lines · Marco Elver
On Thu, 22 Apr 2021 at 08:12, Marek Szyprowski <[email protected]> wrote:
[...]Quoted 16 lines
Quoted 15 lines
So I think we just have to settle on 'unsigned long' here. On many architectures, like 32-bit Arm, the alignment of a structure is that of its largest member. This means that there is no portable way to add 64-bit integers to
siginfo_ton 32-bit architectures.In the case of the
si_perffield, word size is sufficient since the data it contains is user-defined. On 32-bit architectures, any excess bits ofperf_event_attr::sig_datawill therefore be truncated when copying intosi_perf.Feel free to test the below if you have time, but the below lets me boot 32-bit arm which previously timed out. It also passes all the
static_asserts()I added (will send those as separate patches).Once I'm convinced this passes all others tests too, I'll send a patch.
Quoted 8 lines
Quoted 5 lines
This fixes the issue I've observed on my test systems. Feel free to add:
Reported-by Marek Szyprowski <[email protected]>Tested-by Marek Szyprowski <[email protected]>Thank you for testing! It's been sent:
https://lkml.kernel.org/r/[email protected]
Thanks! This fixes the problem for Tegra as well. I have responded to the above patch with my tested-by.
Cheers
Jon
Signature · 1 line
nvpublic
Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
In reply to Marco ElverHi,
this also fixes s390.
strace's tests-m32 on s390 were failing.
Regards
Alex
Jon Hunter
maintainerRe: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo
In reply to Marco ElverHello!
Quoted 7 lines · Marco Elver
Introduces the
TRAP_PERFsi_code, and associatedsiginfo_tfieldsi_perf. These will be used by the perf event subsystem to send signals (if requested) to the task where an event occurred.Signed-off-by Marco Elver <[email protected]>
Since next-20210420 I have noticed a boot regression on all 32-bit Tegra that we are testing. Bisect is pointing to this commit and reverting this patch and patch 6/10 does resolve the issue.
Interestingly there is no apparent crash, but these systems just appear to hang silently after mounting the rootfs. If anyone has any thoughts let me know!
Thanks
Jon
Signature · 1 line
nvpublic
PATCH v4 6/10 perf: Add support for SIGTRAP on perf events
In reply to Marco ElverAdds bit perf_event_attr::sigtrap, which can be set to cause events to send SIGTRAP (with si_code TRAP_PERF) to the task where the event occurred. The primary motivation is to support synchronous signals on perf events in the task where an event (such as breakpoints) triggered.
To distinguish perf events based on the event type, the type is set in si_errno. For events that are associated with an address, si_addr is copied from perf_sample_data.
The new field perf_event_attr::sig_data is copied to si_perf, which allows user space to disambiguate which event (of the same type) triggered the signal. For example, user space could encode the relevant information it cares about in sig_data.
We note that the choice of an opaque u64 provides the simplest and most flexible option. Alternatives where a reference to some user space data is passed back suffer from the problem that modification of referenced data (be it the event fd, or the perf_event_attr) can race with the signal being delivered (of course, the same caveat applies if user space decides to store a pointer in sig_data, but the ABI explicitly avoids prescribing such a design).
---
v4:
* Generalize setting si_perf and si_addr independent of event type; introduces perf_event_attr::sig_data, which can be set by user space to be propagated to si_perf.
* Fix race between irq_work running and task's sighand being released by release_task().
* Warning in perf_sigtrap() if ctx->task and current mismatch; we expect this on architectures that do not properly implement arch_irq_work_raise().
* Require events that want sigtrap to be associated with a task.
v2:
* Use atomic_set(&event_count, 1), since it must always be 0 in perf_pending_event_disable().
* Implicitly restrict inheriting events if sigtrap, but the child was cloned with CLONE_CLEAR_SIGHAND, because it is not generally safe if the child cleared all signal handlers to continue sending SIGTRAP.
--- include/linux/perf_event.h | 3 ++ include/uapi/linux/perf_event.h | 10 ++++++- kernel/events/core.c | 49 ++++++++++++++++++++++++++++++++- 3 files changed, 60 insertions(+), 2 deletions(-)
include/linux/perf_event.h +3 -0
@@ -778,6 +778,9 @@ struct perf_event {void *security;#endif struct list_head sb_list; + +/* Address associated with event, which can be passed to siginfo_t. */ +u64 sig_addr;#endif /* CONFIG_PERF_EVENTS */ };
include/uapi/linux/perf_event.h +9 -1
@@ -311,6 +311,7 @@ enum perf_event_read_format {#define PERF_ATTR_SIZE_VER4 104/* add: sample_regs_intr */ #define PERF_ATTR_SIZE_VER5 112/* add: aux_watermark */ #define PERF_ATTR_SIZE_VER6 120/* add: aux_sample_size */ +#define PERF_ATTR_SIZE_VER7 128/* add: sig_data */ /* * Hardware event_id to monitor via a performance monitoring event:
@@ -391,7 +392,8 @@ struct perf_event_attr { build_id : 1, /* use build id in mmap2 events */ inherit_thread : 1, /* children only inherit if cloned with CLONE_THREAD */ remove_on_exec : 1, /* event is removed from task on exec */ - __reserved_1 : 27; + sigtrap : 1, /* send synchronous SIGTRAP on event */ + __reserved_1 : 26;union {__u32 wakeup_events;/* wakeup every n events */
@@ -443,6 +445,12 @@ struct perf_event_attr {__u16 __reserved_2;__u32 aux_sample_size;__u32 __reserved_3; + +/* +* User provided data if sigtrap=1, passed back to user via +* siginfo_t::si_perf, e.g. to permit user to identify the event. +*/ +__u64 sig_data; };/*
kernel/events/core.c +48 -1
91 lines not on this page · raw message
Signature · 1 line
2.31.0.208.g409f899ff0-goog
PATCH v4 7/10 selftests/perf_events: Add kselftest for process-wide sigtrap handling
In reply to Marco ElverAdd a kselftest for testing process-wide perf events with synchronous SIGTRAP on events (using breakpoints). In particular, we want to test that changes to the event propagate to all children, and the SIGTRAPs are in fact synchronously sent to the thread where the event occurred.
Note: The "signal_stress" test case is also added later in the series to perf tool's built-in tests. The test here is more elaborate in that respect, which on one hand avoids bloating the perf tool unnecessarily, but we also benefit from structured tests with TAP-compliant output that the kselftest framework provides.
---
v4:
* Update for new perf_event_attr::sig_data / si_perf handling.
v3:
* Fix for latest libc signal.h.
v2:
* Patch added to series.
--- .../testing/selftests/perf_events/.gitignore | 2 + tools/testing/selftests/perf_events/Makefile | 6 + tools/testing/selftests/perf_events/config | 1 + tools/testing/selftests/perf_events/settings | 1 + .../selftests/perf_events/sigtrap_threads.c | 210 ++++++++++++++++++ 5 files changed, 220 insertions(+) create mode 100644 tools/testing/selftests/perf_events/.gitignore create mode 100644 tools/testing/selftests/perf_events/Makefile create mode 100644 tools/testing/selftests/perf_events/config create mode 100644 tools/testing/selftests/perf_events/settings create mode 100644 tools/testing/selftests/perf_events/sigtrap_threads.c
tools/testing/selftests/perf_events/.gitignore new file +2 -0
@@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +sigtrap_threads
tools/testing/selftests/perf_events/Makefile new file +6 -0
@@ -0,0 +1,6 @@ +# SPDX-License-Identifier: GPL-2.0 +CFLAGS += -Wl,-no-as-needed -Wall -I../../../../usr/include +LDFLAGS += -lpthread + +TEST_GEN_PROGS := sigtrap_threads +include ../lib.mk
tools/testing/selftests/perf_events/config new file +1 -0
@@ -0,0 +1 @@ +CONFIG_PERF_EVENTS=y
tools/testing/selftests/perf_events/settings new file +1 -0
@@ -0,0 +1 @@ +timeout=120
tools/testing/selftests/perf_events/sigtrap_threads.c new file +210 -0
210 lines not on this page · raw message
Signature · 1 line
2.31.0.208.g409f899ff0-goog
[tip: perf/core] selftests/perf_events: Add kselftest for process-wide sigtrap handling
The following commit has been merged into the perf/core branch of tip:
The following commit has been merged into the perf/core branch of tip:
Commit-ID: f2c3c32f45002de19c6dec33f32fd259e82f2557 Gitweb: https://git.kernel.org/tip/f2c3c32f45002de19c6dec33f32fd259e82f2557 Author: Marco Elver <[email protected]> AuthorDate: Thu, 08 Apr 2021 12:36:02 +02:00 Committer: Peter Zijlstra <[email protected]> CommitterDate: Fri, 16 Apr 2021 16:32:42 +02:00
selftests/perf_events: Add kselftest for process-wide sigtrap handling
Add a kselftest for testing process-wide perf events with synchronous SIGTRAP on events (using breakpoints). In particular, we want to test that changes to the event propagate to all children, and the SIGTRAPs are in fact synchronously sent to the thread where the event occurred.
Note: The "signal_stress" test case is also added later in the series to perf tool's built-in tests. The test here is more elaborate in that respect, which on one hand avoids bloating the perf tool unnecessarily, but we also benefit from structured tests with TAP-compliant output that the kselftest framework provides.
--- tools/testing/selftests/perf_events/.gitignore | 2 +- tools/testing/selftests/perf_events/Makefile | 6 +- tools/testing/selftests/perf_events/config | 1 +- tools/testing/selftests/perf_events/settings | 1 +- tools/testing/selftests/perf_events/sigtrap_threads.c | 210 +++++++++- 5 files changed, 220 insertions(+) create mode 100644 tools/testing/selftests/perf_events/.gitignore create mode 100644 tools/testing/selftests/perf_events/Makefile create mode 100644 tools/testing/selftests/perf_events/config create mode 100644 tools/testing/selftests/perf_events/settings create mode 100644 tools/testing/selftests/perf_events/sigtrap_threads.c
tools/testing/selftests/perf_events/.gitignore new file +2 -0
@@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +sigtrap_threads
tools/testing/selftests/perf_events/Makefile new file +6 -0
@@ -0,0 +1,6 @@ +# SPDX-License-Identifier: GPL-2.0 +CFLAGS += -Wl,-no-as-needed -Wall -I../../../../usr/include +LDFLAGS += -lpthread + +TEST_GEN_PROGS := sigtrap_threads +include ../lib.mk
tools/testing/selftests/perf_events/config new file +1 -0
@@ -0,0 +1 @@ +CONFIG_PERF_EVENTS=y
tools/testing/selftests/perf_events/settings new file +1 -0
@@ -0,0 +1 @@ +timeout=120
tools/testing/selftests/perf_events/sigtrap_threads.c new file +210 -0
210 lines not on this page · raw message
PATCH v4 8/10 selftests/perf_events: Add kselftest for remove_on_exec
In reply to Marco ElverAdd kselftest to test that remove_on_exec removes inherited events from child tasks.
---
v3:
* Fix for latest libc signal.h.
v2:
* Add patch to series.
--- .../testing/selftests/perf_events/.gitignore | 1 + tools/testing/selftests/perf_events/Makefile | 2 +- .../selftests/perf_events/remove_on_exec.c | 260 ++++++++++++++++++ 3 files changed, 262 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/perf_events/remove_on_exec.c
tools/testing/selftests/perf_events/.gitignore +1 -0
@@ -1,2 +1,3 @@ # SPDX-License-Identifier: GPL-2.0-only sigtrap_threads +remove_on_exec
tools/testing/selftests/perf_events/Makefile +1 -1
@@ -2,5 +2,5 @@ CFLAGS += -Wl,-no-as-needed -Wall -I../../../../usr/include LDFLAGS += -lpthread -TEST_GEN_PROGS := sigtrap_threads +TEST_GEN_PROGS := sigtrap_threads remove_on_exec include ../lib.mk
tools/testing/selftests/perf_events/remove_on_exec.c new file +260 -0
260 lines not on this page · raw message
Signature · 1 line
2.31.0.208.g409f899ff0-goog
[tip: perf/core] selftests/perf_events: Add kselftest for remove_on_exec
The following commit has been merged into the perf/core branch of tip:
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 6216798bf98e82c382922f1b71ecc4a13d6e65cb Gitweb: https://git.kernel.org/tip/6216798bf98e82c382922f1b71ecc4a13d6e65cb Author: Marco Elver <[email protected]> AuthorDate: Thu, 08 Apr 2021 12:36:03 +02:00 Committer: Peter Zijlstra <[email protected]> CommitterDate: Fri, 16 Apr 2021 16:32:42 +02:00
selftests/perf_events: Add kselftest for remove_on_exec
Add kselftest to test that remove_on_exec removes inherited events from child tasks.
--- tools/testing/selftests/perf_events/.gitignore | 1 +- tools/testing/selftests/perf_events/Makefile | 2 +- tools/testing/selftests/perf_events/remove_on_exec.c | 260 ++++++++++- 3 files changed, 262 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/perf_events/remove_on_exec.c
tools/testing/selftests/perf_events/.gitignore +1 -0
@@ -1,2 +1,3 @@ # SPDX-License-Identifier: GPL-2.0-only sigtrap_threads +remove_on_exec
tools/testing/selftests/perf_events/Makefile +1 -1
@@ -2,5 +2,5 @@ CFLAGS += -Wl,-no-as-needed -Wall -I../../../../usr/include LDFLAGS += -lpthread -TEST_GEN_PROGS := sigtrap_threads +TEST_GEN_PROGS := sigtrap_threads remove_on_exec include ../lib.mk
tools/testing/selftests/perf_events/remove_on_exec.c new file +260 -0
260 lines not on this page · raw message
PATCH v4 9/10 tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
In reply to Marco ElverSync tool's uapi to pick up the changes adding inherit_thread, remove_on_exec, and sigtrap fields to perf_event_attr.
---
v4:
* Update for new perf_event_attr::sig_data.
v3:
* Added to series.
--- tools/include/uapi/linux/perf_event.h | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
tools/include/uapi/linux/perf_event.h +11 -1
@@ -311,6 +311,7 @@ enum perf_event_read_format {#define PERF_ATTR_SIZE_VER4 104/* add: sample_regs_intr */ #define PERF_ATTR_SIZE_VER5 112/* add: aux_watermark */ #define PERF_ATTR_SIZE_VER6 120/* add: aux_sample_size */ +#define PERF_ATTR_SIZE_VER7 128/* add: sig_data */ /* * Hardware event_id to monitor via a performance monitoring event:
@@ -389,7 +390,10 @@ struct perf_event_attr { cgroup : 1, /* include cgroup events */ text_poke : 1, /* include text poke events */ build_id : 1, /* use build id in mmap2 events */ - __reserved_1 : 29; + inherit_thread : 1, /* children only inherit if cloned with CLONE_THREAD */ + remove_on_exec : 1, /* event is removed from task on exec */ + sigtrap : 1, /* send synchronous SIGTRAP on event */ + __reserved_1 : 26;union {__u32 wakeup_events;/* wakeup every n events */
@@ -441,6 +445,12 @@ struct perf_event_attr {__u16 __reserved_2;__u32 aux_sample_size;__u32 __reserved_3; + +/* +* User provided data if sigtrap=1, passed back to user via +* siginfo_t::si_perf, e.g. to permit user to identify the event. +*/ +__u64 sig_data; };/*
Signature · 1 line
2.31.0.208.g409f899ff0-goog
PATCH v4 10/10 perf test: Add basic stress test for sigtrap handling
In reply to Marco ElverAdd basic stress test for sigtrap handling as a perf tool built-in test. This allows sanity checking the basic sigtrap functionality from within the perf tool.
Note: A more elaborate kselftest version of this test can also be found in tools/testing/selftests/perf_events/sigtrap_threads.c.
---
v4:
* Update for new perf_event_attr::sig_data / si_perf handling.
v3:
* Added to series (per suggestion from Ian Rogers).
--- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 5 ++ tools/perf/tests/sigtrap.c | 150 ++++++++++++++++++++++++++++++++ tools/perf/tests/tests.h | 1 + 4 files changed, 157 insertions(+) create mode 100644 tools/perf/tests/sigtrap.c
tools/perf/tests/Build +1 -0
@@ -64,6 +64,7 @@ perf-y += parse-metric.o perf-y += pe-file-parsing.o perf-y += expand-cgroup.o perf-y += perf-time-to-tsc.o +perf-y += sigtrap.o $(OUTPUT)tests/llvm-src-base.c: tests/bpf-script-example.c tests/Build $(call rule_mkdir)
tools/perf/tests/builtin-test.c +5 -0
@@ -359,6 +359,11 @@ static struct test generic_tests[] = { .func = test__perf_time_to_tsc, .is_supported = test__tsc_is_supported, }, + { + .desc = "Sigtrap support", + .func = test__sigtrap, + .is_supported = test__wp_is_supported, /* uses wp for test */ + }, { .func = NULL, },
tools/perf/tests/sigtrap.c new file +150 -0
150 lines not on this page · raw message
tools/perf/tests/tests.h +1 -0
@@ -127,6 +127,7 @@ int test__parse_metric(struct test *test, int subtest);int test__pe_file_parsing (struct test *test,int subtest);int test__expand_cgroup_events (struct test *test,int subtest);int test__perf_time_to_tsc (struct test *test,int subtest); +int test__sigtrap (struct test *test,int subtest);bool test__bp_signal_is_supported (void );bool test__bp_account_is_supported (void );
Signature · 1 line
2.31.0.208.g409f899ff0-goog
Peter Zijlstra
maintainerQuoted 8 lines · Marco Elver
Marco Elver (9):
perf: ApplyPERF_EVENT_IOC_MODIFY_ATTRIBUTESto children
perf: Support only inheriting events if cloned withCLONE_THREAD
perf: Add support for event removal on exec
signal: IntroduceTRAP_PERFsi_codeandsi_perfto siginfo
perf: Add support for SIGTRAP on perf events selftests/perf_events: Add kselftest for process-wide sigtrap handling selftests/perf_events: Add kselftest forremove_on_exec
Thanks!, I've picked up the above 8 patches. Arnaldo, do you want to carry the last 2 patches or are you fine with me taking them as well?
Quoted 2 lines
tools headers uapi: Sync
tools/include/uapi/linux/perf_event.hperf test: Add basic stress test for sigtrap handling
On Thu, Apr 08, 2021 at 12:35PM +0200, Marco Elver wrote:
[...]
Quoted 36 lines
Motivation and Example Uses
---------------------------1. Our immediate motivation is low-overhead sampling-based race
detection for user space [1]. By usingperf_event_open()at process initialization, we can create hardware breakpoint/watchpoint events that are propagated automatically to all threads in a process. As far as we are aware, today no existing kernel facility (such as ptrace) allows us to set up process-wide watchpoints with minimal overheads (that are comparable tomprotect()of whole pages).2. Other low-overhead error detectors that rely on detecting
accesses to certain memory locations or code, process-wide and also only in a specific set of subtasks or threads.[1] https://llvm.org/devmtg/2020-09/slides/Morehouse-GWP-Tsan.pdf
Other ideas for use-cases we found interesting, but should only illustrate the range of potential to further motivate the utility (we're sure there are more):
3. Code hot patching without full stop-the-world. Specifically, by
setting a code breakpoint to entry to the patched routine, then send signals to threads and check that they are not in the routine, but without stopping them further. If any of the threads will enter the routine, it will receive SIGTRAP and pause.4. Safepoints without
mprotect(). Some Java implementations use
"load from a known memory location" as a safepoint. When threads need to be stopped, the page containing the location is mprotect()ed and threads get a signal. This could be replaced with a watchpoint, which does not require a whole page nor DTLB shootdowns.
Quoted 4 lines
5. Threads receiving signals on performance events to
throttle/unthrottle themselves.6. Tracking data flow globally.
For future reference:
I often wonder what happened to some new kernel feature, and how people are using it. I'm guessing there must be other users of "synchronous signals on perf events" somewhere by now (?), but the reason the whole thing started was because points #1 and #2 above.
Now 3 years later we were able to open source a framework that does #1 and #2 and more: https://github.com/google/gwpsan - "A framework for low-overhead sampling-based dynamic binary instrumentation, designed for implementing various bug detectors (also called "sanitizers") suitable for production uses. GWPSan does not modify the executed code, but instead performs dynamic analysis from signal handlers."
Documentation is sparse, it's still in development, and probably has numerous sharp corners right now...
That being said, the code demonstrates how low-overhead "process-wide synchronous event handling" thanks to perf events can be used to implement crazier things outside the realm of performance profiling.
Thanks!
-- Marco