Also, FWIW, this patch seems to keep things from crashing, since it skips registering console and a few other things. Obviously not real great, but it does get us some kernel logs I think, without a few of the other fancy features:

---

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 8a9b48271367..0cebc767bdd3 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -591,6 +591,7 @@ static int ramoops_probe(struct platform_device *pdev)
 		goto fail_clear;
 	}
 
+	cxt->pstore.flags |= PSTORE_FLAGS_FRAGILE;
 	err = pstore_register(&cxt->pstore);
 	if (err) {
 		pr_err("registering with pstore failed\n");

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dfd46d99697e6ca32acfcdf8b363c267d405ca52

commit dfd46d99697e6ca32acfcdf8b363c267d405ca52
Author: Varun Wadekar <vwadekar@nvidia.com>
Date: Mon Sep 03 06:57:28 2012

CHROMIUM: persistent_ram: remove atomic operations

The atomic operations (LDREX/STREX) to handle a buffer's start pointer
and size do not seem to work well on Logan.  The ldrex/strex instruction
always work on ARM when using the cache.  However, if the cache is
disabled then the instructions are dependent on SoC support.

Cherry picked from android-tegra-3.10 commit:
eae036b44aea75669573f1bfef953ac6bc9205f2

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Suggested by: Colin Cross <ccross@android.com>

Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Signed-off-by: Johnny Qiu <joqiu@nvidia.com>
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193220
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>

[benzh: 3.14 rebase. Upstream has added a spinlock version of
buffer_start_add/buffer_size_add. Instread of implementing our own
compare_and_exchange, just use the upstream version. This patch removes
atomic operations and ensures the spinlock version of the funcions
are always used.]
Signed-off-by: Ben Zhang <benzh@chromium.org>

[groeck: cherry-pick into chromeos-4.4.
 Problem has been observed on rk3288 and rk3399.
 Note for rebase to later kernels: do not remove unless underlying
 problem (see description above) has been fixed upstream.]
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: I4b275e854a4d1d563139d63aefd4acaecf8cc00a
Reviewed-on: https://chromium-review.googlesource.com/370300
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>

[modify] https://crrev.com/dfd46d99697e6ca32acfcdf8b363c267d405ca52/fs/pstore/ram_core.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/be4c2852d29101b76adaa9c964173addaaa5a63c

commit be4c2852d29101b76adaa9c964173addaaa5a63c
Author: Wiebe, Wladislav (Nokia - DE/Ulm) <wladislav.wiebe@nokia.com>
Date: Sat Feb 11 01:00:28 2017

UPSTREAM: pstore: Add support for 64 Bit address space

Some architectures have their reserved RAM in 64 Bit address space.
Therefore convert mem_address module parameter to ullong.

Signed-off-by: Wladislav Wiebe <wladislav.wiebe@nokia.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tony Luck <tony.luck@intel.com>

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

(cherry picked from commit 764fd639d794a1c0b0d203b19d1bef0451c23fb1)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: If597fc2530b9c28af48760fabe33d81c14dfbc89
Reviewed-on: https://chromium-review.googlesource.com/396604
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/be4c2852d29101b76adaa9c964173addaaa5a63c/include/linux/pstore_ram.h
[modify] https://crrev.com/be4c2852d29101b76adaa9c964173addaaa5a63c/fs/pstore/ram.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5bde842b1b2627695997c23b8856aac4947def8b

commit 5bde842b1b2627695997c23b8856aac4947def8b
Author: Kees Cook <keescook@chromium.org>
Date: Sat Feb 11 01:00:29 2017

UPSTREAM: ramoops: Only unregister when registered

While none of the "fragile" pstore backends unregister yet, if they
ever did, the unregistering code for the non-dump targets might get
confused. This adds a check for fragile backends on unregister.

Signed-off-by: Kees Cook <keescook@chromium.org>

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

(cherry picked from commit a1db8060f5c85e33ed810038036f409eed15decc)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: Ia10e5e752042b02f78df6045f5a706ffeeb4cfe5
Reviewed-on: https://chromium-review.googlesource.com/396605
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/5bde842b1b2627695997c23b8856aac4947def8b/fs/pstore/platform.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7aaf88538c22ab7673b7feb07e584cd7f28b38db

commit 7aaf88538c22ab7673b7feb07e584cd7f28b38db
Author: Namhyung Kim <namhyung@kernel.org>
Date: Sat Feb 11 01:00:30 2017

UPSTREAM: pstore: Enable compression on normal path (again)

The commit f0e2efcfd2717 ("pstore: do not use message compression
without lock") added a check to 'is_locked' to avoid breakage in
concurrent accesses.  But it has a side-effect of disabling compression
on normal path since 'is_locked' variable is not set.  As normal path
always takes the lock, it should be initialized to 1.

This also makes the unlock code a bit simpler.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

(cherry picked from commit 98e44fda2ea19c0e8b0a2e0e4dcd3461251f09ea)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: Ibaa36d291ba04ec4b484e42617fec64ad1672e6d
Reviewed-on: https://chromium-review.googlesource.com/396606
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/7aaf88538c22ab7673b7feb07e584cd7f28b38db/fs/pstore/platform.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9f18b4fe6756c9e843d18f8de01600d824a04a90

commit 9f18b4fe6756c9e843d18f8de01600d824a04a90
Author: Namhyung Kim <namhyung@kernel.org>
Date: Sat Feb 11 01:00:31 2017

UPSTREAM: pstore: Cleanup pstore_dump()

The code is duplicate between compression is enabled or not.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

(cherry picked from commit 235f6d157d43a761052e643b8799f86fdc87b47f)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: I3fb879c13f2b76e36b8c1c6dcf31720bde40ba2e
Reviewed-on: https://chromium-review.googlesource.com/396607
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/9f18b4fe6756c9e843d18f8de01600d824a04a90/fs/pstore/platform.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9847ea3243828e5b19454003f2ae1084b8455cfd

commit 9847ea3243828e5b19454003f2ae1084b8455cfd
Author: Geliang Tang <geliangtang@163.com>
Date: Sat Feb 11 01:00:32 2017

UPSTREAM: pstore: add lzo/lz4 compression support

Like zlib compression in pstore, this patch added lzo and lz4
compression support so that users can have more options and better
compression ratio.

The original code treats the compressed data together with the
uncompressed ECC correction notice by using zlib decompress. The
ECC correction notice is missing in the decompression process. The
treatment also makes lzo and lz4 not working. So I treat them
separately by using pstore_decompress() to treat the compressed
data, and memcpy() to treat the uncompressed ECC correction notice.

Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Kees Cook <keescook@chromium.org>

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

(cherry picked from commit 8cfc8ddc99df9509a46043b14af81f5c6a223eab)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: I5e5b87d5b164eebc051a1d113a01b4b6abc5367d
Reviewed-on: https://chromium-review.googlesource.com/396608
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/9847ea3243828e5b19454003f2ae1084b8455cfd/arch/powerpc/kernel/nvram_64.c
[modify] https://crrev.com/9847ea3243828e5b19454003f2ae1084b8455cfd/include/linux/pstore.h
[modify] https://crrev.com/9847ea3243828e5b19454003f2ae1084b8455cfd/fs/pstore/platform.c
[modify] https://crrev.com/9847ea3243828e5b19454003f2ae1084b8455cfd/drivers/firmware/efi/efi-pstore.c
[modify] https://crrev.com/9847ea3243828e5b19454003f2ae1084b8455cfd/fs/pstore/Kconfig
[modify] https://crrev.com/9847ea3243828e5b19454003f2ae1084b8455cfd/fs/pstore/ram.c
[modify] https://crrev.com/9847ea3243828e5b19454003f2ae1084b8455cfd/drivers/acpi/apei/erst.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0c11204af0ba977d89052fe7cdf326127edfb67b

commit 0c11204af0ba977d89052fe7cdf326127edfb67b
Author: Hiraku Toyooka <hiraku.toyooka.gu@hitachi.com>
Date: Sat Feb 11 01:00:33 2017

UPSTREAM: ramoops: use persistent_ram_free() instead of kfree() for freeing prz

persistent_ram_zone(=prz) structures are allocated by persistent_ram_new(),
which includes vmap() or ioremap(). But they are currently freed by
kfree(). This uses persistent_ram_free() for correct this asymmetry usage.

Signed-off-by: Hiraku Toyooka <hiraku.toyooka.gu@hitachi.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.kw@hitachi.com>
Cc: Mark Salyzyn <salyzyn@android.com>
Cc: Seiji Aguchi <seiji.aguchi.tr@hitachi.com>
Signed-off-by: Kees Cook <keescook@chromium.org>

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

(cherry picked from commit e976e56423dc1cc01686861fc3e0c6c0ec8cd8b7)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: Ie3d42c1012de61d1d0401adaed800c1ff63ac9bf
Reviewed-on: https://chromium-review.googlesource.com/396610
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/0c11204af0ba977d89052fe7cdf326127edfb67b/fs/pstore/ram.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4ae78f0b96388e519e66a6c0e4912d73e826d74b

commit 4ae78f0b96388e519e66a6c0e4912d73e826d74b
Author: Namhyung Kim <namhyung@kernel.org>
Date: Sat Feb 11 06:37:21 2017

UPSTREAM: pstore: Split pstore fragile flags

This patch adds new PSTORE_FLAGS for each pstore type so that they can
be enabled separately.  This is a preparation for ongoing virtio-pstore
work to support those types flexibly.

The PSTORE_FLAGS_FRAGILE is changed to PSTORE_FLAGS_DMESG to preserve the
original behavior.

Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: linux-acpi@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
[kees: retained "FRAGILE" for now to make merges easier]
Signed-off-by: Kees Cook <keescook@chromium.org>

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

(cherry picked from commit c950fd6f201aea649932898206a850f0a7f25603)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: I65de743c80e7958436d65e0c747222c3506401a7
Reviewed-on: https://chromium-review.googlesource.com/396460
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/4ae78f0b96388e519e66a6c0e4912d73e826d74b/drivers/firmware/efi/efi-pstore.c
[modify] https://crrev.com/4ae78f0b96388e519e66a6c0e4912d73e826d74b/fs/pstore/ram.c
[modify] https://crrev.com/4ae78f0b96388e519e66a6c0e4912d73e826d74b/drivers/acpi/apei/erst.c
[modify] https://crrev.com/4ae78f0b96388e519e66a6c0e4912d73e826d74b/fs/pstore/platform.c
[modify] https://crrev.com/4ae78f0b96388e519e66a6c0e4912d73e826d74b/include/linux/pstore.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/51180ce466d9dcc72b111268dc17b174c6a95aad

commit 51180ce466d9dcc72b111268dc17b174c6a95aad
Author: Namhyung Kim <namhyung@kernel.org>
Date: Sat Feb 11 06:37:22 2017

UPSTREAM: pstore/ram: Set pstore flags dynamically

The ramoops can be configured to enable each pstore type by setting
their size.  In that case, it'd be better not to register disabled types
in the first place.

Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

(cherry picked from commit 79d955af711a6e20207783590a2cfddbd649568b)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: If5f6594d79bb48080a2065584aba1ceba7ad6aa2
Reviewed-on: https://chromium-review.googlesource.com/396461
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/51180ce466d9dcc72b111268dc17b174c6a95aad/fs/pstore/ram.c
[modify] https://crrev.com/51180ce466d9dcc72b111268dc17b174c6a95aad/include/linux/pstore.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/820f8655911f79c2e1421e7aa02adba384780539

commit 820f8655911f79c2e1421e7aa02adba384780539
Author: Geliang Tang <geliangtang@gmail.com>
Date: Sat Feb 11 06:37:19 2017

UPSTREAM: ramoops: move spin_lock_init after kmalloc error checking

If cxt->pstore.buf allocated failed, no need to initialize
cxt->pstore.buf_lock. So this patch moves spin_lock_init() after the
error checking.

Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

(cherry picked from commit f88baf68ebe5b2efced64725fd98548af9b8f510)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: Ifebb1dd031fe0d96952c9a6af50f69b2d0a5432a
Reviewed-on: https://chromium-review.googlesource.com/396611
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/820f8655911f79c2e1421e7aa02adba384780539/fs/pstore/ram.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7a961092959634c3ff93346afed65c1340bd04ce

commit 7a961092959634c3ff93346afed65c1340bd04ce
Author: Mark Salyzyn <salyzyn@android.com>
Date: Sat Feb 11 06:37:20 2017

UPSTREAM: pstore/pmsg: drop bounce buffer

Removing a bounce buffer copy operation in the pmsg driver path is
always better. We also gain in overall performance by not requesting
a vmalloc on every write as this can cause precious RT tasks, such
as user facing media operation, to stall while memory is being
reclaimed. Added a write_buf_user to the pstore functions, a backup
platform write_buf_user that uses the small buffer that is part of
the instance, and implemented a ramoops write_buf_user that only
supports PSTORE_TYPE_PMSG.

Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Signed-off-by: Kees Cook <keescook@chromium.org>

BUG=chrome-os-partner:56109,  chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

(cherry picked from commit 5bf6d1b92715f224ef6e1c3abca5dd63eeb4915d)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: I87b7269272ceb7602eaeb65d8acc45ec71625b86
Reviewed-on: https://chromium-review.googlesource.com/396612
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/7a961092959634c3ff93346afed65c1340bd04ce/fs/pstore/ram_core.c
[modify] https://crrev.com/7a961092959634c3ff93346afed65c1340bd04ce/fs/pstore/platform.c
[modify] https://crrev.com/7a961092959634c3ff93346afed65c1340bd04ce/fs/pstore/pmsg.c
[modify] https://crrev.com/7a961092959634c3ff93346afed65c1340bd04ce/include/linux/pstore_ram.h
[modify] https://crrev.com/7a961092959634c3ff93346afed65c1340bd04ce/fs/pstore/ram.c
[modify] https://crrev.com/7a961092959634c3ff93346afed65c1340bd04ce/include/linux/pstore.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/559c39a2b8dd5a2bf4cff5a85278085db6527cdc

commit 559c39a2b8dd5a2bf4cff5a85278085db6527cdc
Author: Joel Fernandes <joelaf@google.com>
Date: Sat Feb 11 06:37:24 2017

UPSTREAM: pstore: Make spinlock per zone instead of global

Currently pstore has a global spinlock for all zones. Since the zones
are independent and modify different areas of memory, there's no need
to have a global lock, so we should use a per-zone lock as introduced
here. Also, when ramoops's ftrace use-case has a FTRACE_PER_CPU flag
introduced later, which splits the ftrace memory area into a single zone
per CPU, it will eliminate the need for locking. In preparation for this,
make the locking optional.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: I0e6908fadc2bcda1900c08f2049eee05645b3a3e
Signed-off-by: Joel Fernandes <joelaf@google.com>
[kees: updated commit message]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 109704492ef6)
Reviewed-on: https://chromium-review.googlesource.com/440546

[modify] https://crrev.com/559c39a2b8dd5a2bf4cff5a85278085db6527cdc/include/linux/pstore_ram.h
[modify] https://crrev.com/559c39a2b8dd5a2bf4cff5a85278085db6527cdc/fs/pstore/ram_core.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2220d0e6c5e1701a7c76269526fd899a5402dffe

commit 2220d0e6c5e1701a7c76269526fd899a5402dffe
Author: Li Pengcheng <lipengcheng8@huawei.com>
Date: Sat Feb 11 06:37:23 2017

UPSTREAM: pstore: Actually give up during locking failure

Without a return after the pr_err(), dumps will collide when two threads
call pstore_dump() at the same time.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: I07cecf37d20271e153af47056db461bbf05a10d3
Signed-off-by: Liu Hailong <liuhailong5@huawei.com>
Signed-off-by: Li Pengcheng <lipengcheng8@huawei.com>
Signed-off-by: Li Zhong <lizhong11@hisilicon.com>
[kees: improved commit message]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 959217c84c27)
Reviewed-on: https://chromium-review.googlesource.com/440545

