linux-kernel - RE: [PATCH v1 3/3] scsi: ufs: Make UPIU trace easier differentiate among CDB, OSF, and TM

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM6PR04MB6575864DCED7720950302244FCCD0@DM6PR04MB6575.namprd04.prod.outlook.com>
Date:   Tue, 8 Dec 2020 08:03:48 +0000
From:   Avri Altman <Avri.Altman@....com>
To:     Steven Rostedt <rostedt@...dmis.org>
CC:     Bean Huo <huobean@...il.com>,
        "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "stanley.chu@...iatek.com" <stanley.chu@...iatek.com>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "bvanassche@....org" <bvanassche@....org>,
        "tomas.winkler@...el.com" <tomas.winkler@...el.com>,
        "cang@...eaurora.org" <cang@...eaurora.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v1 3/3] scsi: ufs: Make UPIU trace easier differentiate
 among CDB, OSF, and TM

> 
> On Mon, 7 Dec 2020 16:40:51 +0000
> Avri Altman <Avri.Altman@....com> wrote:
> 
> > >
> > > On Mon, 7 Dec 2020 07:57:27 +0000
> > > Avri Altman <Avri.Altman@....com> wrote:
> > >
> > > > >
> > > > >         TP_printk(
> > > > > -               "%s: %s: HDR:%s, CDB:%s",
> > > > > +               "%s: %s: HDR:%s, %s:%s",
> > > > >                 __get_str(str), __get_str(dev_name),
> > > > >                 __print_hex(__entry->hdr, sizeof(__entry->hdr)),
> > > > > +               __get_str(tsf_type),
> > > > This breaks what current parsers expects.
> > > > Why str is not enough to distinguish between the command?
> > >
> > > Hopefully it shouldn't. Reading from user space should use the
> > > libtraceevent library, that reads the format files and extracts the raw
> > > data to find the fields. As long as the field exists, it should not break
> > > user space parsers. If it does, please let me know, and I'll gladly help
> > > change the user space code to use libtraceevent :-)
> > Hi Steve,
> > Thanks. I wasn't aware of libtraceevent - is this a new thing?
> 
> Actually, it's been around almost as long as ftrace. But unfortunately,
> it's just now becoming a separate library. It was originally developed for
> trace-cmd, but has been copied into perf, power-top and rasdaemon. But
> this
> copying is inefficient and a maintenance nightmare, and we finally have the
> library as a stand alone, and hopefully will be delivered by distributions
> (I believe they are packaging it).
> 
>    https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/
> 
> Looks like distros are starting to catch on.
> 
>   https://packages.debian.org/unstable/libtraceevent-dev
> 
> 
> We are currently working on libtracefs
> 
>   https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/
> 
> Which will make it a lot easier for applications to interact with the
> tracefs file system. I'm hoping to have this ready for distros by the end
> of the year. We have applications coming that depend on these.
> 
> >
> > We have a relatively sophisticated analysis platform that utilizes raw traces,
> > Among which the upiu trace is the most important and informative.
> >
> > This tool has evolved over the years, adding more and more parsers per
> need,
> > and the users are picking the appropriate parser per the trace they used.
> >
> > We will surely be glad to adopt new tracing capabilities,
> 
> I think libtraceevent and libtracefs would be a much welcome addition for
> upiu trace as it would be reading raw data (very fast), and have an API
> that makes doing so much simpler. For example, I just wrote a quick program
> that checks what files an application opens (this is not in anyway
> production ready):
> 
>   http://rostedt.org/code/show-open-files.c
> 
> > But we would prefer not to break anything.
> 
> Of course!
> 
> And again, I would be happy to help out in converting to this libraries. It
> will make your applications more robust, as they make it so that you do not
> need to rely on the order of fields.
> 
> Note, there's plans on making these libraries python modules as well (to
> have python scripts enable and read ftrace data).
Thanks a lot for your insightful comments.
We will surely look into libtraceevent and libtracefs

Thanks,
Avri
> 
> -- Steve