From: Brian Foster <bfoster@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: XFS tracepoint warning due to NULL string
Date: Wed, 23 Mar 2022 10:24:44 -0400 [thread overview]
Message-ID: <YjstrL6J16TEL/mW@bfoster> (raw)
In-Reply-To: <20220323100200.6f22e417@gandalf.local.home>
On Wed, Mar 23, 2022 at 10:02:00AM -0400, Steven Rostedt wrote:
> On Wed, 23 Mar 2022 08:47:10 -0400
> Brian Foster <bfoster@redhat.com> wrote:
>
> > What's the best way to address this going forward with the memory usage
> > verification in place? ISTM we could perhaps consider dropping the
> > custom %.*s thing in favor of using %s with __string_len() and friends,
> > or perhaps just replace the open-coded NULL parameter with the "(null)"
> > string that the trace subsystem code seems to use on NULL pointer
> > checks. The latter seems pretty simple and straightforward of a change
> > to me, but I want to make sure I'm not missing something more obvious.
> > Thoughts?
>
> Can you see if the following (totally untested) patch fixes your issue?
>
Yup, that restores historical behavior. Thanks!
Brian
> -- Steve
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 08ea781540b5..f4de111fa18f 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -3673,12 +3673,17 @@ static char *trace_iter_expand_format(struct trace_iterator *iter)
> }
>
> /* Returns true if the string is safe to dereference from an event */
> -static bool trace_safe_str(struct trace_iterator *iter, const char *str)
> +static bool trace_safe_str(struct trace_iterator *iter, const char *str,
> + bool star, int len)
> {
> unsigned long addr = (unsigned long)str;
> struct trace_event *trace_event;
> struct trace_event_call *event;
>
> + /* Ignore strings with no length */
> + if (star && !len)
> + return true;
> +
> /* OK if part of the event data */
> if ((addr >= (unsigned long)iter->ent) &&
> (addr < (unsigned long)iter->ent + iter->ent_size))
> @@ -3864,7 +3869,7 @@ void trace_check_vprintf(struct trace_iterator *iter, const char *fmt,
> * instead. See samples/trace_events/trace-events-sample.h
> * for reference.
> */
> - if (WARN_ONCE(!trace_safe_str(iter, str),
> + if (WARN_ONCE(!trace_safe_str(iter, str, star, len),
> "fmt: '%s' current_buffer: '%s'",
> fmt, show_buffer(&iter->seq))) {
> int ret;
>
prev parent reply other threads:[~2022-03-23 14:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-23 12:47 XFS tracepoint warning due to NULL string Brian Foster
2022-03-23 14:02 ` Steven Rostedt
2022-03-23 14:24 ` Brian Foster [this message]
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=YjstrL6J16TEL/mW@bfoster \
--to=bfoster@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--cc=rostedt@goodmis.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.