[modify] https://crrev.com/2220d0e6c5e1701a7c76269526fd899a5402dffe/fs/pstore/platform.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c3b5e6427474e749867ecb46537423723cb6a82b

commit c3b5e6427474e749867ecb46537423723cb6a82b
Author: Joel Fernandes <joelaf@google.com>
Date: Sat Feb 11 06:37:25 2017

UPSTREAM: pstore: Warn on PSTORE_TYPE_PMSG using deprecated function

PMSG now uses ramoops_pstore_write_buf_user() instead of ...write_buf().
Print a ratelimited warning if gets accidentally called.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: Ia9e4ddacce1596afe2e249661530f608e46adccf
Signed-off-by: Joel Fernandes <joelaf@google.com>
[kees: adjusted commit log and added -EINVAL return]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit d8991f51e55f)
Reviewed-on: https://chromium-review.googlesource.com/440547

[modify] https://crrev.com/c3b5e6427474e749867ecb46537423723cb6a82b/fs/pstore/ram.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/530f9b08659726b98ce8e9e7208eba34a53eaafa

commit 530f9b08659726b98ce8e9e7208eba34a53eaafa
Author: Joel Fernandes <joelaf@google.com>
Date: Sat Feb 11 06:37:26 2017

UPSTREAM: pstore: Allow prz to control need for locking

