windcharger: backport /dev/kmsg interface to 3.3.8

This allows us to use the c logupload client while we stay on 3.3.8. These
commits originally came from the mainline linux repo, but we decided to squash
them here because the specific changes aren't very important for our heavily-
patched 3.3.8 kernel.

b/21034412

commit 533827c921c34310f63e859e1d6d0feec439657d
Author: Anton Vorontsov <anton.vorontsov@linaro.org>
Date:   Fri Jul 20 17:28:07 2012 -0700

    printk: Implement some unlocked kmsg_dump functions

    If used from KDB, the locked variants are prone to deadlocks (suppose we
    got to the debugger w/ the logbuf lock held).

    So, we have to implement a few routines that grab no logbuf lock.

    Yet we don't need these functions in modules, so we don't export them.

    Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 246f6f2ff2c5cf46ded6d06f11f63e38bad880d1
Author: Kay Sievers <kay@vrfy.org>
Date:   Tue Jun 19 00:32:57 2012 +0200

    kmsg - kmsg_dump() fix CONFIG_PRINTK=n compilation

    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Reported-by: Randy Dunlap <rdunlap@xenotime.net>
    Reported-by: Fengguang Wu <wfg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b499d05eecbe04969516717a8e15afb6ad80689
Author: Anton Vorontsov <anton.vorontsov@linaro.org>
Date:   Fri Jul 20 17:27:54 2012 -0700

    printk: Remove kdb_syslog_data

    The function is no longer needed, so remove it.

    Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 5becfb1df5ac8e491338e64b1029685ccad4b39c
Author: Kay Sievers <kay@vrfy.org>
Date:   Mon Jul 9 12:15:42 2012 -0700

    kmsg: merge continuation records while printing

    In (the unlikely) case our continuation merge buffer is busy, we unfortunately
    can not merge further continuation printk()s into a single record and have to
    store them separately, which leads to split-up output of these lines when they
    are printed.

    Add some flags about newlines and prefix existence to these records and try to
    reconstruct the full line again, when the separated records are printed.

    Reported-By: Michael Neuling <mikey@neuling.org>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Tested-By: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb02dac93708f581c99858a19162af8ca2b6bfcb
Author: Kay Sievers <kay@vrfy.org>
Date:   Mon Jul 9 10:05:10 2012 -0700

    kmsg: /proc/kmsg - support reading of partial log records

    Restore support for partial reads of any size on /proc/kmsg, in case the
    supplied read buffer is smaller than the record size.

    Some people seem to think is is ia good idea to run:
      $ dd if=/proc/kmsg bs=1 of=...
    as a klog bridge.

    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44211
    Reported-by: Jukka Ollila <jiiksteri@gmail.com>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68b6507dc554ba015b5ed5e13b1ed4993cdf4024
Author: Kay Sievers <kay@vrfy.org>
Date:   Fri Jul 6 09:50:09 2012 -0700

    kmsg: make sure all messages reach a newly registered boot console

    We suppress printing kmsg records to the console, which are already printed
    immediately while we have received their fragments.

    Newly registered boot consoles print the entire kmsg buffer during
    registration. Clear the console-suppress flag after we skipped the record
    during its first storage, so any later print will see these records as usual.

    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb424ffe9f45ad80267f2a98fbd9bf21caa0ce22
