All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Joel Fernandes <joel@joelfernandes.org>,
	Kees Cook <keescook@chromium.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Andy Gross <andy.gross@linaro.org>,
	David Brown <david.brown@linaro.org>,
	Jiri Slaby <jslaby@suse.com>,
	"Ivan T. Ivanov" <ivan.ivanov@linaro.org>,
	Geliang Tang <geliangtang@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Pramod Gurav <gpramod@codeaurora.org>,
	linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
	"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	Vivek Gautam <vivek.gautam@codeaurora.org>,
	Sibi Sankar <sibis@codeaurora.org>
Subject: Re: Crash in msm serial on dragonboard with ftrace bootargs
Date: Wed, 17 Oct 2018 17:08:09 +0530	[thread overview]
Message-ID: <2a23cd74-7364-0fb7-3c7b-7be79a881073@codeaurora.org> (raw)
In-Reply-To: <20181017101355.GA230639@joelaf.mtv.corp.google.com>

On 10/17/2018 3:43 PM, Joel Fernandes wrote:
> Hi Kees,
> 
> On Tue, Oct 16, 2018 at 10:02:53AM -0700, Kees Cook wrote:
>> On Tue, Oct 16, 2018 at 8:29 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>> On Tue, 16 Oct 2018 17:08:25 +0530
>>> Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote:
>>>> One more thing is for pstore dmesg-ramoops, I had to change
>>>> late_initcall to postcore_initcall which brings the question as to why
>>>> we changed to late_initcall?
>>>> Simple git blame shows to support crypto compress api, but is it really
>>>> helpful? A lot of boottime issues can be caught with pstore enabled at
>>>> postcore_initcall rather than late_initcall, this backtrace
>>>> is just one example. Is there any way we could change this?
>>>
>>> Does it break if the crypto is not initialized? Perhaps add a command
>>> line flag to have it happen earlier:
>>>
>>>   ramoops=earlyinit
>>>
>>> and add a postcore_initcall that checks if that flag is set, and if so,
>>> it does the work then, and the late_initcall() will do nothing.
>>>
>>> That way, you can still have unmodified kernels use pstore when it
>>> crashes at boot up.
>>
>> Even better, if we could find a way to make it work with a late
>> initialization of compression (i.e. postcore_initcall() by default
>> means anything caught would be uncompressed, but anything after
>> late_initcall() would be compressed). I'd be very happy to review
>> patches for that!
> 
> What do you think about the (untested) patch below? It seems to me that it
> should solve the issue of missing early crash dumps, but I have not tested it
> yet. Sai, would you mind trying it out and let me know if you can see the
> early crash dumps properly now?
> 
> ----8<---
> From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> Subject: [RFC] pstore: allocate compression during late_initcall
> 
> ramoop's pstore registration (using pstore_register) has to run during
> late_initcall because crypto backend may not be ready during
> postcore_initcall. This causes missing of dmesg crash dumps which could
> have been caught by pstore.
> 
> Instead, lets allow ramoops pstore registration earlier, and once crypto
> is ready we can initialize the compression.
> 
> Reported-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
>   fs/pstore/platform.c | 13 +++++++++++++
>   fs/pstore/ram.c      |  2 +-
>   2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> index 15e99d5a681d..f09066db2d4d 100644
> --- a/fs/pstore/platform.c
> +++ b/fs/pstore/platform.c
> @@ -780,6 +780,19 @@ void __init pstore_choose_compression(void)
>   	}
>   }
>   
> +static int __init pstore_compression_late_init(void)
> +{
> +	/*
> +	 * Check if any pstore backends registered earlier but did not allocate
> +	 * for compression because crypto was not ready, if so then initialize
> +	 * compression.
> +	 */
> +	if (psinfo && !tfm)
> +		allocate_buf_for_compression();
> +	return 0;
> +}
> +late_initcall(pstore_compression_late_init);
> +
>   module_param(compress, charp, 0444);
>   MODULE_PARM_DESC(compress, "Pstore compression to use");
>   
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index bbd1e357c23d..98e48d1a9776 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -940,7 +940,7 @@ static int __init ramoops_init(void)
>   	ramoops_register_dummy();
>   	return platform_driver_register(&ramoops_driver);
>   }
> -late_initcall(ramoops_init);
> +postcore_initcall(ramoops_init);
>   
>   static void __exit ramoops_exit(void)
>   {
> 

Yes I could see the early crash dump. Also I tested with different 
compression (LZO) instead of deflate just to be sure and it works fine, 
thanks :)

Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>

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

  reply	other threads:[~2018-10-17 11:38 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-16 11:38 Crash in msm serial on dragonboard with ftrace bootargs Sai Prakash Ranjan
2018-10-16 11:44 ` Greg Kroah-Hartman
2018-10-16 11:58   ` Sai Prakash Ranjan
2018-10-16 15:29 ` Steven Rostedt
2018-10-16 16:35   ` Sai Prakash Ranjan
2018-10-16 16:57     ` Steven Rostedt
2018-10-16 17:36       ` Sai Prakash Ranjan
2018-10-16 17:48         ` Steven Rostedt
2018-10-16 18:05           ` Sai Prakash Ranjan
2018-10-16 18:16             ` Steven Rostedt
2018-10-16 18:25               ` Sai Prakash Ranjan
2018-10-16 18:41                 ` Steven Rostedt
2018-10-16 19:01                   ` Sai Prakash Ranjan
2018-10-16 19:03                     ` Steven Rostedt
2018-10-16 19:06                       ` Sai Prakash Ranjan
2018-10-16 19:15                         ` Steven Rostedt
2018-10-16 19:16                           ` Steven Rostedt
2018-10-16 19:37                             ` Sai Prakash Ranjan
2018-10-16 19:35                           ` Sai Prakash Ranjan
2018-10-16 20:51                             ` Stephen Boyd
2018-10-16 20:51                               ` Stephen Boyd
2018-10-17 11:27                               ` Sai Prakash Ranjan
2018-10-18  2:33                         ` Steven Rostedt
2018-10-18  5:21                           ` Sai Prakash Ranjan
2018-10-18 13:17                             ` Steven Rostedt
2018-10-19  4:17                               ` Joel Fernandes
2018-10-19  6:54                                 ` Sai Prakash Ranjan
2018-10-19 13:51                                   ` Steven Rostedt
2018-10-19 14:48                                     ` Sai Prakash Ranjan
2018-10-19 15:12                                       ` Steven Rostedt
2018-10-25 14:36                                         ` saiprakash.ranjan
2018-11-13  9:44                                           ` Srinivas Kandagatla
2018-11-15 10:33                                             ` Sai Prakash Ranjan
2018-11-15 10:53                                               ` Srinivas Kandagatla
2018-11-16  3:39                                                 ` Viresh Kumar
2018-11-16 10:49                                                   ` Sai Prakash Ranjan
2018-10-16 17:02   ` Kees Cook
2018-10-17 10:13     ` Joel Fernandes
2018-10-17 11:38       ` Sai Prakash Ranjan [this message]
2018-10-17 14:49         ` Sai Prakash Ranjan
2018-10-17 17:56           ` Joel Fernandes
2018-10-17 18:25             ` Kees Cook
2018-10-16 23:09 ` Joel Fernandes
2018-10-17 11:53   ` Sai Prakash Ranjan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2a23cd74-7364-0fb7-3c7b-7be79a881073@codeaurora.org \
    --to=saiprakash.ranjan@codeaurora.org \
    --cc=andy.gross@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=david.brown@linaro.org \
    --cc=geliangtang@gmail.com \
    --cc=gpramod@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ivan.ivanov@linaro.org \
    --cc=joel@joelfernandes.org \
    --cc=jslaby@suse.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=rnayak@codeaurora.org \
    --cc=rostedt@goodmis.org \
    --cc=sboyd@kernel.org \
    --cc=sibis@codeaurora.org \
    --cc=vivek.gautam@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.