In preparation of not locking at all for certain buffers depending on if
there's contention, make locking optional depending on the initialization
of the prz.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: I2640cf4acf019b4c00ef99e07033dc2eb95e3d4e
Signed-off-by: Joel Fernandes <joelaf@google.com>
[kees: moved locking flag into prz instead of via caller arguments]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 663deb47880f)
Reviewed-on: https://chromium-review.googlesource.com/440548

[modify] https://crrev.com/530f9b08659726b98ce8e9e7208eba34a53eaafa/include/linux/pstore_ram.h
[modify] https://crrev.com/530f9b08659726b98ce8e9e7208eba34a53eaafa/fs/pstore/ram.c
[modify] https://crrev.com/530f9b08659726b98ce8e9e7208eba34a53eaafa/fs/pstore/ram_core.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2676e634bb7698b085818128a7bd57dad91af9ad

commit 2676e634bb7698b085818128a7bd57dad91af9ad
Author: Kees Cook <keescook@chromium.org>
Date: Sat Feb 11 06:37:27 2017

UPSTREAM: pstore: Make ramoops_init_przs generic for other prz arrays

Currently ramoops_init_przs() is hard wired only for panic dump zone
array. In preparation for the ftrace zone array (one zone per-cpu) and pmsg
zone array, make the function more generic to be able to handle this case.

