On Wed, 20 Nov 2013 19:01:22 -0700
Shuah Khan <shuah...@samsung.com> wrote:
> On 11/20/2013 06:40 PM, Shuah Khan wrote:
> > ---
> > include/trace/events/power.h | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/trace/events/power.h b/include/trace/events/power.h
> > index cda100d..5ba545a 100644
> > --- a/include/trace/events/power.h
> > +++ b/include/trace/events/power.h
> > @@ -110,12 +110,14 @@ DECLARE_EVENT_CLASS(wakeup_source,
> > TP_ARGS(name, state),
> >
> > TP_STRUCT__entry(
> > - __string( name, name )
> > + __string(name, name ? name : "(no name)")
> > __field( u64, state )
> > ),
> >
> > TP_fast_assign(
> > - __assign_str(name, name);
> > + const char *tname = name ? name : "(no name)";
> > +
> > + __assign_str(name, tname);
> > __entry->state = state;
> > ),
> >
> >
>
> Adding tracing maintainers.
Thanks!
This is one solution, but what about just making the tracing facility a
bit more robust for everyone. Following what glibc printf() does when
it is passed a NULL, does this patch fix it too?
-- Steve
(haven't even compile tested this)
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 52594b2..bdac88c 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -372,7 +372,8 @@ ftrace_define_fields_##call(struct ftrace_event_call
*event_call) \
__data_size += (len) * sizeof(type);
#undef __string
-#define __string(item, src) __dynamic_array(char, item, strlen(src) + 1)
+#define __string(item, src) __dynamic_array(char, item,
\
+ strlen((src) ? (src) : "(null)") + 1)
#undef DECLARE_EVENT_CLASS
#define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print) \
@@ -501,7 +502,7 @@ static inline notrace int ftrace_get_offsets_##call(
\
#undef __assign_str
#define __assign_str(dst, src) \
- strcpy(__get_str(dst), src);
+ strcpy(__get_str(dst), (src) ? (src) : "(null)");
#undef TP_fast_assign
#define TP_fast_assign(args...) args
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