Author: Kay Sievers <kay@vrfy.org>
Date:   Fri Jul 6 09:50:09 2012 -0700

    kmsg: properly handle concurrent non-blocking read() from /proc/kmsg

    The /proc/kmsg read() interface is internally simply wired up to a sequence
    of syslog() syscalls, which might are racy between their checks and actions,
    regarding concurrency.

    In the (very uncommon) case of concurrent readers of /dev/kmsg, relying on
    usual O_NONBLOCK behavior, the recently introduced mutex might block an
    O_NONBLOCK reader in read(), when poll() returns for it, but another process
    has already read the data in the meantime. We've seen that while running
    artificial test setups and tools that "fight" about /proc/kmsg data.

    This restores the original /proc/kmsg behavior, where in case of concurrent
    read()s, poll() might wake up but the read() syscall will just return 0 to
    the caller, while another process has "stolen" the data.

    This is in the general case not the expected behavior, but it is the exact
    same one, that can easily be triggered with a 3.4 kernel, and some tools
    might just rely on it.

    The mutex is not needed, the original integrity issue which introduced it,
    is in the meantime covered by:
      "fill buffer with more than a single message for SYSLOG_ACTION_READ"
      116e90b23f74d303e8d607c7a7d54f60f14ab9f2

    Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43a73a50b352cd3df25b3ced72033942a6a0f919
