Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 20 8月, 2013 8 次提交
  3. 02 7月, 2013 1 次提交
  5. 01 7月, 2013 1 次提交
  7. 29 6月, 2013 1 次提交
    • L
      pstore: Return unique error if backend registration excluded by kernel param · 8e48b1a8
      由 Lenny Szubowicz 提交于 
      This is patch 1/3 of a patch set that avoids what misleadingly appears
to be a error during boot:

ERST: Could not register with persistent store

This message is displayed if the system has a valid ACPI ERST table and the
pstore.backend kernel parameter has been used to disable use of ERST by
pstore. But this same message is used for errors that preclude registration.

As part of fixing this, return a unique error status from pstore_register
if the pstore.backend kernel parameter selects a specific facility other
than the requesting facility and check for this condition before any others.
This allows the caller to distinquish this benign case from the other failure
cases.

Also, print an informational console message about which facility
successfully registered as the pstore backend. Since there are various
kernel parameters, config build options, and boot-time errors that can
influence which facility registers with pstore, it's useful to have a
positive indication.
Signed-off-by: NLenny Szubowicz <lszubowi@redhat.com>
Reported-by: NNaotaka Hamaguchi <n.hamaguchi@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      8e48b1a8
  9. 26 6月, 2013 1 次提交
  11. 20 6月, 2013 3 次提交
  13. 15 6月, 2013 2 次提交
  15. 09 5月, 2013 1 次提交
  17. 04 4月, 2013 3 次提交
  19. 19 3月, 2013 1 次提交
  21. 12 3月, 2013 1 次提交
  23. 13 2月, 2013 1 次提交
  25. 16 1月, 2013 1 次提交
  27. 12 1月, 2013 1 次提交
    • S
      pstore: Avoid deadlock in panic and emergency-restart path · 9f244e9c
      由 Seiji Aguchi 提交于 
      [Issue]

When pstore is in panic and emergency-restart paths, it may be blocked
in those paths because it simply takes spin_lock.

This is an example scenario which pstore may hang up in a panic path:

 - cpuA grabs psinfo->buf_lock
 - cpuB panics and calls smp_send_stop
 - smp_send_stop sends IRQ to cpuA
 - after 1 second, cpuB gives up on cpuA and sends an NMI instead
 - cpuA is now in an NMI handler while still holding buf_lock
 - cpuB is deadlocked

This case may happen if a firmware has a bug and
cpuA is stuck talking with it more than one second.

Also, this is a similar scenario in an emergency-restart path:

 - cpuA grabs psinfo->buf_lock and stucks in a firmware
 - cpuB kicks emergency-restart via either sysrq-b or hangcheck timer.
   And then, cpuB is deadlocked by taking psinfo->buf_lock again.

[Solution]

This patch avoids the deadlocking issues in both panic and emergency_restart
paths by introducing a function, is_non_blocking_path(), to check if a cpu
can be blocked in current path.

With this patch, pstore is not blocked even if another cpu has
taken a spin_lock, in those paths by changing from spin_lock_irqsave
to spin_trylock_irqsave.

In addition, according to a comment of emergency_restart() in kernel/sys.c,
spin_lock shouldn't be taken in an emergency_restart path to avoid
deadlock. This patch fits the comment below.

<snip>
/**
 *      emergency_restart - reboot the system
 *
 *      Without shutting down any hardware or taking any locks
 *      reboot the system.  This is called when we know we are in
 *      trouble so this is our best effort to reboot.  This is
 *      safe to call in interrupt context.
 */
void emergency_restart(void)
<snip>
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NDon Zickus <dzickus@redhat.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      9f244e9c
  29. 04 1月, 2013 1 次提交
    • G
      pstore: remove __dev* attributes. · f568f6ca
      由 Greg Kroah-Hartman 提交于 
      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>
      f568f6ca
  31. 18 12月, 2012 1 次提交
  33. 13 12月, 2012 2 次提交
  35. 27 11月, 2012 2 次提交
    • S
      efi_pstore: Add a sequence counter to a variable name · 755d4fe4
      由 Seiji Aguchi 提交于 
      [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>
      755d4fe4
    • S
      efi_pstore: Add ctime to argument of erase callback · a9efd39c
      由 Seiji Aguchi 提交于 
      [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>
      a9efd39c
  37. 18 11月, 2012 1 次提交
  39. 17 11月, 2012 1 次提交
  41. 15 11月, 2012 1 次提交
  43. 21 9月, 2012 1 次提交
  45. 07 9月, 2012 1 次提交
    • A
      pstore/ftrace: Convert to its own enable/disable debugfs knob · 65f8c95e
      由 Anton Vorontsov 提交于 
      With this patch we no longer reuse function tracer infrastructure, now
we register our own tracer back-end via a debugfs knob.

It's a bit more code, but that is the only downside. On the bright side we
have:

- Ability to make persistent_ram module removable (when needed, we can
  move ftrace_ops struct into a module). Note that persistent_ram is still
  not removable for other reasons, but with this patch it's just one
  thing less to worry about;

- Pstore part is more isolated from the generic function tracer. We tried
  it already by registering our own tracer in available_tracers, but that
  way we're loosing ability to see the traces while we record them to
  pstore. This solution is somewhere in the middle: we only register
  "internal ftracer" back-end, but not the "front-end";

- When there is only pstore tracing enabled, the kernel will only write
  to the pstore buffer, omitting function tracer buffer (which, of course,
  still can be enabled via 'echo function > current_tracer').
Suggested-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
      65f8c95e
  47. 01 9月, 2012 1 次提交
  49. 05 8月, 2012 2 次提交