From: Steven Rostedt <rostedt@goodmis.org>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
linux-trace-kernel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 4/4] tracing/probes: Fix to record 0-length data_loc in fetch_store_string*() if fails
Date: Mon, 10 Jul 2023 18:16:01 -0400 [thread overview]
Message-ID: <20230710181601.438b79a8@gandalf.local.home> (raw)
In-Reply-To: <168878453829.2721251.15110493517953858343.stgit@mhiramat.roam.corp.google.com>
On Sat, 8 Jul 2023 11:48:58 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> --- a/kernel/trace/trace_probe_kernel.h
> +++ b/kernel/trace/trace_probe_kernel.h
> @@ -55,8 +55,7 @@ fetch_store_string_user(unsigned long addr, void *dest, void *base)
> __dest = get_loc_data(dest, base);
>
> ret = strncpy_from_user_nofault(__dest, uaddr, maxlen);
> - if (ret >= 0)
> - *(u32 *)dest = make_data_loc(ret, __dest - base);
> + *(u32 *)dest = make_data_loc((ret >= 0) ? ret : 0, __dest - base);
>
> return ret;
> }
> @@ -87,8 +86,7 @@ fetch_store_string(unsigned long addr, void *dest, void *base)
> * probing.
> */
> ret = strncpy_from_kernel_nofault(__dest, (void *)addr, maxlen);
> - if (ret >= 0)
> - *(u32 *)dest = make_data_loc(ret, __dest - base);
> + *(u32 *)dest = make_data_loc((ret >= 0) ? ret : 0, __dest - base);
The above is a complex line, and not something that I think should be cut
and pasted between two different locations.
I know you took out the set_data_loc() helper, but really it should have
stayed, and have used that to update this code in the two places it
affected, instead of making the changes in those two locations.
That is, patch 3 could have had kept.
static nokprobe_inline void set_data_loc(int ret, void *dest, void *__dest, void *base)
{
if (ret >= 0)
*(u32 *)dest = make_data_loc(ret, __dest - base);
}
And this patch could have been:
static nokprobe_inline void set_data_loc(int ret, void *dest, void *__dest, void *base)
{
*(u32 *)dest = make_data_loc(ret, __dest - base);
}
That would keep the complexity down in this changes set.
-- Steve
>
> return ret;
> }
next prev parent reply other threads:[~2023-07-10 22:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-08 2:48 [PATCH v3 0/4] tracing/probes: Fix bugs in process_fetch_insn Masami Hiramatsu (Google)
2023-07-08 2:48 ` [PATCH v3 1/4] tracing/probes: Fix to avoid double count of the string length on the array Masami Hiramatsu (Google)
2023-07-08 2:48 ` [PATCH v3 2/4] tracing/probes: Fix not to count error code to total length Masami Hiramatsu (Google)
2023-07-08 2:48 ` [PATCH v3 3/4] Revert "tracing: Add "(fault)" name injection to kernel probes" Masami Hiramatsu (Google)
2023-07-08 2:48 ` [PATCH v3 4/4] tracing/probes: Fix to record 0-length data_loc in fetch_store_string*() if fails Masami Hiramatsu (Google)
2023-07-10 22:16 ` Steven Rostedt [this message]
2023-07-11 0:05 ` Masami Hiramatsu
2023-07-11 0:16 ` 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 \
--in-reply-to=20230710181601.438b79a8@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=dan.carpenter@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@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 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).