Eric Lee / smarc-fsl-linux-kernel

05 Jul, 2013

1 commit

  • 65b97fb73   Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc ... Browse Code »

    Pull powerpc updates from Ben Herrenschmidt:
    "This is the powerpc changes for the 3.11 merge window. In addition to
    the usual bug fixes and small updates, the main highlights are:

    - Support for transparent huge pages by Aneesh Kumar for 64-bit
    server processors. This allows the use of 16M pages as transparent
    huge pages on kernels compiled with a 64K base page size.

    - Base VFIO support for KVM on power by Alexey Kardashevskiy

    - Wiring up of our nvram to the pstore infrastructure, including
    putting compressed oopses in there by Aruna Balakrishnaiah

    - Move, rework and improve our "EEH" (basically PCI error handling
    and recovery) infrastructure. It is no longer specific to pseries
    but is now usable by the new "powernv" platform as well (no
    hypervisor) by Gavin Shan.

    - I fixed some bugs in our math-emu instruction decoding and made it
    usable to emulate some optional FP instructions on processors with
    hard FP that lack them (such as fsqrt on Freescale embedded
    processors).

    - Support for Power8 "Event Based Branch" facility by Michael
    Ellerman. This facility allows what is basically "userspace
    interrupts" for performance monitor events.

    - A bunch of Transactional Memory vs. Signals bug fixes and HW
    breakpoint/watchpoint fixes by Michael Neuling.

    And more ... I appologize in advance if I've failed to highlight
    something that somebody deemed worth it."

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (156 commits)
    pstore: Add hsize argument in write_buf call of pstore_ftrace_call
    powerpc/fsl: add MPIC timer wakeup support
    powerpc/mpic: create mpic subsystem object
    powerpc/mpic: add global timer support
    powerpc/mpic: add irq_set_wake support
    powerpc/85xx: enable coreint for all the 64bit boards
    powerpc/8xx: Erroneous double irq_eoi() on CPM IRQ in MPC8xx
    powerpc/fsl: Enable CONFIG_E1000E in mpc85xx_smp_defconfig
    powerpc/mpic: Add get_version API both for internal and external use
    powerpc: Handle both new style and old style reserve maps
    powerpc/hw_brk: Fix off by one error when validating DAWR region end
    powerpc/pseries: Support compression of oops text via pstore
    powerpc/pseries: Re-organise the oops compression code
    pstore: Pass header size in the pstore write callback
    powerpc/powernv: Fix iommu initialization again
    powerpc/pseries: Inform the hypervisor we are using EBB regs
    powerpc/perf: Add power8 EBB support
    powerpc/perf: Core EBB support for 64-bit book3s
    powerpc/perf: Drop MMCRA from thread_struct
    powerpc/perf: Don't enable if we have zero events
    ...

    Linus Torvalds
     

02 Jul, 2013

1 commit

01 Jul, 2013

1 commit

29 Jun, 2013

1 commit

  • 8e48b1a8e   pstore: Return unique error if backend registration excluded by kernel param ... Browse Code »

    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: Lenny Szubowicz
    Reported-by: Naotaka Hamaguchi
    Signed-off-by: Tony Luck

    Lenny Szubowicz
     

26 Jun, 2013

1 commit

20 Jun, 2013

3 commits

15 Jun, 2013

2 commits

  • 264466545   pstore/ram: remove the power of buffer size limitation ... Browse Code »

    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: Rob Herring
    Acked-by: Anton Vorontsov
    Signed-off-by: Tony Luck

    Rob Herring
     
  • 0405a5cec   pstore/ram: avoid atomic accesses for ioremapped regions ... Browse Code »

    For persistent RAM outside of main memory, the memory may have limitations
    on supported accesses. For internal RAM on highbank platform exclusive
    accesses are not supported and will hang the system. So atomic_cmpxchg
    cannot be used. This commit uses spinlock protection for buffer size and
    start updates on ioremapped regions instead.

    Signed-off-by: Rob Herring
    Acked-by: Anton Vorontsov
    Signed-off-by: Tony Luck

    Rob Herring
     

