From: Ira Weiny <ira.weiny@intel.com>
To: Steven Rostedt <rostedt@goodmis.org>,
Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Dave Jiang <dave.jiang@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
<linux-cxl@vger.kernel.org>
Subject: Re: [PATCH] cxl/trace: Initialize cxl_poison region name to NULL
Date: Thu, 14 Mar 2024 13:49:51 -0700 [thread overview]
Message-ID: <65f362eef27ee_221412947f@iweiny-mobl.notmuch> (raw)
In-Reply-To: <20240314144405.2ae1d16a@gandalf.local.home>
Steven Rostedt wrote:
> On Thu, 14 Mar 2024 10:04:14 -0700
> Alison Schofield <alison.schofield@intel.com> wrote:
>
> > On Thu, Mar 14, 2024 at 06:53:47AM -0700, Ira Weiny wrote:
> > > alison.schofield@ wrote:
> > > > From: Alison Schofield <alison.schofield@intel.com>
> > > >
> > > > The TP_STRUCT__entry that gets assigned the region name, or an
> > > > empty string if no region is present, is erroneously initialized
> > > > to the cxl_region pointer. It needs to be initialized to NULL
> > > > otherwise its length is wrong and garbage chars can appear in
> > > > the kernel trace output: /sys/kernel/tracing/trace
> > > >
> > > > Impact is that tooling depending on that trace data can miss
> > > > picking up a valid event when searching by region name. The
> > > > TP_printk() output, if enabled, does emit the correct region
> > > > names in the dmesg log.
> > > >
> > > > This was found during testing of the cxl-list option to report
> > > > media-errors for a region.
> > > >
> > > > Fixes: ddf49d57b841 ("cxl/trace: Add TRACE support for CXL media-error records")
> > > > Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> > > > ---
> > > > drivers/cxl/core/trace.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/cxl/core/trace.h b/drivers/cxl/core/trace.h
> > > > index bdf117a33744..bc5ca4d530d1 100644
> > > > --- a/drivers/cxl/core/trace.h
> > > > +++ b/drivers/cxl/core/trace.h
> > > > @@ -657,7 +657,7 @@ TRACE_EVENT(cxl_poison,
> > > > __string(host, dev_name(cxlmd->dev.parent))
> > > > __field(u64, serial)
> > > > __field(u8, trace_type)
> > > > - __string(region, region)
> > > > + __string(region, NULL)
> > >
> > > Couldn't this be "" instead of NULL then remove the __assign_str() if
> > > region is NULL?
>
> That will not work either.
>
> __string() allocates the space on the ring buffer.
Ah! Thanks, good to know.
>
> Getting rid of __assign_str() still leaves the buffer allocated with garbage.
>
> As I said in the other email thread [1], __string() and __assign_str() are
> tightly coupled and are the equivalent of:
>
> #define __string(buf, str) len = strlen(str); buf = malloc(len)
> #define __assign_str(buf, str) strcpy(buf, str)
>
> I also mentioned that __string() does much more. It can handle NULL
> pointers, so it's more like:
>
> #define __string(buf, str) len = str ? strlen(str) : strlen("null"); buf = malloc(len)
> #define __assign_str(buf, str) if (str) strcpy(buf, str); else strcpy(buf, "null")
>
> So if the string is NULL, then you want to copy it. That said, looking at
> this trace-event, it's still broken, because region isn't a string, so you
> are basically doing:
>
> len = strlen(region);
>
> Which doesn't make sense. What you want is:
>
> __string(region, region ? dev_name(®ion->dev) : NULL)
Yea this looks much cleaner.
Thanks!
Ira
>
> and then you can add the __assign_str(region, NULL) to the else path.
>
> -- Steve
>
>
> [1] https://lore.kernel.org/all/20240314143406.6289a060@gandalf.local.home/
>
next prev parent reply other threads:[~2024-03-14 20:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 4:43 [PATCH] cxl/trace: Initialize cxl_poison region name to NULL alison.schofield
2024-03-14 13:53 ` Ira Weiny
2024-03-14 17:04 ` Alison Schofield
2024-03-14 17:25 ` Ira Weiny
2024-03-14 18:44 ` Steven Rostedt
2024-03-14 18:47 ` Steven Rostedt
2024-03-14 20:08 ` Alison Schofield
2024-03-14 20:34 ` Steven Rostedt
2024-03-14 20:49 ` Ira Weiny [this message]
2024-03-14 17:24 ` Ira Weiny
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=65f362eef27ee_221412947f@iweiny-mobl.notmuch \
--to=ira.weiny@intel.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=jonathan.cameron@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=vishal.l.verma@intel.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).