Heavily based on similar work from Joel Fernandes.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: I572585f09b64ab8a69f53e8aeafa6b4149065822
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit de83209249d6)
Reviewed-on: https://chromium-review.googlesource.com/440549

[modify] https://crrev.com/2676e634bb7698b085818128a7bd57dad91af9ad/fs/pstore/ram.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/892e43b9766c8d9292de4e867e27978d2a779407

commit 892e43b9766c8d9292de4e867e27978d2a779407
Author: Kefeng Wang <wangkefeng.wang@huawei.com>
Date: Sat Feb 11 06:37:29 2017

UPSTREAM: of/platform: Add common method to populate default bus

The arch code calls of_platform_populate() with default match table
when it wants to populate default bus.

This patch introduce a new of_platform_default_populate_init() and make it
arch_initcall_sync(it should be later than some iommu configration, eg,
of_iommu_init() and swiotlb_late_init in arm64), then we can finish above
job in common method.

In order to avoid the default bus being populated twice, simply checking
the flag of bus node whether has be set OF_POPULATED_BUS or not.

After that, we can safely remove the caller in arch code.

Btw, add debug print in of_platform_populate(), and use __func__ to
print function's name of of_platform_bus_create().

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: Ib2ae98f376c99f58331ea98bf7e51d1d2191bd79
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 44a7185c2ae63)
Reviewed-on: https://chromium-review.googlesource.com/440550
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/892e43b9766c8d9292de4e867e27978d2a779407/drivers/of/platform.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7a3f25d55a931aa715cb28582e87e383bc3771cb