Author: Kay Sievers <kay@vrfy.org>
Date:   Fri Jul 6 09:50:09 2012 -0700

    kmsg: add the facility number to the syslog prefix

    After the recent split of facility and level into separate variables,
    we miss the facility value (always 0 for kernel-originated messages)
    in the syslog prefix.

    On Tue, Jul 3, 2012 at 12:45 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
    > Static checkers complain about the impossible condition here.
    >
    > In 084681d14e ('printk: flush continuation lines immediately to
    > console'), we changed msg->level from being a u16 to being an unsigned
    > 3 bit bitfield.

    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3f5a5f27153228569f3396049838e9727dae86e
Author: Kay Sievers <kay@vrfy.org>
Date:   Fri Jul 6 09:50:09 2012 -0700

    kmsg: escape the backslash character while exporting data

    Non-printable characters in the log data are hex-escaped to ensure safe
    post processing. We need to escape a backslash we find in the data, to be
    able to distinguish it from a backslash we add for the escaping.

    Also escape the non-printable character 127.

    Thanks to Miloslav Trmac for the heads up.

    Reported-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c53d819c71c63fdc91f30a59164583f68e2d63a
Author: liu chuansheng <chuansheng.liu@intel.com>
Date:   Fri Jul 6 09:50:08 2012 -0700

    printk: replacing the raw_spin_lock/unlock with raw_spin_lock/unlock_irq

    In function devkmsg_read/writev/llseek/poll/open()..., the function
    raw_spin_lock/unlock is used, there is potential deadlock case happening.
    CPU1: thread1 doing the cat /dev/kmsg:
            raw_spin_lock(&logbuf_lock);
            while (user->seq == log_next_seq) {
    when thread1 run here, at this time one interrupt is coming on CPU1 and running
    based on this thread,if the interrupt handle called the printk which need the
    logbuf_lock spin also, it will cause deadlock.

    So we should use raw_spin_lock/unlock_irq here.

    Acked-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f0f4af59cb07bcf44d3c07a9e8c26df54d9fff8
Author: Randy Dunlap <rdunlap@xenotime.net>
Date:   Sat Jun 30 15:37:24 2012 -0700

    printk.c: fix kernel-doc warnings

    Fix kernel-doc warnings in printk.c: use correct parameter name.

      Warning(kernel/printk.c:2429): No description found for parameter 'buf'
      Warning(kernel/printk.c:2429): Excess function parameter 'line' description in 'kmsg_dump_get_buffer'

    Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit d36208227d03c44c0a74cd702cc94528162e1703
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Fri Jun 29 11:40:11 2012 -0400

    printk: Optimize if statement logic where newline exists

    In reviewing Kay's fix up patch: "printk: Have printk() never buffer its
    data", I found two if statements that could be combined and optimized.

    Put together the two 'cont.len && cont.owner == current' if statements
    into a single one, and check if we need to call cont_add(). This also
    removes the unneeded double cont_flush() calls.

    Link: http://lkml.kernel.org/r/1340869133.876.10.camel@mop

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 084681d14e429cb6192262ac7437f00e2c02f26a
Author: Kay Sievers <kay@vrfy.org>
Date:   Thu Jun 28 09:38:53 2012 +0200

    printk: flush continuation lines immediately to console

    Continuation lines are buffered internally, intended to merge the
    chunked printk()s into a single record, and to isolate potentially
    racy continuation users from usual terminated line users.

    This though, has the effect that partial lines are not printed to
    the console in the moment they are emitted. In case the kernel
    crashes in the meantime, the potentially interesting printed
    information would never reach the consoles.

    Here we share the continuation buffer with the console copy logic,
    and partial lines are always immediately flushed to the available
    consoles. They are still buffered internally to improve the
    readability and integrity of the messages and minimize the amount
    of needed record headers to store.

    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Tested-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 116e90b23f74d303e8d607c7a7d54f60f14ab9f2
Author: Jan Beulich <JBeulich@suse.com>
Date:   Fri Jun 22 16:36:09 2012 +0100

    syslog: fill buffer with more than a single message for SYSLOG_ACTION_READ

    The recent changes to the printk buffer management resulted in
    SYSLOG_ACTION_READ to only return a single message, whereas previously
    the buffer would get filled as much as possible. As, when too small to
    fit everything, filling it to the last byte would be pretty ugly with
    the new code, the patch arranges for as many messages as possible to
    get returned in a single invocation. User space tools in at least all
    SLES versions depend on the old behavior.

    This at once addresses the issue attempted to get fixed with commit
    b56a39ac263e5b8cafedd551a49c2105e68b98c2 ("printk: return -EINVAL if
    the message len is bigger than the buf size"), and since that commit
    widened the possibility for losing a message altogether, the patch
    here assumes that this other commit would get reverted first
    (otherwise the patch here won't apply).

    Furthermore, this patch also addresses the problem dealt with in
    commit 4a77a5a06ec66ed05199b301e7c25f42f979afdc ("printk: use mutex
    lock to stop syslog_seq from going wild"), so I'd recommend reverting
    that one too (albeit there's no direct collision between the two).

    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Kay Sievers <kay@vrfy.org>
    Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fda135c908d0f38a0167adcbd71094572e3059b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jun 26 12:35:24 2012 -0700

    Revert "printk: return -EINVAL if the message len is bigger than the buf size"

    This reverts commit b56a39ac263e5b8cafedd551a49c2105e68b98c2.

    A better patch from Jan will follow this to resolve the issue.

    Acked-by: Kay Sievers <kay@vrfy.org>
    Cc: Fengguang Wu <wfg@linux.intel.com>
    Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Cc: Jan Beulich <JBeulich@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4661e3568a7d14a93d4e428d246cdb86f4bac6e7
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Jun 22 17:12:19 2012 -0400

    printk: fix regression in SYSLOG_ACTION_CLEAR

    Commit 7ff9554bb578ba02166071d2d487b7fc7d860d62 (printk: convert
    byte-buffer to variable-length record buffer) introduced a regression
    by accidentally removing a "break" statement from inside the big
    switch in printk's do_syslog().  The symptom of this bug is that the
    "dmesg -C" command doesn't only clear the kernel's log buffer; it also
    disables console logging.

    This patch (as1561) fixes the regression by adding the missing
    "break".

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b56a39ac263e5b8cafedd551a49c2105e68b98c2
Author: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Date:   Sat Jun 16 12:40:55 2012 +0800

    printk: return -EINVAL if the message len is bigger than the buf size

    Just like what devkmsg_read() does, return -EINVAL if the message len is
    bigger than the buf size, or it will trigger a segfault error.

    Acked-by: Kay Sievers <kay@vrfy.org>
    Acked-by: Fengguang Wu <wfg@linux.intel.com>
    Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a77a5a06ec66ed05199b301e7c25f42f979afdc
Author: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Date:   Sat Jun 16 21:21:51 2012 +0800

    printk: use mutex lock to stop syslog_seq from going wild

    Although syslog_seq and log_next_seq stuff are protected by logbuf_lock
    spin log, it's not enough. Say we have two processes A and B, and let
    syslog_seq = N, while log_next_seq = N + 1, and the two processes both
    come to syslog_print at almost the same time. And No matter which
    process get the spin lock first, it will increase syslog_seq by one,
    then release spin lock; thus later, another process increase syslog_seq
    by one again. In this case, syslog_seq is bigger than syslog_next_seq.
    And latter, it would make:
       wait_event_interruptiable(log_wait, syslog != log_next_seq)
    don't wait any more even there is no new write comes. Thus it introduce
    a infinite loop reading.

    I can easily see this kind of issue by the following steps:
      # cat /proc/kmsg # at meantime, I don't kill rsyslog
                       # So they are the two processes.
      # xinit          # I added drm.debug=6 in the kernel parameter line,
                       # so that it will produce lots of message and let that
                       # issue happen

    It's 100% reproducable on my side. And my disk will be filled up by
    /var/log/messages in a quite short time.

    So, introduce a mutex_lock to stop syslog_seq from going wild just like
    what devkmsg_read() does. It does fix this issue as expected.

    v2: use mutex_lock_interruptiable() instead (comments from Kay)

    Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Reviewed-by: Fengguang Wu <fengguang.wu@intel.com>
    Acked-By: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2ae715d66bf4becfb85eb84b7150e23cf27df30
Author: Kay Sievers <kay@vrfy.org>
Date:   Fri Jun 15 14:07:51 2012 +0200

    kmsg - kmsg_dump() use iterator to receive log buffer content

    Provide an iterator to receive the log buffer content, and convert all
    kmsg_dump() users to it.

    The structured data in the kmsg buffer now contains binary data, which
    should no longer be copied verbatim to the kmsg_dump() users.

    The iterator should provide reliable access to the buffer data, and also
    supports proper log line-aware chunking of data while iterating.

    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Tested-by: Tony Luck <tony.luck@intel.com>
    Reported-by: Anton Vorontsov <anton.vorontsov@linaro.org>
    Tested-by: Anton Vorontsov <anton.vorontsov@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ebb017de9d59a18c3ff9648270e8f6abaa93438
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Tue Jun 5 08:52:34 2012 +0200

    printk: Fix alignment of buf causing crash on ARM EABI

    Commit 7ff9554bb578ba02166071d2d487b7fc7d860d62, printk: convert
    byte-buffer to variable-length record buffer, causes systems using
    EABI to crash very early in the boot cycle. The first entry in struct
    log is a u64, which for EABI must be 8 byte aligned.

    Make use of __alignof__() so the compiler to decide the alignment, but
    allow it to be overridden using CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS,
    for systems which can perform unaligned access and want to save
    a few bytes of space.

    Tested on Orion5x and Kirkwood.

    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Tested-by: Stephen Warren <swarren@wwwdotorg.org>
    Acked-by: Stephen Warren <swarren@wwwdotorg.org>
    Acked-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c313af145b9bc4fb8e8e0c83b8cfc10e1b894a50
Author: Kay Sievers <kay@vrfy.org>
Date:   Mon May 14 20:46:27 2012 +0200

    printk() - isolate KERN_CONT users from ordinary complete lines

    Arrange the continuation printk() buffering to be fully separated from the
    ordinary full line users.

    Limit the exposure to races and wrong printk() line merges to users of
    continuation only. Ordinary full line users racing against continuation
    users will no longer affect each other.

    Multiple continuation users from different threads, racing against each
    other will not wrongly be merged into a single line, but printed as
    separate lines.

    Test output of a kernel module which starts two separate threads which
    race against each other, one of them printing a single full terminated
    line:
      printk("(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)\n");

    The other one printing the line, every character separate in a
    continuation loop:
      printk("(C");
      for (i = 0; i < 58; i++)
              printk(KERN_CONT "C");
      printk(KERN_CONT "C)\n");

    Behavior of single and non-thread-aware printk() buffer:
      # modprobe printk-race
      printk test init
      (CC(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      CC(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      CC(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      CC(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC)
      (CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC)

    New behavior with separate and thread-aware continuation buffer:
      # modprobe printk-race
      printk test init
      (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      (CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC)
      (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
      (CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC)
      (CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC)

    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Joe Perches <joe@perches.com>
    Cc: Ted Ts'o <tytso@mit.edu>
    Cc: Ingo Molnar  <mingo@kernel.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ce9a7c0ac28561567fadedf1a99272e4970f740
Author: Kay Sievers <kay@vrfy.org>
Date:   Sun May 13 23:30:46 2012 +0200

    printk() - restore prefix/timestamp printing for multi-newline strings

    Calls like:
      printk("\n *** DEADLOCK ***\n\n");
    will print 3 properly indented, separated, syslog + timestamp prefixed lines in
    the log output.

    Reported-By: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fce677971e29ceaa7c569741fa9c685a7b1052a
Author: Randy Dunlap <rdunlap@xenotime.net>
Date:   Fri May 11 16:36:07 2012 -0700

    printk: add stub for prepend_timestamp()

    Add a stub for prepend_timestamp() when CONFIG_PRINTK is not
    enabled.  Fixes this build error:

    kernel/printk.c:1770:3: error: implicit declaration of function 'prepend_timestamp'

    Cc: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8450fca6ecdea38b5a882fdf6cd097e3ec8651c
Author: Stephen Warren <swarren@nvidia.com>
Date:   Thu May 10 16:14:33 2012 -0600

    printk: correctly align __log_buf

    __log_buf must be aligned, because a 64-bit value is written directly
    to it as part of struct log. Alignment of the log entries is typically
    handled by log_store(), but this only triggers for subsequent entries,
    not the very first (or wrapped) entries.

    Cc: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 649e6ee33f73ba1c4f2492c6de9aff2254b540cb
Author: Kay Sievers <kay@vrfy.org>
Date:   Thu May 10 04:30:45 2012 +0200

    printk() - restore timestamp printing at console output

    The output of the timestamps got lost with the conversion of the
    kmsg buffer to records; restore the old behavior.

    Document, that CONFIG_PRINTK_TIME now only controls the output of
    the timestamps in the syslog() system call and on the console, and
    not the recording of the timestamps.

    Cc: Joe Perches <joe@perches.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Sasha Levin <levinsasha928@gmail.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Reported-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c5d5ca51abd728c8de3be43ffd6bb00f977bfcd
Author: Kay Sievers <kay@vrfy.org>
Date:   Thu May 10 04:32:53 2012 +0200

    printk() - do not merge continuation lines of different threads

    This prevents the merging of printk() continuation lines of different
    threads, in the case they race against each other.

    It should properly isolate "atomic" single-line printk() users from
    continuation users, to make sure the single-line users will never be
    merged with the racy continuation ones.

    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f3a781d6fd81e397c3928c9af33f1fc63232db6
Author: Kay Sievers <kay@vrfy.org>
Date:   Wed May 9 01:37:51 2012 +0200

    printk - fix compilation for CONFIG_PRINTK=n

    Reported-by: Randy Dunlap <rdunlap@xenotime.net>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fc3249068c1ed87c6fd485f42ced24132405629
Author: Kay Sievers <kay@vrfy.org>
Date:   Tue May 8 13:04:17 2012 +0200

    kmsg: use do_div() to divide 64bit integer

    On Tue, May 8, 2012 at 10:02 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
    > kernel/built-in.o: In function `devkmsg_read':
    > printk.c:(.text+0x27e8): undefined reference to `__udivdi3'
    > Most probably the "msg->ts_nsec / 1000" since
    > ts_nsec is a u64 and this is a 32 bit build ...

    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e11fea92e13fb91c50bacca799a6131c81929986
Author: Kay Sievers <kay@vrfy.org>
Date:   Thu May 3 02:29:41 2012 +0200

    kmsg: export printk records to the /dev/kmsg interface

    Support for multiple concurrent readers of /dev/kmsg, with read(),
    seek(), poll() support. Output of message sequence numbers, to allow
    userspace log consumers to reliably reconnect and reconstruct their
    state at any given time. After open("/dev/kmsg"), read() always
    returns *all* buffered records. If only future messages should be
    read, SEEK_END can be used. In case records get overwritten while
    /dev/kmsg is held open, or records get faster overwritten than they
    are read, the next read() will return -EPIPE and the current reading
    position gets updated to the next available record. The passed
    sequence numbers allow the log consumer to calculate the amount of
    lost messages.

      [root@mop ~]# cat /dev/kmsg
      5,0,0;Linux version 3.4.0-rc1+ (kay@mop) (gcc version 4.7.0 20120315 ...
      6,159,423091;ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
      7,160,424069;pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7] (ignored)
       SUBSYSTEM=acpi
       DEVICE=+acpi:PNP0A03:00
      6,339,5140900;NET: Registered protocol family 10
      30,340,5690716;udevd[80]: starting version 181
      6,341,6081421;FDC 0 is a S82078B
      6,345,6154686;microcode: CPU0 sig=0x623, pf=0x0, revision=0x0
      7,346,6156968;sr 1:0:0:0: Attached scsi CD-ROM sr0
       SUBSYSTEM=scsi
       DEVICE=+scsi:1:0:0:0
      6,347,6289375;microcode: CPU1 sig=0x623, pf=0x0, revision=0x0

    Cc: Karel Zak <kzak@redhat.com>
    Tested-by: William Douglas <william.douglas@intel.com>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ff9554bb578ba02166071d2d487b7fc7d860d62
Author: Kay Sievers <kay@vrfy.org>
Date:   Thu May 3 02:29:13 2012 +0200

    printk: convert byte-buffer to variable-length record buffer

    - Record-based stream instead of the traditional byte stream
      buffer. All records carry a 64 bit timestamp, the syslog facility
      and priority in the record header.

    - Records consume almost the same amount, sometimes less memory than
      the traditional byte stream buffer (if printk_time is enabled). The record
      header is 16 bytes long, plus some padding bytes at the end if needed.
      The byte-stream buffer needed 3 chars for the syslog prefix, 15 char for
      the timestamp and a newline.

    - Buffer management is based on message sequence numbers. When records
      need to be discarded, the reading heads move on to the next full
      record. Unlike the byte-stream buffer, no old logged lines get
      truncated or partly overwritten by new ones. Sequence numbers also
      allow consumers of the log stream to get notified if any message in
      the stream they are about to read gets discarded during the time
      of reading.

    - Better buffered IO support for KERN_CONT continuation lines, when printk()
      is called multiple times for a single line. The use of KERN_CONT is now
      mandatory to use continuation; a few places in the kernel need trivial fixes
      here. The buffering could possibly be extended to per-cpu variables to allow
      better thread-safety for multiple printk() invocations for a single line.

    - Full-featured syslog facility value support. Different facilities
      can tag their messages. All userspace-injected messages enforce a
      facility value > 0 now, to be able to reliably distinguish them from
      the kernel-generated messages. Independent subsystems like a
      baseband processor running its own firmware, or a kernel-related
      userspace process can use their own unique facility values. Multiple
      independent log streams can co-exist that way in the same
      buffer. All share the same global sequence number counter to ensure
      proper ordering (and interleaving) and to allow the consumers of the
      log to reliably correlate the events from different facilities.

    Tested-by: William Douglas <william.douglas@intel.com>
    Signed-off-by: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95100358491abaa2e9a5483811370059bbca4645
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Nov 24 20:03:08 2011 +0100

    printk/tracing: Add console output tracing

    Add a printk.console trace point to record any printk
    messages into the trace, regardless of the current
    console loglevel. This can help correlate (existing)
    printk debugging with other tracing.

    Link: http://lkml.kernel.org/r/1322161388.5366.54.camel@jlt3.sipsolutions.net

    Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Change-Id: If820ddf7d597f22df252f57839279dc33d51fbec
11 files changed