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>

This will help make code clearer when we'll add support for other
message types.

The patch also changes return value from -EINVAL to 0 in case of
end-of-records. The exact value doesn't matter for pstore (it should
be just <= 0), but 0 feels more correct.
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>

This will help make code clearer when we'll add support for other
message types.

This also makes probe() much shorter and understandable, plus
makes mem/record size checking a bit easier.

Implementation detail: we now use a paddr pointer, this will
be used for allocating persistent ram zones for other message
types.
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>

We're about to add support for other message types, so let's rename
some variables to not be confused later.
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>

Otherwise, unlinked file will reappear on the next boot.
Reported-by: NKees Cook <keescook@chromium.org>
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>

Without the update, we'll only see the new dmesg buffer after the
reboot, but previously we could see it right away. Making an oops
visible in pstore filesystem before reboot is a somewhat dubious
feature, but removing it wasn't an intentional change, so let's
restore it.

For this we have to make persistent_ram_save_old() safe for calling
multiple times, and also extern it.
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>

This is now straightforward: just introduce a module parameter and pass
the needed value to persistent_ram_new().
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: NMarco Stornelli <marco.stornelli@gmail.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The patch switches pstore RAM backend to use persistent_ram routines,
one step closer to the ECC support.
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: NMarco Stornelli <marco.stornelli@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since ramoops was converted to pstore, it has nothing to do with character
devices nowadays. Instead, today it is just a RAM backend for pstore.

The patch just moves things around. There are a few changes were needed
because of the move:

1. Kconfig and Makefiles fixups, of course.

2. In pstore/ram.c we have to play a bit with MODULE_PARAM_PREFIX, this
   is needed to keep user experience the same as with ramoops driver
   (i.e. so that ramoops.foo kernel command line arguments would still
   work).
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: NMarco Stornelli <marco.stornelli@gmail.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix printk format warnings for phys_addr_t type variables:

drivers/char/ramoops.c:246:3: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'phys_addr_t'
drivers/char/ramoops.c:273:2: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'phys_addr_t'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of using /dev/mem directly and forcing userspace to know (or
extract) where the platform has defined persistent memory, how many slots
it has, the sizes, etc, use the common pstore infrastructure to handle
Oops gathering and extraction.  This presents a much easier to use
filesystem-based view to the memory region.  This also means that any
other tools that are written to understand pstore will automatically be
able to process ramoops too.
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Marco Stornelli <marco.stornelli@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

drivers/char/ramoops.c included 'linux/err.h' twice, remove
the duplicate.
Signed-off-by: NDanny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If a platform device exists on the system, but ramoops fails to attach to
it, the module parameters are overridden before ramoops can fall back and
try to use passed module parameters.  Move update to end of init routine.
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: Marco Stornelli <marco.stornelli@gmail.com>
Cc: Sergiu Iordache <sergiu@chromium.org>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The return value of rounddown_pow_of_two wasn't evaluated, so the
operation was a no-op.
Signed-off-by: NMarco Stornelli <marco.stornelli@gmail.com>
Reported-by: NAndrew Morton <akpm@linux-foundation.org>
Reviewed-by: NWANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

KMSG_DUMP_KEXEC is useless because we already save kernel messages inside
/proc/vmcore, and it is unsafe to allow modules to do other stuffs in a
crash dump scenario.

[akpm@linux-foundation.org: fix powerpc build]
Signed-off-by: NWANG Cong <xiyou.wangcong@gmail.com>
Reported-by: NVivek Goyal <vgoyal@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

drivers/char/ramoops.c: In function 'ramoops_init':
drivers/char/ramoops.c:221: error: implicit declaration of function 'IS_ERR'
drivers/char/ramoops.c:222: error: implicit declaration of function 'PTR_ERR'
make[3]: *** [drivers/char/ramoops.o] Error 1
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Update the module parameters when platform data is used.  This means
that they can be read from /sys/module/ramoops/parameters in order to
parse the memory area.
Signed-off-by: NSergiu Iordache <sergiu@chromium.org>
Cc: Marco Stornelli <marco.stornelli@gmail.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixes this:

  drivers/char/ramoops.c: In function 'ramoops_init':
  drivers/char/ramoops.c:221: error: implicit declaration of function 'IS_ERR'
  drivers/char/ramoops.c:222: error: implicit declaration of function 'PTR_ERR'