commit 7a3f25d55a931aa715cb28582e87e383bc3771cb
Author: Greg Hackmann <ghackmann@google.com>
Date: Sat Feb 11 08:34:57 2017

BACKPORT: pstore/ram: add Device Tree bindings

ramoops is one of the remaining places where ARM vendors still rely on
board-specific shims.  Device Tree lets us replace those shims with
generic code.

These bindings mirror the ramoops module parameters, with two small
differences:

(1) dump_oops becomes an optional "no-dump-oops" property, since ramoops
    sets dump_oops=1 by default.

(2) mem_type=1 becomes the more self-explanatory "unbuffered" property.

Signed-off-by: Greg Hackmann <ghackmann@google.com>
[fixed platform_get_drvdata() crash, thanks to Brian Norris]
[switched from u64 to u32 to simplify code, various whitespace fixes]
[use dev_of_node() to gain code-elimination for CONFIG_OF=n]
Signed-off-by: Kees Cook <keescook@chromium.org>
[backport: resolve conflicts; retain backwards compatibility for legacy
 chromebooks]
BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru
CQ-DEPEND=CL:440561

Change-Id: Ibcc88805ae6803b3b38a5a8f8f2a96294b136c41
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 35da60941e44d)
Reviewed-on: https://chromium-review.googlesource.com/440551
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/7a3f25d55a931aa715cb28582e87e383bc3771cb/Documentation/ramoops.txt
[modify] https://crrev.com/7a3f25d55a931aa715cb28582e87e383bc3771cb/fs/pstore/ram.c
[add] https://crrev.com/7a3f25d55a931aa715cb28582e87e383bc3771cb/Documentation/devicetree/bindings/misc/ramoops.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5c78b5bc60c59f9a3623bd50a07f0ea51ee84248

commit 5c78b5bc60c59f9a3623bd50a07f0ea51ee84248
Author: Kees Cook <keescook@chromium.org>
Date: Sat Feb 11 08:34:58 2017

BACKPORT: ramoops: use DT reserved-memory bindings

Instead of a ramoops-specific node, use a child node of /reserved-memory.
This requires that of_platform_device_create() be explicitly called
for the node, though, since "/reserved-memory" does not have its own
"compatible" property.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: I065ced6efe6eb459f835e582c08809a2e3d686fb
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
[backport: Compatibility bindings for the most part no longer necessary]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 529182e204db083cb7bda832d1c5c6d9278ba1cb)
Reviewed-on: https://chromium-review.googlesource.com/440552

[modify] https://crrev.com/5c78b5bc60c59f9a3623bd50a07f0ea51ee84248/Documentation/ramoops.txt
[modify] https://crrev.com/5c78b5bc60c59f9a3623bd50a07f0ea51ee84248/drivers/of/platform.c
[modify] https://crrev.com/5c78b5bc60c59f9a3623bd50a07f0ea51ee84248/fs/pstore/ram.c
[rename] https://crrev.com/5c78b5bc60c59f9a3623bd50a07f0ea51ee84248/Documentation/devicetree/bindings/reserved-memory/ramoops.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f181f7a0417ac612e2e0ef352962c0cc82642116

commit f181f7a0417ac612e2e0ef352962c0cc82642116
Author: Joel Fernandes <joelaf@google.com>
Date: Sat Feb 11 08:34:59 2017

UPSTREAM: ramoops: Split ftrace buffer space into per-CPU zones

If the RAMOOPS_FLAG_FTRACE_PER_CPU flag is passed to ramoops pdata, split
the ftrace space into multiple zones depending on the number of CPUs.

