From: Pavel Begunkov <[email protected]>
To: Steven Rostedt <[email protected]>,
Olivier Langlois <[email protected]>
Cc: Stefan Metzmacher <[email protected]>, Jens Axboe <[email protected]>,
Ingo Molnar <[email protected]>,
[email protected], [email protected]
Subject: Re: [PATCH] io_uring: Add to traces the req pointer when available
Date: Sat, 29 May 2021 13:30:31 +0100 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 5/28/21 11:42 PM, Steven Rostedt wrote:
> On Wed, 26 May 2021 12:18:37 -0400
> Olivier Langlois <[email protected]> wrote:
>
>>> If that gets changed, could be also include the personality id and
>>> flags here,
>>> and maybe also translated the opcode and flags to human readable
>>> strings?
>>>
>> If Jens and Pavel agrees that they would like to see this info in the
>> traces, I have no objection adding it.
>>
>> Still waiting input from Steven Rostedt which I believe is the trace
>> system maintainer concerning the hash-ptr situation.
>>
>> I did receive an auto-respond from him saying that he was in vacation
>> until May 28th...
>
> Yep, I'm back now.
>
> Here's how it works using your patch as an example:
>
>> TP_fast_assign(
>> __entry->ctx = ctx;
>> + __entry->req = req;
>
> The "__entry" is a structure defined by TP_STRUCT__entry() that is located
> on the ring buffer that can be read directly by user space (aka trace-cmd).
> So yes, that value is never hashed, and one of the reasons that tracefs
> requires root privilege to read it.
>
>> __entry->opcode = opcode;
>> __entry->user_data = user_data;
>> __entry->force_nonblock = force_nonblock;
>> __entry->sq_thread = sq_thread;
>> ),
>>
>> - TP_printk("ring %p, op %d, data 0x%llx, non block %d, sq_thread %d",
>> - __entry->ctx, __entry->opcode,
>> - (unsigned long long) __entry->user_data,
>> - __entry->force_nonblock, __entry->sq_thread)
>> + TP_printk("ring %p, req %p, op %d, data 0x%llx, non block %d, "
>> + "sq_thread %d", __entry->ctx, __entry->req,
>> + __entry->opcode, (unsigned long long)__entry->user_data,
>> + __entry->force_nonblock, __entry->sq_thread)
>> );
>
> The TP_printk() macro *is* used when reading the "trace" or "trace_pipe"
> file, and that uses vsnprintf() to process it. Which will hash the values
> for %p (by default, because that's what it always did when vsnprintf()
> started hashing values).
>
> Masami Hiramatsu added the hash-ptr option (which I told him to be the
> default as that was the behavior before that option was created), where the
> use could turn off the hashing.
>
> There's lots of trace events that expose the raw pointers when hash-ptr is
> off or if the ring buffers are read via the trace_pip_raw interface.
>
> What's special about these pointers to hash them before they are recorded?
io_uring offers all different operations and has internal request/memory
recycling, so it may be an easy vector of attack in case of some
vulnerabilities found, but nothing special. As that's the status quo,
I wouldn't care, let's put aside my concerns and print them raw.
--
Pavel Begunkov
next prev parent reply other threads:[~2021-05-29 12:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <[email protected]>
2021-05-25 8:21 ` [PATCH] io_uring: Add to traces the req pointer when available Pavel Begunkov
2021-05-25 8:33 ` Pavel Begunkov
2021-05-25 21:26 ` Olivier Langlois
2021-05-25 21:48 ` Olivier Langlois
2021-05-25 22:28 ` Jens Axboe
2021-05-26 8:28 ` Olivier Langlois
2021-05-25 21:29 ` Olivier Langlois
2021-05-26 12:38 ` Stefan Metzmacher
2021-05-26 16:18 ` Olivier Langlois
2021-05-26 17:19 ` Olivier Langlois
2021-05-29 12:18 ` Pavel Begunkov
2021-05-28 22:42 ` Steven Rostedt
2021-05-29 12:30 ` Pavel Begunkov [this message]
2021-05-29 12:34 ` Pavel Begunkov
2021-05-29 17:55 ` Steven Rostedt
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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