In the function ramoops_probe, the console_size, pmsg_size,
ftrace_size may be update because the value is not the power
of two. We should update the module parameter variables
as well so they are visible through /sys/module/ramoops/parameters
correctly.
Signed-off-by: NWang Long <long.wanglong@huawei.com>
Acked-by: NMark Salyzyn <salyzyn@android.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

A secured user-space accessible pstore object. Writes
to /dev/pmsg0 are appended to the buffer, on reboot
the persistent contents are available in
/sys/fs/pstore/pmsg-ramoops-[ID].

One possible use is syslogd, or other daemon, can
write messages, then on reboot provides a means to
triage user-space activities leading up to a panic
as a companion to the pstore dmesg or console logs.
Signed-off-by: NMark Salyzyn <salyzyn@android.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

ramoops_pstore_read fails to return the next in a prz
series after first zero-sized entry, not venturing to
the next non-zero entry.
Signed-off-by: NMark Salyzyn <salyzyn@android.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

All previous checks will fail with error if memory size
is not sufficient to register a zone, so this legacy
check has become redundant.
Signed-off-by: NMark Salyzyn <salyzyn@android.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

On some ARMs the memory can be mapped pgprot_noncached() and still
be working for atomic operations. As pointed out by Colin Cross
<ccross@android.com>, in some cases you do want to use
pgprot_noncached() if the SoC supports it to see a debug printk
just before a write hanging the system.

On ARMs, the atomic operations on strongly ordered memory are
implementation defined. So let's provide an optional kernel parameter
for configuring pgprot_noncached(), and use pgprot_writecombine() by
default.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robherring2@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: stable@vger.kernel.org
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

pstore compression/decompression was added during 3.12.
The ramoops driver prepends a "====timestamp.timestamp-C|D\n"
header to the compressed record before handing it over to pstore
driver which doesn't know about the header. In pstore_decompress(),
the pstore driver reads the first "==" as a zlib header, so the
decompression always fails. For example, this causes the driver
to write /dev/pstore/dmesg-ramoops-0.enc.z instead of
/dev/pstore/dmesg-ramoops-0.

This patch makes the ramoops driver remove the header before
pstore decompression.
Signed-off-by: NBen Zhang <benzh@chromium.org>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

In case that ramoops_init_przs failed, max_dump_cnt won't be reset to
zero in error handle path.
Signed-off-by: NLiu ShuoX <shuox.liu@intel.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

ramoops_get_next_prz get the prz according the paramters. If it get a
uninitialized prz, access its members by following persistent_ram_old_size(prz)
will cause a NULL pointer crash.
Ex: if ftrace_size is 0, fprz will be NULL.

Fix it by return NULL in advance.
Signed-off-by: NLiu ShuoX <shuox.liu@intel.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

In ramoops_pstore_read, a valid prz pointer with zero size buffer will
break traverse of all persistent ram buffers.  The latter buffer might be
lost.
Signed-off-by: NLiu ShuoX <shuox.liu@intel.com>
Cc: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Cc: Colin Cross <ccross@android.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

*_read_cnt in ramoops_context need to be cleared during pstore ->open to
support mutli times getting the records.  The patch added missed
ftrace_read_cnt clearing and removed duplicate clearing in ramoops_probe.
Signed-off-by: NLiu ShuoX <shuox.liu@intel.com>
Cc: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Previous attempt to fix was b042e474

Suggested use of is_power_of_2() was bogus because is_power_of_2(0) is
false (documented behaviour).
Signed-off-by: NMaxime Bizon <mbizon@freebox.fr>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

In pstore write, add character 'C'(compressed) or 'D'(decompressed)
in the header while writing to Ram persistent buffer. In pstore read,
read the header and update the 'compressed' flag accordingly.
Signed-off-by: NAruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Backends will set the flag 'compressed' after reading the log from
persistent store to indicate the data being returned to pstore is
compressed or not.
Signed-off-by: NAruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Addition of new argument 'compressed' in the write call back will
help the backend to know if the data passed from pstore is compressed
or not (In case where compression fails.). If compressed, the backend
can add a tag indicating the data is compressed while writing to
persistent store.
Signed-off-by: NAruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Header size is needed to distinguish between header and the dump data.
Incorporate the addition of new argument (hsize) in the pstore write
callback.
Signed-off-by: NAruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

