From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Brian Geffon <bgeffon@google.com>,
John Stultz <jstultz@google.com>, Ian Rogers <irogers@google.com>,
Suleiman Souhlal <suleiman@google.com>
Subject: Re: [PATCH v2 1/3] tracing: Have futex syscall trace event show specific user data
Date: Wed, 11 Mar 2026 18:03:25 +0900 [thread overview]
Message-ID: <20260311180325.488f724d97204d1a3c66f071@kernel.org> (raw)
In-Reply-To: <20260310201036.542627924@kernel.org>
On Tue, 10 Mar 2026 16:09:55 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> +#ifdef CONFIG_FTRACE_SYSCALLS
> +static const char * __futex_cmds[] =
> +{
> + "FUTEX_WAIT", "FUTEX_WAKE", "FUTEX_FD", "FUTEX_REQUEUE",
> + "FUTEX_CMP_REQUEUE", "FUTEX_WAKE_OP", "FUTEX_LOCK_PI",
> + "FUTEX_UNLOCK_PI", "FUTEX_TRYLOCK_PI", "FUTEX_WAIT_BITSET",
> + "FUTEX_WAKE_BITSET", "FUTEX_WAIT_REQUEUE_PI", "FUTEX_CMP_REQUEUE_PI",
> + "FUTEX_LOCK_PI2",
> +};
> +
[...]
> @@ -437,6 +464,69 @@ sys_enter_openat_print_fmt(struct syscall_metadata *entry, char *buf, int len)
> return pos;
> }
>
> +static int __init
> +sys_enter_futex_print_fmt(struct syscall_metadata *entry, char *buf, int len)
> +{
> + int pos = 0;
> +
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "\"uaddr: 0x%%lx (0x%%lx) cmd=%%s%%s%%s");
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + " val: 0x%%x timeout/val2: 0x%%llx");
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + " uaddr2: 0x%%lx val3: 0x%%x\", ");
> +
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + " REC->uaddr,");
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + " REC->__value,");
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + " __print_symbolic(REC->op & 0x%x, ", FUTEX_CMD_MASK);
> +
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_WAIT\"}, ", FUTEX_WAIT);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_WAKE\"}, ", FUTEX_WAKE);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_FD\"}, ", FUTEX_FD);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_REQUEUE\"}, ", FUTEX_REQUEUE);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_CMP_REQUEUE\"}, ", FUTEX_CMP_REQUEUE);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_WAKE_OP\"}, ", FUTEX_WAKE_OP);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_LOCK_PI\"}, ", FUTEX_LOCK_PI);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_UNLOCK_PI\"}, ", FUTEX_UNLOCK_PI);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_TRYLOCK_PI\"}, ", FUTEX_TRYLOCK_PI);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_WAIT_BITSET\"}, ", FUTEX_WAIT_BITSET);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_WAKE_BITSET\"}, ", FUTEX_WAKE_BITSET);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_WAIT_REQUEUE_PI\"}, ", FUTEX_WAIT_REQUEUE_PI);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_CMP_REQUEUE_PI\"}, ", FUTEX_CMP_REQUEUE_PI);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + "{%d, \"FUTEX_LOCK_PI2\"}),", FUTEX_LOCK_PI2);
Hmm can we share __futex_cmds[] with kernel/futex/syscalls.c?
Then these could be
for (i = 0; i <= FUTEX_LOCK_PI2; i++)
pos += snprintf(buf + pos, LEN_OR_ZERO,
"{%d, \"%s\"}%s", i, __futex_cmds[i],
i == FUTEX_LOCK_PI2 ? ")," : ", ");
> +
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + " (REC->op & %d) ? \"|FUTEX_PRIVATE_FLAG\" : \"\",",
> + FUTEX_PRIVATE_FLAG);
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + " (REC->op & %d) ? \"|FUTEX_CLOCK_REALTIME\" : \"\",",
> + FUTEX_CLOCK_REALTIME);
> +
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + " REC->val, REC->utime,");
> +
> + pos += snprintf(buf + pos, LEN_OR_ZERO,
> + " REC->uaddr, REC->val3");
> + return pos;
> +}
> +
> static int __init
> __set_enter_print_fmt(struct syscall_metadata *entry, char *buf, int len)
> {
[...]
> @@ -689,6 +799,48 @@ static int syscall_copy_user_array(char *buf, const char __user *ptr,
> return 0;
> }
>
> +static int
> +syscall_get_futex(unsigned long *args, char **buffer, int *size, int buf_size)
> +{
> + struct syscall_user_buffer *sbuf;
> + const char __user *ptr;
> + char *buf;
> +
> + /* buf_size of zero means user doesn't want user space read */
> + if (!buf_size)
> + return -1;
> +
> + /* If the syscall_buffer is NULL, tracing is being shutdown */
> + sbuf = READ_ONCE(syscall_buffer);
> + if (!sbuf)
> + return -1;
> +
> + ptr = (char __user *)args[0];
> +
> + *buffer = trace_user_fault_read(&sbuf->buf, ptr, 4, NULL, NULL);
> + if (!*buffer)
> + return -1;
> +
> + /* Add room for the value */
> + *size += 4;
> +
> + buf = *buffer;
As kernel test bot says, this does nothing. (*buffer is already assigned)
> +
> + return 0;
> +}
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2026-03-11 9:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 20:09 [PATCH v2 0/3] tracing: Read user data from futex system call trace event Steven Rostedt
2026-03-10 20:09 ` [PATCH v2 1/3] tracing: Have futex syscall trace event show specific user data Steven Rostedt
2026-03-11 7:41 ` kernel test robot
2026-03-11 9:03 ` Masami Hiramatsu [this message]
2026-03-11 14:16 ` Steven Rostedt
2026-03-11 11:23 ` kernel test robot
2026-03-10 20:09 ` [PATCH v2 2/3] tracing: Update futex syscall trace event to show more commands Steven Rostedt
2026-03-12 5:34 ` Masami Hiramatsu
2026-03-10 20:09 ` [PATCH v2 3/3] tracing: Show TID and flags for PI futex system call trace event Steven Rostedt
2026-03-12 8:15 ` Masami Hiramatsu
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=20260311180325.488f724d97204d1a3c66f071@kernel.org \
--to=mhiramat@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bgeffon@google.com \
--cc=irogers@google.com \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=peterz@infradead.org \
--cc=rostedt@kernel.org \
--cc=suleiman@google.com \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox