linux-kernel - RE: [PATCH v3 0/6] Several changes for the UPIU trace

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]

Date:   Mon, 14 Dec 2020 22:13:39 +0000
From:   Avri Altman <Avri.Altman@....com>
To:     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>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "joe@...ches.com" <joe@...ches.com>
CC:     "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 0/6] Several changes for the UPIU trace

Bean Hi,
I support this series.
I think it is a good idea to print the response on complete,
But you need to change the prefix strings, otherwise you are breaking the current parsers.

Say that you have a trace log, generated sometime during 2020 using the current upiu trace.
It would look something like:
"send" <request upiu>
"complete" <request upiu>

And another log generated sometime during 2021 after your change is merged:
"send" <request upiu>
"complete" < ****response upiu ****>

The current parser won't be able to differentiate between those logs.
Just change the prefix strings to be "send_req" and "complete_rsp", or something,
so the parsing tools that support the new format will be able to differentiate it from the old one.
  
Also, once the parser can differentiate the new format from the old,
whatever follows its fine: cdb / osf / tsf or whatever makes sense to you.

Thanks,
Avri
 

> -----Original Message-----
> From: Bean Huo <huobean@...il.com>
> Sent: Monday, December 14, 2020 10:20 PM
> To: alim.akhtar@...sung.com; Avri Altman <Avri.Altman@....com>;
> asutoshd@...eaurora.org; jejb@...ux.ibm.com;
> martin.petersen@...cle.com; stanley.chu@...iatek.com;
> beanhuo@...ron.com; bvanassche@....org; tomas.winkler@...el.com;
> cang@...eaurora.org; rostedt@...dmis.org; joe@...ches.com
> Cc: linux-scsi@...r.kernel.org; linux-kernel@...r.kernel.org
> Subject: [PATCH v3 0/6] Several changes for the UPIU trace
> 
> CAUTION: This email originated from outside of Western Digital. Do not click
> on links or open attachments unless you recognize the sender and know that
> the content is safe.
> 
> 
> From: Bean Huo <beanhuo@...ron.com>
> 
> Changelog:
> 
> V2--V3:
>   1. Fix a typo in patch 1/6 (Reported-by: Joe Perches <joe@...ches.com>)
> 
> V1--V2:
>   1. Convert __get_str(str) to __print_symbolic()
>   2. Add new patches 1/6, 2/6,3/6
>   3. Use __print_symbolic() in patch 6/6
> 
> Bean Huo (6):
>   scsi: ufs: Remove stringize operator '#' restriction
>   scsi: ufs: Use __print_symbolic() for UFS trace string print
>   scsi: ufs: Don't call trace_ufshcd_upiu() in case trace poit is
>     disabled
>   scsi: ufs: Distinguish between query REQ and query RSP in query trace
>   scsi: ufs: Distinguish between TM request UPIU and response UPIU in TM
>     UPIU trace
>   scsi: ufs: Make UPIU trace easier differentiate among CDB, OSF, and TM
> 
>  drivers/scsi/ufs/ufs.h     |  17 ++++++
>  drivers/scsi/ufs/ufshcd.c  |  72 ++++++++++++++++---------
>  include/trace/events/ufs.h | 108 +++++++++++++++++++++++--------------
>  3 files changed, 131 insertions(+), 66 deletions(-)
> 
> --
> 2.17.1