There doesn't appear to be any reason for the overall pstore RAM buffer to
be a power of 2 size, so remove it. The individual console, ftrace and oops
buffers are still a power of 2 size.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Acked-by: NAnton Vorontsov <anton@enomsg.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This was lost when proc/last_kmsg moved to pstore/console-ramoops.
Signed-off-by: NArve Hjønnevåg <arve@android.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NAnton Vorontsov <anton@enomsg.org>

Allow specifying ecc parameters in platform data
Signed-off-by: NArve Hjønnevåg <arve@android.com>
[jstultz: Tweaked commit subject & add commit message]
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NAnton Vorontsov <anton@enomsg.org>

Replaced calls to kmalloc and memcpy with a single call to kmemdup. This
patch was found using coccicheck.
Signed-off-by: NAlexandru Gheorghiu <gheorghiuandru@gmail.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NAnton Vorontsov <anton@enomsg.org>

Replaced calls to kmalloc and memcpy with a single call to kmemdup.
This patch was found using coccicheck.
Signed-off-by: NAlexandru Gheorghiu <gheorghiuandru@gmail.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The pstore RAM backend can get called during resume, and must be defensive
against a suspended time source. Expose getnstimeofday logic that returns
an error instead of a WARN. This can be detected and the timestamp can
be zeroed out.
Reported-by: NDoug Anderson <dianders@chromium.org>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit from the pstore filesystem.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Anton Vorontsov <cbouatmailru@gmail.com>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The bounds check in ramoops_init_prz was incorrect and ramoops_init_przs
had no check. Additionally, ramoops_init_przs allows record_size to be 0,
but ramoops_pstore_write_buf would always crash in this case.
Signed-off-by: NArve Hjønnevåg <arve@android.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

[Issue]

Currently, a variable name, which identifies each entry, consists of type, id and ctime.
But if multiple events happens in a short time, a second/third event may fail to log because
efi_pstore can't distinguish each event with current variable name.

[Solution]

A reasonable way to identify all events precisely is introducing a sequence counter to
the variable name.

The sequence counter has already supported in a pstore layer with "oopscount".
So, this patch adds it to a variable name.
Also, it is passed to read/erase callbacks of platform drivers in accordance with
the modification of the variable name.

  <before applying this patch>
 a variable name of first event: dump-type0-1-12345678
 a variable name of second event: dump-type0-1-12345678

  type:0
  id:1
  ctime:12345678

 If multiple events happen in a short time, efi_pstore can't distinguish them because
 variable names are same among them.

  <after applying this patch>

 it can be distinguishable by adding a sequence counter as follows.

 a variable name of first event: dump-type0-1-1-12345678
 a variable name of Second event: dump-type0-1-2-12345678

  type:0
  id:1
  sequence counter: 1(first event), 2(second event)
  ctime:12345678

In case of a write callback executed in pstore_console_write(), "0" is added to
an argument of the write callback because it just logs all kernel messages and
doesn't need to care about multiple events.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

[Issue]

Currently, a variable name, which is used to identify each log entry, consists of type,
id and ctime. But an erase callback does not use ctime.

If efi_pstore supported just one log, type and id were enough.
However, in case of supporting multiple logs, it doesn't work because
it can't distinguish each entry without ctime at erasing time.

 <Example>

 As you can see below, efi_pstore can't differentiate first event from second one without ctime.

 a variable name of first event: dump-type0-1-12345678
 a variable name of second event: dump-type0-1-23456789

  type:0
  id:1
  ctime:12345678, 23456789

[Solution]

This patch adds ctime to an argument of an erase callback.

It works across reboots because ctime of pstore means the date that the record was originally stored.
To do this, efi_pstore saves the ctime to variable name at writing time and passes it to pstore
at reading time.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

record_size / console_size / ftrace_size can be 0 (this is how you disable
the feature), but rounddown_pow_of_two(0) is undefined. As suggested by
Kees Cook, use !is_power_of_2() as a condition to call
rounddown_pow_of_two and avoid its undefined behavior on the value 0. This
issue has been present since commit 1894a253 (ramoops: Move to
fs/pstore/ram.c).

Cc: stable@vger.kernel.org
Signed-off-by: NMaxime Bizon <mbizon@freebox.fr>
Signed-off-by: NFlorian Fainelli <ffainelli@freebox.fr>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

The compiler complained about missing section annotations.
Fix it.
Signed-off-by: NHannes Reinecke <hare@suse.de>
Cc: Colin Cross <ccross@android.com>
Cc: Tony Luck <tony.luck@intel.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

