On 22/03/11 09:45AM, Steven Rostedt wrote:
> On Fri, 11 Mar 2022 10:42:49 +0530
> Ritesh Harjani <[email protected]> wrote:
>
> > You may add below, if you like:-
> >
> > Reported-and-tested-by: Ritesh Harjani <[email protected]>
>
> Will do. Thanks for testing.
>
> I'll be adding this for the next merge window. I don't think this is
> something that needs to be added to this rc release nor stable. Do you
> agree?
If using an enum in TP_STRUCT__entry's __array field doesn't cause any side
effect other than it just can't be decoded by userspace perf record / trace-cmd,
then I guess it should be ok.
But for this PATCH 2/10 "ext4: Fix ext4_fc_stats trace point", will be
needed to be Cc'd to stable tree as discussed before, as it tries to
dereference some sbi pointer from the tracing ring buffer. Then hopefully the
only problem with previous kernel version would be that ext4_fc_stats(), won't
show proper values for array entries in older kernel version where this patch
of trace_events is not found.
But cat /sys/kernel/debug/tracing/trace_pipe should be able to show the right values.
From my side, I will send a v3 of this patch series with just EXT4_FC_REASON_MAX
defined using TRACE_DEFINE_ENUM.
Thanks again for your help :)
-ritesh
>
> -- Steve
On Fri, 11 Mar 2022 20:33:57 +0530
Ritesh Harjani <[email protected]> wrote:
> On 22/03/11 09:45AM, Steven Rostedt wrote:
> > On Fri, 11 Mar 2022 10:42:49 +0530
> > Ritesh Harjani <[email protected]> wrote:
> >
> > > You may add below, if you like:-
> > >
> > > Reported-and-tested-by: Ritesh Harjani <[email protected]>
> >
> > Will do. Thanks for testing.
> >
> > I'll be adding this for the next merge window. I don't think this is
> > something that needs to be added to this rc release nor stable. Do you
> > agree?
>
> If using an enum in TP_STRUCT__entry's __array field doesn't cause any side
> effect other than it just can't be decoded by userspace perf record / trace-cmd,
> then I guess it should be ok.
Right. It only causes trace-cmd and perf to not be able to parse the field.
But that's not really a regression, as it never was able to parse an enum
defining an array size.
>
> But for this PATCH 2/10 "ext4: Fix ext4_fc_stats trace point", will be
> needed to be Cc'd to stable tree as discussed before, as it tries to
> dereference some sbi pointer from the tracing ring buffer. Then hopefully the
> only problem with previous kernel version would be that ext4_fc_stats(), won't
> show proper values for array entries in older kernel version where this patch
> of trace_events is not found.
> But cat /sys/kernel/debug/tracing/trace_pipe should be able to show the right values.
>
>
> >From my side, I will send a v3 of this patch series with just EXT4_FC_REASON_MAX
> defined using TRACE_DEFINE_ENUM.
OK, I'll just add this for the next merge window. If people complain about
the parser not being able to parse this from user space, then we can either
backport it, or add a plugin that parses it manually in libtraceevent.
>
> Thanks again for your help :)
>
No problem. Thanks for the report.
-- Steve