Hi,
On Thu, Oct 18, 2018 at 11:56 AM Kees Cook keescook@chromium.org wrote:
From: "Joel Fernandes (Google)" joel@joelfernandes.org
ramoops's call of pstore_register() was recently moved to run during late_initcall() because the crypto backend may not have been ready during postcore_initcall(). This meant early-boot crash dumps were not getting caught by pstore any more.
Instead, lets allow calls to pstore_register() 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 Tested-by: Sai Prakash Ranjan saiprakash.ranjan@codeaurora.org Fixes: cb3bee0369bc ("pstore: Use crypto compress API") [kees: trivial rebase] Signed-off-by: Kees Cook keescook@chromium.org
fs/pstore/platform.c | 10 +++++++++- fs/pstore/ram.c | 2 +- 2 files changed, 10 insertions(+), 2 deletions(-)
I'd propose that these three patches:
95047b0519c1 pstore: Refactor compression initialization 416031653eb5 pstore: Allocate compression during late_initcall() cb095afd4476 pstore: Centralize init/exit routines
Get sent to linux-stable. Specifically I'll mention that 4.19 needs it. IMO the regression of pstore not catching early boot crashes is pretty serious IMO.
Thanks!
-Doug
On Fri, May 03, 2019 at 11:37:51AM -0700, Douglas Anderson wrote:
Hi,
On Thu, Oct 18, 2018 at 11:56 AM Kees Cook keescook@chromium.org wrote:
From: "Joel Fernandes (Google)" joel@joelfernandes.org
ramoops's call of pstore_register() was recently moved to run during late_initcall() because the crypto backend may not have been ready during postcore_initcall(). This meant early-boot crash dumps were not getting caught by pstore any more.
Instead, lets allow calls to pstore_register() 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 Tested-by: Sai Prakash Ranjan saiprakash.ranjan@codeaurora.org Fixes: cb3bee0369bc ("pstore: Use crypto compress API") [kees: trivial rebase] Signed-off-by: Kees Cook keescook@chromium.org
fs/pstore/platform.c | 10 +++++++++- fs/pstore/ram.c | 2 +- 2 files changed, 10 insertions(+), 2 deletions(-)
I'd propose that these three patches:
95047b0519c1 pstore: Refactor compression initialization 416031653eb5 pstore: Allocate compression during late_initcall() cb095afd4476 pstore: Centralize init/exit routines
Get sent to linux-stable. Specifically I'll mention that 4.19 needs it. IMO the regression of pstore not catching early boot crashes is pretty serious IMO.
So just those 3 commits and not this specific patch from Joel?
thanks,
greg k-h
Hi,
On Sun, May 5, 2019 at 6:16 AM Greg KH gregkh@linuxfoundation.org wrote:
On Fri, May 03, 2019 at 11:37:51AM -0700, Douglas Anderson wrote:
Hi,
On Thu, Oct 18, 2018 at 11:56 AM Kees Cook keescook@chromium.org wrote:
From: "Joel Fernandes (Google)" joel@joelfernandes.org
ramoops's call of pstore_register() was recently moved to run during late_initcall() because the crypto backend may not have been ready during postcore_initcall(). This meant early-boot crash dumps were not getting caught by pstore any more.
Instead, lets allow calls to pstore_register() 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 Tested-by: Sai Prakash Ranjan saiprakash.ranjan@codeaurora.org Fixes: cb3bee0369bc ("pstore: Use crypto compress API") [kees: trivial rebase] Signed-off-by: Kees Cook keescook@chromium.org
fs/pstore/platform.c | 10 +++++++++- fs/pstore/ram.c | 2 +- 2 files changed, 10 insertions(+), 2 deletions(-)
I'd propose that these three patches:
95047b0519c1 pstore: Refactor compression initialization 416031653eb5 pstore: Allocate compression during late_initcall() cb095afd4476 pstore: Centralize init/exit routines
Get sent to linux-stable. Specifically I'll mention that 4.19 needs it. IMO the regression of pstore not catching early boot crashes is pretty serious IMO.
So just those 3 commits and not this specific patch from Joel?
The middle commit ("pstore: Allocate compression during late_initcall()") is ${SUBJECT} patch and the one with the "Fixes" tag.
The first commit ("pstore: Centralize init/exit routines") is needed to apply the middle commit.
I haven't done lots of analysis but the last commit ("pstore: Refactor compression initialization") sure looks like it's important if you have the middle commit. Specifically the middle commit allocates the compression earlier and the last commit says that it improves handling of this situation.
Unless someone thinks otherwise, it seems best to apply all 3?
-Doug
On Mon, May 6, 2019 at 8:16 AM Doug Anderson dianders@chromium.org wrote:
On Sun, May 5, 2019 at 6:16 AM Greg KH gregkh@linuxfoundation.org wrote:
On Fri, May 03, 2019 at 11:37:51AM -0700, Douglas Anderson wrote:
On Thu, Oct 18, 2018 at 11:56 AM Kees Cook keescook@chromium.org wrote:
From: "Joel Fernandes (Google)" joel@joelfernandes.org
ramoops's call of pstore_register() was recently moved to run during late_initcall() because the crypto backend may not have been ready during postcore_initcall(). This meant early-boot crash dumps were not getting caught by pstore any more.
Instead, lets allow calls to pstore_register() 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 Tested-by: Sai Prakash Ranjan saiprakash.ranjan@codeaurora.org Fixes: cb3bee0369bc ("pstore: Use crypto compress API") [kees: trivial rebase] Signed-off-by: Kees Cook keescook@chromium.org
fs/pstore/platform.c | 10 +++++++++- fs/pstore/ram.c | 2 +- 2 files changed, 10 insertions(+), 2 deletions(-)
I'd propose that these three patches:
95047b0519c1 pstore: Refactor compression initialization 416031653eb5 pstore: Allocate compression during late_initcall() cb095afd4476 pstore: Centralize init/exit routines
Get sent to linux-stable. Specifically I'll mention that 4.19 needs it. IMO the regression of pstore not catching early boot crashes is pretty serious IMO.
So just those 3 commits and not this specific patch from Joel?
The middle commit ("pstore: Allocate compression during late_initcall()") is ${SUBJECT} patch and the one with the "Fixes" tag.
The first commit ("pstore: Centralize init/exit routines") is needed to apply the middle commit.
I haven't done lots of analysis but the last commit ("pstore: Refactor compression initialization") sure looks like it's important if you have the middle commit. Specifically the middle commit allocates the compression earlier and the last commit says that it improves handling of this situation.
Unless someone thinks otherwise, it seems best to apply all 3?
At first glance, yes, but let me double-check it this morning. There were some subtle changes that made me not initially want to backport these, but it should be doable. :)
Doug said:
I'd propose that these three patches:
95047b0519c1 pstore: Refactor compression initialization 416031653eb5 pstore: Allocate compression during late_initcall() cb095afd4476 pstore: Centralize init/exit routines
Okay, confirmed. These look sufficient to me, and the resulting tree passes my pstore tests. Greg, can you please pull these into 4.19?
Thanks!
On Mon, May 06, 2019 at 09:05:12AM -0700, Kees Cook wrote:
Doug said:
I'd propose that these three patches:
95047b0519c1 pstore: Refactor compression initialization 416031653eb5 pstore: Allocate compression during late_initcall() cb095afd4476 pstore: Centralize init/exit routines
Okay, confirmed. These look sufficient to me, and the resulting tree passes my pstore tests. Greg, can you please pull these into 4.19?
All now queued up, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org
-
Doug Anderson -
Douglas Anderson
-
Greg KH -
Kees Cook