We need to unregister platform device when module exit, this commit fixes
the issue.
Signed-off-by: NJovi Zhang <bookjovi@gmail.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

write_buf() should be marked as notrace, otherwise it is prone to
recursion.

Though, yet the issue is never triggered in real life, because we run
inside the function tracer, where ftrace does its own recurse protection.

But it's still no good, plus soon we might switch to our own tracer ops,
and then the issue will be fatal. So, let's fix it.
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

Fix printk format warning (on i386) in pstore:

fs/pstore/ram.c:409:3: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

We can dereference 'cxt->cprz' if console and dump logging are disabled
(which is unlikely, but still possible to do). This patch fixes the issue
by changing the code so that we don't dereference przs at all, we can
just calculate bufsize from console_size and record_size values.

Plus, while at it, the patch improves the buffer size calculation.

After Kay's printk rework, we know the optimal buffer size for console
logging -- it is LOG_LINE_MAX (defined privately in printk.c). Previously,
if only console logging was enabled, we would allocate unnecessary large
buffer in pstore, while we only need LOG_LINE_MAX. (Pstore console logging
is still capable of handling buffers > LOG_LINE_MAX, it will just do
multiple calls to psinfo->write).

Note that I don't export the constant, since we will do even a better
thing soon: we will switch console logging to a new write_buf API, which
will eliminate the need for the additional buffer; and so we won't need
the constant.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: NKees Cook <keescook@chromium.org>

Decoding the binary trace w/ a different kernel might be troublesome
since we convert addresses to symbols. For kernels with minimal changes,
the mappings would probably match, but it's not guaranteed at all.
(But still we could convert the addresses by hand, since we do print
raw addresses.)

If we use modules, the symbols could be loaded at different addresses
from the previously booted kernel, and so this would also fail, but
there's nothing we can do about it.

Also, the binary data format that pstore/ram is using in its ringbuffer
may change between the kernels, so here we too must ensure that we're
running the same kernel.

So, there are two questions really:

1. How to compute the unique kernel tag;
2. Where to store it.

In this patch we're using LINUX_VERSION_CODE, just as hibernation
(suspend-to-disk) does. This way we are protecting from the kernel
version mismatch, making sure that we're running the same kernel
version and patch level. We could use CRC of a symbol table (as
suggested by Tony Luck), but for now let's not be that strict.

And as for storing, we are using a small trick here. Instead of
allocating a dedicated buffer for the tag (i.e. another prz), or
hacking ram_core routines to "reserve" some control data in the
buffer, we are just encoding the tag into the buffer signature
(and XOR'ing it with the actual signature value, so that buffers
not needing a tag can just pass zero, which will result into the
plain old PRZ signature).
Suggested-by: NSteven Rostedt <rostedt@goodmis.org>
Suggested-by: NTony Luck <tony.luck@intel.com>
Suggested-by: NColin Cross <ccross@android.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ftrace log size is configurable via ramoops.ftrace_size
module option, and the log itself is available via
<pstore-mount>/ftrace-ramoops file.
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Don't use pstore.buf directly, instead convert the code to write_buf callback
which passes a pointer to a buffer as an argument.
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is now pretty straightforward: instead of using bool, just pass
an integer. For backwards compatibility ramoops.ecc=1 means 16 bytes
ECC (using 1 byte for ECC isn't much of use anyway).
Suggested-by: NArve Hjønnevåg <arve@android.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

persistent_ram_new() returns ERR_PTR() value on errors, so during
freeing of the przs we should check for both NULL and IS_ERR() entries,
otherwise bad things will happen.
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Registering the platform driver before module_init allows us to log oopses
that happen during device probing.

This requires changing module_init to postcore_initcall, and switching
from platform_driver_probe to platform_driver_register because the
platform device is not registered when the platform driver is registered;
and because we use driver_register, now can't use create_bundle() (since
it will try to register the same driver once again), so we have to switch
to platform_device_register_data().

Also, some __init -> __devinit changes were needed.

Overall, the registration logic is now much clearer, since we have only
one driver registration point, and just an optional dummy device, which
is created from the module parameters.
Suggested-by: NColin Cross <ccross@android.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The console log size is configurable via ramoops.console_size
module option, and the log itself is available via
<pstore-mount>/console-ramoops file.
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>