From: Dominique Martinet <asmadeus@codewreck.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Christian Schoenebeck <linux_oss@crudebyte.com>,
JP Kobryn <inwardvessel@gmail.com>,
ericvh@kernel.org, lucho@ionkov.net, mhiramat@kernel.org,
mathieu.desnoyers@efficios.com, v9fs@lists.linux.dev,
linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH] 9p: prevent read overrun in protocol dump tracepoint
Date: Sun, 3 Dec 2023 14:32:15 +0900 [thread overview]
Message-ID: <ZWwS3_DGmqc73dxm@codewreck.org> (raw)
In-Reply-To: <20231202231524.4ce1d342@gandalf.local.home>
Steven Rostedt wrote on Sat, Dec 02, 2023 at 11:15:24PM -0500:
> > Also, for custom tracepoints e.g. bpftrace the program needs to know how
> > many bytes can be read safely even if it's just for dumping -- unless
> > dynamic_array is a "fat pointer" that conveys its own size?
> > (Sorry didn't take the time to check)
>
> Yes, there's also a __get_dynamic_array_len(line) that will return the
> allocated length of the line. Is that what you need?
Yes, thanks! So the lower two bytes of the field are its position in
the entry and the higher two bytes its size; ok.
It doesn't look like bpftrace has any helper for it but that can
probably be sorted out if someone wants to dump data there.
Let's update the event to use a dynamic array and have printk fomrat to
use %*ph with that length.
JP Kobryn, does that sound good to you? I'm not sure what you were
trying to do in the first place.
Do you want to send a v2 or shall I?
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2023-12-03 5:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-02 3:04 [PATCH] 9p: prevent read overrun in protocol dump tracepoint JP Kobryn
2023-12-02 4:35 ` asmadeus
2023-12-02 7:19 ` asmadeus
2023-12-02 13:05 ` Christian Schoenebeck
2023-12-03 1:14 ` Steven Rostedt
2023-12-03 1:33 ` Dominique Martinet
2023-12-03 4:15 ` Steven Rostedt
2023-12-03 5:32 ` Dominique Martinet [this message]
2023-12-04 16:20 ` JP Kobryn
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=ZWwS3_DGmqc73dxm@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=bpf@vger.kernel.org \
--cc=ericvh@kernel.org \
--cc=inwardvessel@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=v9fs@lists.linux.dev \
/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;
as well as URLs for NNTP newsgroup(s).