linux-kernel - Re: [PATCH v1 1/1] scsi: ufs: Add command logging infrastructure

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: <b7de9358-b8ba-3100-a3f2-ebed8aaab490@codeaurora.org>
Date:   Thu, 16 Jan 2020 15:03:15 -0800
From:   "Asutosh Das (asd)" <asutoshd@...eaurora.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>, cang@...eaurora.org
Cc:     Avri Altman <Avri.Altman@....com>,
        "Winkler, Tomas" <tomas.winkler@...el.com>, nguyenb@...eaurora.org,
        rnayak@...eaurora.org, linux-scsi@...r.kernel.org,
        kernel-team@...roid.com, saravanak@...gle.com, salyzyn@...gle.com,
        Alim Akhtar <alim.akhtar@...sung.com>,
        Pedro Sousa <pedrom.sousa@...opsys.com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Evan Green <evgreen@...omium.org>,
        Janek Kotas <jank@...ence.com>,
        Stanley Chu <stanley.chu@...iatek.com>,
        Bean Huo <beanhuo@...ron.com>,
        Subhash Jadavani <subhashj@...eaurora.org>,
        Arnd Bergmann <arnd@...db.de>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 1/1] scsi: ufs: Add command logging infrastructure

On 10/28/2019 10:46 PM, Bjorn Andersson wrote:
> On Mon 28 Oct 19:37 PDT 2019, cang@...eaurora.org wrote:
> 
>> On 2019-10-23 18:33, Avri Altman wrote:
>>>>
>>>>> Add the necessary infrastructure to keep timestamp history of
>>>>> commands, events and other useful info for debugging complex issues.
>>>>> This helps in diagnosing events leading upto failure.
>>>>
>>>> Why not use tracepoints, for that?
>>> Ack on Tomas's comment.
>>> Are there any pieces of information that you need not provided by the
>>> upiu tracer?
>>>
>>> Thanks,
>>> Avri
>>
>> In extreme cases, when the UFS runs into bad state, system may crash. There
>> may not be a chance to collect trace. If trace is not collected and failure
>> is hard to be reproduced, some command logs prints would be very helpful to
>> help understand what was going on before we run into failure.
>>
> 
> This is a common problem shared among many/all subsystems, so it's
> better to rely on a generic solution for this; such as using tracepoints
> dumped into pstore/ramoops.
> 
> Regards,
> Bjorn
> 

Reviving this discussion.

Another issue with using ftrace is that several subsystems use it.
Consider a situation in which we store a history of 64 commands, 
responses and some other required info in ftrace.

Say there's a command that's stuck for seconds until the software times 
out. In this case, the other ftrace events are still enabled and keep 
writing to ftrace buffer thus overwriting some/most of the ufs's command 
history; thus the history is more or less lost. And there's a need to 
reproduce the issue with other tracing disabled.

So what we need is a client specific logging mechanism, which is 
lightweight as ftrace and can be parsed from ramdumps.

I'm open to ideas but ftrace in its current form may not be suitable for 
this.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project