This speeds up the performance of function tracing by about 280% in my
tests as we avoid the locking. The trade off being lesser space available
per CPU. Let the ramoops user decide which option they want based on pdata
flag.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: I7b1e3f137c0903df09cb38a472c110b4c745ce87
Signed-off-by: Joel Fernandes <joelaf@google.com>
[kees: added max_ftrace_cnt to track size, added DT logic and docs]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit a1cf53ac6d15)
Reviewed-on: https://chromium-review.googlesource.com/440553

[modify] https://crrev.com/f181f7a0417ac612e2e0ef352962c0cc82642116/include/linux/pstore_ram.h
[modify] https://crrev.com/f181f7a0417ac612e2e0ef352962c0cc82642116/fs/pstore/ram.c
[modify] https://crrev.com/f181f7a0417ac612e2e0ef352962c0cc82642116/Documentation/devicetree/bindings/reserved-memory/ramoops.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4a6fdaccc4f93472407b935c5d45329e757bfb7e

commit 4a6fdaccc4f93472407b935c5d45329e757bfb7e
Author: Joel Fernandes <joelaf@google.com>
Date: Sat Feb 11 08:35:00 2017

UPSTREAM: pstore: Add ftrace timestamp counter

In preparation for merging the per CPU buffers into one buffer when
we retrieve the pstore ftrace data, we store the timestamp as a
counter in the ftrace pstore record.  We store the CPU number as well
if !PSTORE_CPU_IN_IP, in this case we shift the counter and may lose
ordering there but we preserve the same record size. The timestamp counter
is also racy, and not doing any locking or synchronization here results
in the benefit of lower overhead. Since we don't care much here for exact
ordering of function traces across CPUs, we don't synchronize and may lose
some counter updates but I'm ok with that.

Using trace_clock() results in much lower performance so avoid using it
since we don't want accuracy in timestamp and need a rough ordering to
perform merge.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: I571825820057821443e8580ebc9f3868b105d4b1
Signed-off-by: Joel Fernandes <joelaf@google.com>
[kees: updated commit message, added comments]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit fbccdeb8d77d)
Reviewed-on: https://chromium-review.googlesource.com/440554

[modify] https://crrev.com/4a6fdaccc4f93472407b935c5d45329e757bfb7e/fs/pstore/internal.h
[modify] https://crrev.com/4a6fdaccc4f93472407b935c5d45329e757bfb7e/fs/pstore/inode.c
[modify] https://crrev.com/4a6fdaccc4f93472407b935c5d45329e757bfb7e/fs/pstore/ftrace.c
[modify] https://crrev.com/4a6fdaccc4f93472407b935c5d45329e757bfb7e/include/linux/pstore.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/54671a6cdf0d947bf11f5ca792f0127f73bed34a

commit 54671a6cdf0d947bf11f5ca792f0127f73bed34a
Author: Joel Fernandes <joelaf@google.com>
Date: Sat Feb 11 08:35:01 2017

UPSTREAM: pstore: Merge per-CPU ftrace records into one

Up until this patch, each of the per CPU ftrace buffers appear as a
separate ftrace-ramoops-N file. In this patch we merge all the zones into
one and populate a single ftrace-ramoops-0 file.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: I3ec74575a52895364ab165c688649cae6a8330b3
Signed-off-by: Joel Fernandes <joelaf@google.com>
[kees: clarified variables names, added -ENOMEM handling]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 2fbea82bbb89)
Reviewed-on: https://chromium-review.googlesource.com/440555

[modify] https://crrev.com/54671a6cdf0d947bf11f5ca792f0127f73bed34a/fs/pstore/ram.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5cd356d010b3b095d7ad9cea44650e32875217ef

commit 5cd356d010b3b095d7ad9cea44650e32875217ef
Author: Kees Cook <keescook@chromium.org>
Date: Sat Feb 11 08:35:02 2017

UPSTREAM: pstore: improve error report for failed setup

When setting ramoops record sizes, sometimes it's not clear which
parameters contributed to the allocation failure. This adds a per-zone
name and expands the failure reports.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: Idfbadb49ccef5a5fe0249abbf165c8297cc11c3f
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit c443a5f3f1f1)
Reviewed-on: https://chromium-review.googlesource.com/440556

[modify] https://crrev.com/5cd356d010b3b095d7ad9cea44650e32875217ef/fs/pstore/ram.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/eeaafbcd6d82949a5a45b81a00076fdcab7b2fc3

commit eeaafbcd6d82949a5a45b81a00076fdcab7b2fc3
Author: Kees Cook <keescook@chromium.org>
Date: Sat Feb 11 08:35:03 2017

UPSTREAM: pstore: Clarify context field przs as dprzs

