linux-kernel - Re: [RESEND PATCH 1/2] PM / sleep: print function name of callbacks

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]

Date:   Wed, 2 Nov 2016 14:02:17 -0700
From:   Brian Norris <briannorris@...omium.org>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        Doug Anderson <dianders@...omium.org>,
        Brian Norris <computersforpeace@...il.com>,
        Jeffy Chen <jeffy.chen@...k-chips.com>,
        linux-pm@...r.kernel.org,
        Chuansheng Liu <chuansheng.liu@...el.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [RESEND PATCH 1/2] PM / sleep: print function name of callbacks

On Tue, Nov 01, 2016 at 05:27:05AM +0100, Rafael J. Wysocki wrote:
> Any reason why you need to rely on the initcall_debug stuff instead of using
> the tracepoints we have there (for exactly the reason why you are pushing this
> patch)?

This was mentioned on the last submission. I'll paste Doug's reply from
there:

"""
On Tue, Sep 22, 2015 at 10:33 AM, Brown, Len <len.brown@...el.com>
wrote:
> have you used analyze_suspend?
> It used to parse this output, but that was abandoned
> when it cut over to using ftrace directly.
>
> https://01.org/suspendresume

Ah, good to know about.  In my case this output is enabled on shipping
devices and sometimes we get back bug reports with these prints in the
log, so I'm interested in making the prints more useful.  :)

-Doug
"""

Perhaps I should have elabotated on the RESEND...

Or is there a really good way to make use of the tracepoints for
production systems, including for crash reports? We currently get the
kernel log from pstore, but I see ftrace support has been there for a
little while too. Still, it's awfully useful to have kernel prints and
warnings interleave with initcall_debug, and it wouldn't be quite as
easy to have to piece this together between kernel log + ftrace log.

Brian