10 May, 2013

1 commit

  • 70eba4226   Merge tag 'please-pull-pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux ... Browse Code »

    Pull trivial pstore update from Tony Luck:
    "Couple of pstore cleanups"

    It turns out that the kmemdup() conversion ends up being undone by the
    fact that the memory block also needed the ecc information (see commit
    bd08ec33b5c2: "pstore/ram: Restore ecc information block"), so all that
    remains after merging is the error return code change.

    * tag 'please-pull-pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
    pstore/ram: fix error return code in ramoops_probe()
    fs: pstore: Replaced calls to kmalloc and memcpy with kmemdup

    Linus Torvalds
     

09 May, 2013

1 commit

04 Apr, 2013

3 commits

19 Mar, 2013

1 commit

12 Mar, 2013

1 commit

22 Feb, 2013

1 commit

  • 024e4ec18   Merge tag 'please-pull-pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux ... Browse Code »

    Pull pstore patches from Tony Luck:
    "A few fixes to reduce places where pstore might hang a system in the
    crash path. Plus a new mountpoint (/sys/fs/pstore ... makes more
    sense then /dev/pstore)."

    Fix up trivial conflict in drivers/firmware/efivars.c

    * tag 'please-pull-pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
    pstore: Create a convenient mount point for pstore
    efi_pstore: Introducing workqueue updating sysfs
    efivars: Disable external interrupt while holding efivars->lock
    efi_pstore: Avoid deadlock in non-blocking paths
    pstore: Avoid deadlock in panic and emergency-restart path

    Linus Torvalds
     

13 Feb, 2013

1 commit

  • fb0af3f2b   pstore: Create a convenient mount point for pstore ... Browse Code »

    Using /dev/pstore as a mount point for the pstore filesystem is slightly
    awkward. We don't normally mount filesystems in /dev/ and the /dev/pstore
    file isn't created automatically by anything. While this method will
    still work, we can create a persistent mount point in sysfs. This will
    put pstore on par with things like cgroups and efivarfs.

    Signed-off-by: Josh Boyer
    Acked-by: Kees Cook
    Signed-off-by: Tony Luck

    Josh Boyer
     

04 Feb, 2013

1 commit

16 Jan, 2013

1 commit

  • 1e817fb62   time: create __getnstimeofday for WARNless calls ... Browse Code »

    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: Doug Anderson
    Cc: John Stultz
    Cc: Anton Vorontsov
    Signed-off-by: Kees Cook
    Signed-off-by: John Stultz

    Kees Cook
     

12 Jan, 2013