Since "przs" (persistent ram zones) is a general name in the code now, so
rename the Oops-dump zones to dprzs from przs.

Based on a patch from Nobuhiro Iwamatsu.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: I4dc561d06872d9e785760233cac3bde7f0688b7c
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit a5d23b956cab)
Reviewed-on: https://chromium-review.googlesource.com/440557

[modify] https://crrev.com/eeaafbcd6d82949a5a45b81a00076fdcab7b2fc3/fs/pstore/ram.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c824ceb13d5cd9ce1b99b4284982cab4b7841f69

commit c824ceb13d5cd9ce1b99b4284982cab4b7841f69
Author: Joel Fernandes <joelaf@google.com>
Date: Sat Feb 11 08:35:05 2017

UPSTREAM: pstore: Use global ftrace filters for function trace filtering

Currently, pstore doesn't have any filters setup for function tracing.
This has the associated overhead and may not be useful for users looking
for tracing specific set of functions.

ftrace's regular function trace filtering is done writing to
tracing/set_ftrace_filter however this is not available if not requested.
In order to be able to use this feature, the support to request global
filtering introduced earlier in the series should be requested before
registering the ftrace ops. Here we do the same.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: Ic000a7d4a4f598777cdfa707cacfe84ccbc8c653
Signed-off-by: Joel Fernandes <joelaf@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 7a0032f50472)
Reviewed-on: https://chromium-review.googlesource.com/440558

[modify] https://crrev.com/c824ceb13d5cd9ce1b99b4284982cab4b7841f69/fs/pstore/ftrace.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0afa95eb87393594f5eaccd839fc8699c0c6ab1a

commit 0afa95eb87393594f5eaccd839fc8699c0c6ab1a
Author: Namhyung Kim <namhyung@kernel.org>
Date: Sat Feb 11 08:35:06 2017

UPSTREAM: pstore: Protect unlink with read_mutex

When update_ms is set, pstore_get_records() will be called when there's
a new entry.  But unlink can be called at the same time and might
contend with the open-read-close loop.  Depending on the implementation
of platform driver, it may be safe or not.  But I think it'd be better
to protect those race in the first place.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: Ia43802d9f33d81aa2ef5a89bb465f44373fd92a6
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit e9e360b08a44)
Reviewed-on: https://chromium-review.googlesource.com/440559

[modify] https://crrev.com/0afa95eb87393594f5eaccd839fc8699c0c6ab1a/fs/pstore/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/18762ce0e414d10865e7f2a209d3e54d57141910

commit 18762ce0e414d10865e7f2a209d3e54d57141910
Author: Namhyung Kim <namhyung@kernel.org>
Date: Sat Feb 11 08:35:08 2017

UPSTREAM: pstore: Convert console write to use ->write_buf

Maybe I'm missing something, but I don't know why it needs to copy the
input buffer to psinfo->buf and then write.  Instead we can write the
input buffer directly.  The only implementation that supports console
message (i.e. ramoops) already does it for ftrace messages.

For the upcoming virtio backend driver, it needs to protect psinfo->buf
overwritten from console messages.  If it could use ->write_buf method
instead of ->write, the problem will be solved easily.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: Ib5fa9ae794aed4ae3a053ccc3159ee4e09c3a03a
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 70ad35db3321)
Reviewed-on: https://chromium-review.googlesource.com/440560

[modify] https://crrev.com/18762ce0e414d10865e7f2a209d3e54d57141910/fs/pstore/platform.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/be37f7d9483c7f62a699e6a28010ff822a2b43cd

commit be37f7d9483c7f62a699e6a28010ff822a2b43cd
Author: Brian Norris <briannorris@chromium.org>
Date: Sat Feb 11 08:35:11 2017

FROMLIST: pstore: don't OOPS when there are no ftrace zones

We'll OOPS in ramoops_get_next_prz() if the platform didn't ask for any
ftrace zones (i.e., cxt->fprzs will be NULL). Let's just skip this
entire FTRACE section if there's no 'fprzs'.

