From: Jeff Barnes <jeffbarnes@linux.microsoft.com>
To: rostedt@goodmis.org, mhiramat@kernel.org, shuah@kernel.org
Cc: mathieu.desnoyers@efficios.com, reddybalavignesh9979@gmail.com,
richard.weiyang@gmail.com, michael.bommarito@gmail.com,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: [PATCH v2 0/3] tracing/user_events: Share state with existing threads
Date: Tue, 6 Oct 2026 12:47:17 -0400 [thread overview]
Message-ID: <20261006164720.3940272-1-jeffbarnes@linux.microsoft.com> (raw)
In-Reply-To: <20261002153934.798176-1-jeffbarnes@linux.microsoft.com>
A thread created before the first user_events registration can share an
mm with another thread while retaining a NULL user_event_mm. If it later
registers an event, it can create independent registration state instead
of observing the state already associated with the shared mm. This allows
pre-existing threads in one address space to register different events
using the same enable address and bit.
Patch 1 fixes a locking issue found while reviewing this path. Duplicate
enabler lookup performs a plain traversal of the enabler list, while
asynchronous fault cleanup can remove entries under event_mutex. Serialize
the traversal with that cleanup.
Patch 2 finds the already-published user_event_mm for the current mm and
attaches the pre-existing thread to it. The global list lock serializes
lookup and attachment with the final task-count decrement and list removal.
Patch 3 adds a regression test covering two pre-existing threads that
attempt to register different events at the same enable address and bit.
Tested on 7.3.0-rc6 with virtme-ng:
- user_events ftrace_test: 6/6 passed
- user_events dyn_test: 4/4 passed
- user_events perf_test: 2/2 passed
- user_events abi_test: 7/7 passed
The user.preexisting_threads_same_address test passed.
Changes since v1:
- Split the duplicate-enabler locking correction into a preparatory patch.
- Protect duplicate-enabler traversal with event_mutex.
- Document and assert the group reg_mutex contract.
- Simplify existing-thread attachment around user_event_mms_lock.
- Serialize the final tasks decrement and list removal with lookup and
attachment.
- Keep the regression selftest as the final patch.
Jeff Barnes (3):
tracing/user_events: Serialize duplicate enabler lookup with event
removal
tracing/user_events: Share event state with existing threads
selftests/user_events: Test registration from existing threads
kernel/trace/trace_events_user.c | 56 ++++++--
.../testing/selftests/user_events/abi_test.c | 125 ++++++++++++++++++
2 files changed, 171 insertions(+), 10 deletions(-)
base-commit: a90ee4305c4a5df72c11b31dacfdc76e00fcf78a
--
2.43.0
next prev parent reply other threads:[~2026-10-06 16:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 15:39 [PATCH 0/2] tracing/user_events: Share state between existing threads Jeff Barnes
2026-10-02 15:39 ` [PATCH 1/2] selftests/user_events: Test registration from " Jeff Barnes
2026-10-03 1:33 ` sashiko-bot
2026-10-02 15:39 ` [PATCH 2/2] tracing/user_events: Share tracing state between " Jeff Barnes
2026-10-05 14:39 ` [PATCH v2 0/2] " Jeff Barnes
2026-10-05 14:39 ` [PATCH v2 1/2] selftests/user_events: Test registration from " Jeff Barnes
2026-10-05 14:39 ` [PATCH v2 2/2] tracing/user_events: Share tracing state between " Jeff Barnes
2026-10-06 16:47 ` Jeff Barnes [this message]
2026-10-06 16:47 ` [PATCH v2 1/3] tracing/user_events: Serialize duplicate enabler lookup with event removal Jeff Barnes
2026-10-06 16:47 ` [PATCH v2 2/3] tracing/user_events: Share event state with existing threads Jeff Barnes
2026-10-06 16:47 ` [PATCH v2 3/3] selftests/user_events: Test registration from " Jeff Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261006164720.3940272-1-jeffbarnes@linux.microsoft.com \
--to=jeffbarnes@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=michael.bommarito@gmail.com \
--cc=reddybalavignesh9979@gmail.com \
--cc=richard.weiyang@gmail.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.