If it actually builds on other platforms, it's probably getting
linux/err.h via some other #include.
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The size of the dump is currently set using the RECORD_SIZE macro which
is set to a page size.  This patch makes the record size a module
parameter and allows it to be set through platform data as well to allow
larger dumps if needed.
Signed-off-by: NSergiu Iordache <sergiu@chromium.org>
Acked-by: NMarco Stornelli <marco.stornelli@gmail.com>
Cc: "Ahmed S. Darwish" <darwish.07@gmail.com>
Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The platform driver currently allows setting the mem_size and
mem_address.

ince dump_oops is also a module parameter it would be more consistent if
it could be set through platform data as well.
Signed-off-by: NSergiu Iordache <sergiu@chromium.org>
Acked-by: NMarco Stornelli <marco.stornelli@gmail.com>
Cc: "Ahmed S. Darwish" <darwish.07@gmail.com>
Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add new line to each print.
Signed-off-by: NMarco Stornelli <marco.stornelli@gmail.com>
Reported-by: NStevie Trujillo <stevie.trujillo@gmail.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Américo Wang <xiyou.wangcong@gmail.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use generic module parameters instead of platform data, if platform data
are not available.  This limitation has been introduced with commit
c3b92ce9 ("ramoops: use the platform data structure instead of module
params").

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NMarco Stornelli <marco.stornelli@gmail.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Américo Wang <xiyou.wangcong@gmail.com>
Reported-by: NStevie Trujillo <stevie.trujillo@gmail.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Cc: Ahmed S. Darwish <darwish.07@gmail.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marco Stornelli <marco.stornelli@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This series aims to develop logging facility for enterprise use.

It is important to save kernel messages reliably on enterprise system
because they are helpful for diagnosing system.

This series add kmsg_dump() to the paths loosing kernel messages.  The use
case is the following.

[Use case of reboot/poweroff/halt/emergency_restart]

 My company has often experienced the followings in our support service.
 - Customer's system suddenly reboots.
 - Customers ask us to investigate the reason of the reboot.

We recognize the fact itself because boot messages remain in
/var/log/messages.  However, we can't investigate the reason why the
system rebooted, because the last messages don't remain.  And off course
we can't explain the reason.

We can solve above problem with this patch as follows.

 Case1: reboot with command
   - We can see "Restarting system with command:" or ""Restarting system.".

 Case2: halt with command
   - We can see "System halted.".

 Case3: poweroff with command
   - We can see " Power down.".

 Case4: emergency_restart with sysrq.
   - We can see "Sysrq:" outputted in __handle_sysrq().

 Case5: emergency_restart with softdog.
   - We can see "Initiating system reboot" in watchdog_fire().

So, we can distinguish the reason of reboot, poweroff, halt and emergency_restart.

If customer executed reboot command, you may think the customer should
know the fact.  However, they often claim they don't execute the command
when they rebooted system by mistake.

No message remains on the current Linux kernel, so we can't show the proof
to the customer.  This patch improves this situation.

This patch:

Alters mtdoops and ramoops to perform their actions only for
KMSG_DUMP_PANIC, KMSG_DUMP_OOPS and KMSG_DUMP_KEXEC because they would
like to log crashes only.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Marco Stornelli <marco.stornelli@gmail.com>
Reviewed-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The current code mis-calculates the ramoops header size, leading to an
overflow over the next record at best, or over a non-allocated region at
worst.  Fix that calculation.
Signed-off-by: NAhmed S. Darwish <darwish.07@gmail.com>
Acked-by: NMarco Stornelli <marco.stornelli@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>