On Fri, 11 Mar 2022 20:33:57 +0530 Ritesh Harjani <riteshh@xxxxxxxxxxxxx> wrote: > On 22/03/11 09:45AM, Steven Rostedt wrote: > > On Fri, 11 Mar 2022 10:42:49 +0530 > > Ritesh Harjani <riteshh@xxxxxxxxxxxxx> wrote: > > > > > You may add below, if you like:- > > > > > > Reported-and-tested-by: Ritesh Harjani <riteshh@xxxxxxxxxxxxx> > > > > 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