1 commit

  • 9f244e9cf   pstore: Avoid deadlock in panic and emergency-restart path ... Browse Code »

    [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.

    /**
    * 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)

    Signed-off-by: Seiji Aguchi
    Acked-by: Don Zickus
    Signed-off-by: Tony Luck

    Seiji Aguchi
     

04 Jan, 2013

1 commit

  • f568f6ca8   pstore: remove __dev* attributes. ... Browse Code »

    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
    Cc: Anton Vorontsov
    Cc: Colin Cross
    Cc: Kees Cook
    Cc: Tony Luck
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

18 Dec, 2012

1 commit

16 Dec, 2012

1 commit

  • 75e300c8b   Merge tag 'for-v3.8' of git://git.infradead.org/users/cbou/linux-pstore ... Browse Code »

    Pull pstore update from Anton Vorontsov:
    "Here are just a few fixups for the pstore subsystem, nothing special
    this time"

    * tag 'for-v3.8' of git://git.infradead.org/users/cbou/linux-pstore:
    pstore/ftrace: Adjust for ftrace_ops->func prototype change
    pstore/ram: Fix bounds checks for mem_size, record_size, console_size and ftrace_size
    pstore/ram: Fix undefined usage of rounddown_pow_of_two(0)
    pstore/ram: Fixup section annotations

    Linus Torvalds
     

13 Dec, 2012

2 commits

27 Nov, 2012

2 commits

  • 755d4fe46   efi_pstore: Add a sequence counter to a variable name ... Browse Code »

    [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.


    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.

    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: Seiji Aguchi
    Acked-by: Rafael J. Wysocki
    Acked-by: Mike Waychison
    Signed-off-by: Tony Luck

    Seiji Aguchi
     
  • a9efd39cd   efi_pstore: Add ctime to argument of erase callback ... Browse Code »

    [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.

    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: Seiji Aguchi
    Acked-by: Mike Waychison
    Signed-off-by: Tony Luck

    Seiji Aguchi
     

18 Nov, 2012

1 commit

  • b042e4749   pstore/ram: Fix undefined usage of rounddown_pow_of_two(0) ... Browse Code »

    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: Maxime Bizon
    Signed-off-by: Florian Fainelli
    Acked-by: Kees Cook
    Signed-off-by: Anton Vorontsov

    Maxime Bizon
     

17 Nov, 2012

1 commit

15 Nov, 2012

1 commit

  • 70a6f46d7   pstore: Fix NULL pointer dereference in console writes ... Browse Code »

    Passing a NULL id causes a NULL pointer deference in writers such as
    erst_writer and efi_pstore_write because they expect to update this id.
    Pass a dummy id instead.

    This avoids a cascade of oopses caused when the initial
    pstore_console_write passes a null which in turn causes writes to the
    console causing further oopses in subsequent pstore_console_write calls.

    Signed-off-by: Colin Ian King
    Acked-by: Kees Cook
    Cc: stable@vger.kernel.org
    Signed-off-by: Anton Vorontsov

    Colin Ian King
     

21 Sep, 2012

1 commit

07 Sep, 2012

1 commit

  • 65f8c95e4   pstore/ftrace: Convert to its own enable/disable debugfs knob ... Browse Code »

    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: Steven Rostedt
    Signed-off-by: Anton Vorontsov

    Anton Vorontsov
     

01 Sep, 2012

1 commit

05 Aug, 2012

3 commits

  • 242030365   pstore/ram: Mark ramoops_pstore_write_buf() as notrace ... Browse Code »

    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: Anton Vorontsov

    Anton Vorontsov
     
  • 0427193b6   pstore/ram: Fix printk format warning ... Browse Code »

    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: Randy Dunlap
    Acked-by: Kees Cook
    Signed-off-by: Anton Vorontsov

    Randy Dunlap
     
  • a384f6411   pstore/ram: Fix possible NULL dereference ... Browse Code »

    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: Dan Carpenter
    Signed-off-by: Anton Vorontsov
    Acked-by: Kees Cook

    Anton Vorontsov
     

18 Jul, 2012

2 commits

  • cbe7cbf5a   pstore/ram: Make tracing log versioned ... Browse Code »

    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: Steven Rostedt
    Suggested-by: Tony Luck
    Suggested-by: Colin Cross
    Signed-off-by: Anton Vorontsov
    Signed-off-by: Greg Kroah-Hartman

    Anton Vorontsov
     
  • 67a101f57   pstore: Headers should include all stuff they use ... Browse Code »

    Headers should really include all the needed prototypes, types, defines
    etc. to be self-contained. This is a long-standing issue, but apparently
    the new tracing code unearthed it (SMP=n is also a prerequisite):

    In file included from fs/pstore/internal.h:4:0,
    from fs/pstore/ftrace.c:21:
    include/linux/pstore.h:43:15: error: field ‘read_mutex’ has incomplete type

    While at it, I also added the following:

    linux/types.h -> size_t, phys_addr_t, uXX and friends
    linux/spinlock.h -> spinlock_t
    linux/errno.h -> Exxxx
    linux/time.h -> struct timespec (struct passed by value)
    struct module and rs_control forward declaration (passed via pointers).

    Signed-off-by: Anton Vorontsov
    Signed-off-by: Greg Kroah-Hartman

    Anton Vorontsov