lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 11 Mar 2022 11:42:37 -0500
From:   Steven Rostedt <>
To:     Ritesh Harjani <>
Cc:, Jan Kara <>,
        "Theodore Ts'o" <>,
        Harshad Shirwadkar <>,,
Subject: Re: [PATCHv2 00/10] ext4: Improve FC trace events

On Fri, 11 Mar 2022 20:33:57 +0530
Ritesh Harjani <> wrote:

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

Powered by blists - more mailing lists