Regression seen on a coreboot/depthcharge-based Chromebook.

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: Ic3d3ae94b92be968f63441cabbc7ae823b8e40d7
Fixes: 2fbea82bbb89 ("pstore: Merge per-CPU ftrace records into one")
Cc: Joel Fernandes <joelaf@google.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(am from https://patchwork.kernel.org/patch/9564121/)
Reviewed-on: https://chromium-review.googlesource.com/440561
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/be37f7d9483c7f62a699e6a28010ff822a2b43cd/fs/pstore/ram.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e30ab9304dd7082d6f5330e713bfc9ba1cd5616d

commit e30ab9304dd7082d6f5330e713bfc9ba1cd5616d
Author: Brian Norris <briannorris@chromium.org>
Date: Sat Feb 11 10:42:03 2017

FROMLIST: pstore: unconditionally initialize spinlock and flags

We check to see if a buffer is already sane-looking, and if it's sane,
we don't wipe it. But that's not an excuse to avoid initializing our
spinlocks or setting our flags. Without this, we might see spinlock
debugging messages like this at boot:

[    0.760836] persistent_ram: found existing buffer, size 29988, start 29988
[    0.765112] persistent_ram: found existing buffer, size 30105, start 30105
[    0.769435] persistent_ram: found existing buffer, size 118542, start 118542
[    0.785960] persistent_ram: found existing buffer, size 0, start 0
[    0.786098] persistent_ram: found existing buffer, size 0, start 0
[    0.786131] pstore: using zlib compression
[    0.790716] BUG: spinlock bad magic on CPU#0, swapper/0/1
[    0.790729]  lock: 0xffffffc0d1ca9bb0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[    0.790742] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc2+ #913
[    0.790747] Hardware name: Google Kevin (DT)
[    0.790750] Call trace:
[    0.790768] [<ffffff900808ae88>] dump_backtrace+0x0/0x2bc
[    0.790780] [<ffffff900808b164>] show_stack+0x20/0x28
[    0.790794] [<ffffff9008460ee0>] dump_stack+0xa4/0xcc
[    0.790809] [<ffffff9008113cfc>] spin_dump+0xe0/0xf0
[    0.790821] [<ffffff9008113d3c>] spin_bug+0x30/0x3c
[    0.790834] [<ffffff9008113e28>] do_raw_spin_lock+0x50/0x1b8
[    0.790846] [<ffffff9008a2d2ec>] _raw_spin_lock_irqsave+0x54/0x6c
[    0.790862] [<ffffff90083ac3b4>] buffer_size_add+0x48/0xcc
[    0.790875] [<ffffff90083acb34>] persistent_ram_write+0x60/0x11c
[    0.790888] [<ffffff90083aab1c>] ramoops_pstore_write_buf+0xd4/0x2a4
[    0.790900] [<ffffff90083a9d3c>] pstore_console_write+0xf0/0x134
[    0.790912] [<ffffff900811c304>] console_unlock+0x48c/0x5e8
[    0.790923] [<ffffff900811da18>] register_console+0x3b0/0x4d4
[    0.790935] [<ffffff90083aa7d0>] pstore_register+0x1a8/0x234
[    0.790947] [<ffffff90083ac250>] ramoops_probe+0x6b8/0x7d4
[    0.790961] [<ffffff90085ca548>] platform_drv_probe+0x7c/0xd0
[    0.790972] [<ffffff90085c76ac>] driver_probe_device+0x1b4/0x3bc
[    0.790982] [<ffffff90085c7ac8>] __device_attach_driver+0xc8/0xf4
[    0.790996] [<ffffff90085c4bfc>] bus_for_each_drv+0xb4/0xe4
[    0.791006] [<ffffff90085c7414>] __device_attach+0xd0/0x158
[    0.791016] [<ffffff90085c7b18>] device_initial_probe+0x24/0x30
[    0.791026] [<ffffff90085c648c>] bus_probe_device+0x50/0xe4
[    0.791038] [<ffffff90085c35b8>] device_add+0x3a4/0x76c
[    0.791051] [<ffffff90087d0e84>] of_device_add+0x74/0x84
[    0.791062] [<ffffff90087d19b8>] of_platform_device_create_pdata+0xc0/0x100
[    0.791073] [<ffffff90087d1a2c>] of_platform_device_create+0x34/0x40
[    0.791086] [<ffffff900903c910>] of_platform_default_populate_init+0x58/0x78
[    0.791097] [<ffffff90080831fc>] do_one_initcall+0x88/0x160
[    0.791109] [<ffffff90090010ac>] kernel_init_freeable+0x264/0x31c
[    0.791123] [<ffffff9008a25bd0>] kernel_init+0x18/0x11c
[    0.791133] [<ffffff9008082ec0>] ret_from_fork+0x10/0x50
[    0.793717] console [pstore-1] enabled
[    0.797845] pstore: Registered ramoops as persistent store backend
[    0.804647] ramoops: attached 0x100000@0xf7edc000, ecc: 0/0

BUG= chromium:633355 
TEST=Boot 4.4 kernel on veyron or kevin/gru

Change-Id: I0361db00a4b2129f6e769376befb5bdac9fcb79a
Fixes: 663deb47880f ("pstore: Allow prz to control need for locking")
Fixes: 109704492ef6 ("pstore: Make spinlock per zone instead of global")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(am from https://patchwork.kernel.org/patch/9565653/)
Reviewed-on: https://chromium-review.googlesource.com/440512
Reviewed-by: Kees Cook <keescook@chromium.org>

[modify] https://crrev.com/e30ab9304dd7082d6f5330e713bfc9ba1cd5616d/fs/pstore/ram_core.c