linux-kernel - Re: Crash in msm serial on dragonboard with ftrace bootargs

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: <20181016134803.1b9260c1@gandalf.local.home>
Date:   Tue, 16 Oct 2018 13:48:03 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
Cc:     Stephen Boyd <sboyd@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Jiri Slaby <jslaby@...e.com>,
        "Ivan T. Ivanov" <ivan.ivanov@...aro.org>,
        Kees Cook <keescook@...omium.org>,
        "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        Geliang Tang <geliangtang@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Pramod Gurav <gpramod@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Vivek Gautam <vivek.gautam@...eaurora.org>,
        Sibi Sankar <sibis@...eaurora.org>
Subject: Re: Crash in msm serial on dragonboard with ftrace bootargs

On Tue, 16 Oct 2018 23:06:24 +0530
Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org> wrote:

> On 10/16/2018 10:27 PM, Steven Rostedt wrote:
> > 
> > OK, can you add to the command line:
> > 
> >   ftrace=function ftrace_filter=*schedule*
> > 
> > to see if it's a specific function that may be causing the issue (but
> > hopefully it's not one of the scheduling functions that caused it).
> >   
> 
> Target boots fine with this. So its not scheduling functions that is 
> causing it. Also I tried with ftrace_filter=*msm* just to be sure if
> tracing driver functions is causing any issue but its NOT.

OK, seems that something is being traced that shouldn't be.

When this happens after boot up, it's easy to bisect down to the
problem function. But since it's at boot up, it will take a lot longer.

I would suggest to start by going down the alphabet.

	ftrace_filter=a*
 	ftrace_filter=b*
	ftrace_filter=c*
	[...]

And at least find the letter the bad function starts with.

Note, it could be more than one function (I've had that a couple of
times), and to find that out, you can test with "ftrace_notrace". Say
you find that the problem function starts with 'x'. You can do:

	ftrace_notrace=x*

Which will trace all functions except those that start with an 'x', to
make sure it still boots.

Remember, you still need to have ftrace=function for all of this.

Once you find the letter of the function, you can try the next letter,
or perhaps come up with another method. I would say look at the
functions in /sys/kernel/debug/tracing/available_filter_functions, but
they don't list the init function (that can be traced). But you can
use /proc/kallsyms instead.

-- Steve