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 for Android: free password hash cracker in your pocket

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

Message-ID: <20201207103708.66897ef3@gandalf.local.home>
Date:   Mon, 7 Dec 2020 10:37:08 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Avri Altman <Avri.Altman@....com>
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 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 :-)

-- Steve