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  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]
Date:   Sun, 21 Oct 2018 10:29:17 +0530
From:   Sai Prakash Ranjan <>
To:     Joel Fernandes <>
Cc:     Tom Zanussi <>,
        Catalin Marinas <>,
        Will Deacon <>,
        Vivek Gautam <>,
        Prasad Sodagudi <>,
        Ingo Molnar <>,,
        Anton Vorontsov <>,
        Ingo Molnar <>,
        Sibi Sankar <>,
        Laura Abbott <>,,
        Kees Cook <>,
        Arnd Bergmann <>,,
        Steven Rostedt <>,
        Jason Baron <>,
        Rob Herring <>,
        Tingwei Zhang <>,,
        Tony Luck <>,
        Rajendra Nayak <>,
        Jim Cromie <>,
        Greg Kroah-Hartman <>,,
        Bryan Huntsman <>,
        Masami Hiramatsu <>,
        Colin Cross <>,
        Joe Perches <>,
Subject: Re: [PATCH 0/6] Tracing register accesses with pstore and dynamic

On 10/21/2018 9:16 AM, Sai Prakash Ranjan wrote:
> On 10/20/2018 9:57 PM, Joel Fernandes wrote:
>> On Sat, Oct 20, 2018 at 12:02:37PM +0530, Sai Prakash Ranjan wrote:
>>> On 10/20/2018 10:55 AM, Joel Fernandes wrote:
>>>> On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote:
>>>>> Hi,
>>>>> This patch series adds Event tracing support to pstore and is 
>>>>> continuation
>>>>> to the RFC patch introduced to add a new tracing facility for register
>>>>> accesses called Register Trace Buffer(RTB). Since we decided to not 
>>>>> introduce
>>>>> a separate framework to trace register accesses and use existing 
>>>>> framework
>>>>> like tracepoints, I have moved from RFC. Details of the RFC in link 
>>>>> below:
>>>>> Link: 
>>>>> MSR tracing example given by Steven was helpful in using 
>>>>> tracepoints for
>>>>> register accesses instead of using separate trace. But just having 
>>>>> these
>>>>> IO traces would not help much unless we could have them in some 
>>>>> persistent
>>>>> ram buffer for debugging unclocked access or some kind of bus hang 
>>>>> or an
>>>>> unexpected reset caused by some buggy driver which happens a lot 
>>>>> during
>>>>> initial development stages. By analyzing the last few entries of 
>>>>> this buffer,
>>>>> we could identify the register access which is causing the issue.
>>>> Hi Sai,
>>>> I wanted to see if I could make some time to get your patches 
>>>> working. We are
>>>> hitting usecases that need something like this as well. Basically 
>>>> devices
>>>> hanging and then the ramdump does not tell us much, so in this case 
>>>> pstore
>>>> events can be really helpful. This usecase came up last year as well.
>>>> Anyway while I was going through your patches, I cleaned up some 
>>>> pstore code
>>>> as well and I have 3 more patches on top of yours for this clean up. 
>>>> I prefer
>>>> we submit the patches together and sync our work together so that 
>>>> there is
>>>> least conflict.
>>>> Here's my latest tree:
>>>> (note that I have only build tested the patches since I just wrote 
>>>> them and
>>>> its quite late in the night here ;-))
>>> Hi Joel,
>>> Thanks for looking into this. Sure, I will be happy to sync up with 
>>> you on
>> Thanks. And added a fourth patch in the tree too.
>>> this. I can test your additional patches on top of my pstore patches. 
>>> BTW,
>>> I'm still stuck at copying binary record into pstore and then extract it
>>> during read time. Seems like I'm missing something.
>> Sure, push your latest somewhere and let me know. I'll try to get you 
>> unstuck.
> Thanks Joel, I will push my changes and let you know in some time.

Hi Joel,

Here's my tree:

I have one patch extra on top of your patches. Nothing much on binary 
record storage in this patch, only removed kmalloc in pstore event call 
to avoid loop.

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Powered by blists - more mailing lists