Eric Lee / smarc-ti-linux-kernel

04 Apr, 2014

5 commits

  • 72581487a   printk: fix one circular lockdep warning about console_lock ... Browse Code »
    2

    Fix a warning about possible circular locking dependency.

    If do in following sequence:

    enter suspend -> resume -> plug-out CPUx (echo 0 > cpux/online)

    lockdep will show warning as following:

    ======================================================
    [ INFO: possible circular locking dependency detected ]
    3.10.0 #2 Tainted: G O
    -------------------------------------------------------
    sh/1271 is trying to acquire lock:
    (console_lock){+.+.+.}, at: console_cpu_notify+0x20/0x2c
    but task is already holding lock:
    (cpu_hotplug.lock){+.+.+.}, at: cpu_hotplug_begin+0x2c/0x58
    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:
    -> #2 (cpu_hotplug.lock){+.+.+.}:
    lock_acquire+0x98/0x12c
    mutex_lock_nested+0x50/0x3d8
    cpu_hotplug_begin+0x2c/0x58
    _cpu_up+0x24/0x154
    cpu_up+0x64/0x84
    smp_init+0x9c/0xd4
    kernel_init_freeable+0x78/0x1c8
    kernel_init+0x8/0xe4
    ret_from_fork+0x14/0x2c

    -> #1 (cpu_add_remove_lock){+.+.+.}:
    lock_acquire+0x98/0x12c
    mutex_lock_nested+0x50/0x3d8
    disable_nonboot_cpus+0x8/0xe8
    suspend_devices_and_enter+0x214/0x448
    pm_suspend+0x1e4/0x284
    try_to_suspend+0xa4/0xbc
    process_one_work+0x1c4/0x4fc
    worker_thread+0x138/0x37c
    kthread+0xa4/0xb0
    ret_from_fork+0x14/0x2c

    -> #0 (console_lock){+.+.+.}:
    __lock_acquire+0x1b38/0x1b80
    lock_acquire+0x98/0x12c
    console_lock+0x54/0x68
    console_cpu_notify+0x20/0x2c
    notifier_call_chain+0x44/0x84
    __cpu_notify+0x2c/0x48
    cpu_notify_nofail+0x8/0x14
    _cpu_down+0xf4/0x258
    cpu_down+0x24/0x40
    store_online+0x30/0x74
    dev_attr_store+0x18/0x24
    sysfs_write_file+0x16c/0x19c
    vfs_write+0xb4/0x190
    SyS_write+0x3c/0x70
    ret_fast_syscall+0x0/0x48

    Chain exists of:
    console_lock --> cpu_add_remove_lock --> cpu_hotplug.lock

    Possible unsafe locking scenario:
    CPU0 CPU1
    ---- ----
    lock(cpu_hotplug.lock);
    lock(cpu_add_remove_lock);
    lock(cpu_hotplug.lock);
    lock(console_lock);
    *** DEADLOCK ***

    There are three locks involved in two sequence:
    a) pm suspend:
    console_lock (@suspend_console())
    cpu_add_remove_lock (@disable_nonboot_cpus())
    cpu_hotplug.lock (@_cpu_down())
    b) Plug-out CPUx:
    cpu_add_remove_lock (@(cpu_down())
    cpu_hotplug.lock (@_cpu_down())
    console_lock (@console_cpu_notify()) => Lockdeps prints warning log.

    There should be not real deadlock, as flag of console_suspended can
    protect this.

    Although console_suspend() releases console_sem, it doesn't tell lockdep
    about it. That results in the lockdep warning about circular locking
    when doing the following: enter suspend -> resume -> plug-out CPUx (echo
    0 > cpux/online)

    Fix the problem by telling lockdep we actually released the semaphore in
    console_suspend() and acquired it again in console_resume().

    Signed-off-by: Jane Li
    Reviewed-by: Jan Kara
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jane Li
     
  • fce6e0338   printk: do not compute the size of the message twice ... Browse Code »

    This is just a tiny optimization. It removes duplicate computation of
    the message size.

    Signed-off-by: Petr Mladek
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    Cc: Jan Kara
    Cc: Michal Hocko
    Cc: Kay Sievers
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Petr Mladek
     
  • 39b25109b   printk: use also the last bytes in the ring buffer ... Browse Code »

    It seems that we have newer used the last byte in the ring buffer. In
    fact, we have newer used the last 4 bytes because of padding.

    First problem is in the check for free space. The exact number of free
    bytes is enough to store the length of data.

    Second problem is in the check where the ring buffer is rotated. The
    left side counts the first unused index. It is unused, so it might be
    the same as the size of the buffer.

    Note that the first problem has to be fixed together with the second
    one. Otherwise, the buffer is rotated even when there is enough space
    on the end of the buffer. Then the beginning of the buffer is rewritten
    and valid entries get corrupted.

    Signed-off-by: Petr Mladek
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    Cc: Jan Kara
    Cc: Michal Hocko
    Cc: Kay Sievers
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Petr Mladek
     
  • e8c42d36a   printk: add comment about tricky check for text buffer size ... Browse Code »

    There is no check for potential "text_len" overflow. It is not needed
    because only valid level is detected. It took me some time to
    understand why. It would deserve a comment ;-)

    Signed-off-by: Petr Mladek
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    Cc: Jan Kara
    Cc: Michal Hocko
    Cc: Kay Sievers
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Petr Mladek
     
  • c64730b26   printk: remove obsolete check for log level "c" ... Browse Code »

    The kernel log level "c" was removed in commit 61e99ab8e35a ("printk:
    remove the now unnecessary "C" annotation for KERN_CONT"). It is no
    longer detected in printk_get_level(). Hence we do not need to check it
    in vprintk_emit.

    Signed-off-by: Petr Mladek
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    Cc: Jan Kara
    Cc: Michal Hocko
    Cc: Kay Sievers
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Petr Mladek
     

18 Feb, 2014

1 commit

  • e4178d809   printk: fix syslog() overflowing user buffer ... Browse Code »

    This is not a buffer overflow in the traditional sense: we don't
    overflow any *kernel* buffers, but we do mis-count the amount of data we
    copy back to user space for the SYSLOG_ACTION_READ_ALL case.

    In particular, if the user buffer is too small to hold everything, and
    *if* there is a continuation line at just the right place, we can end up
    giving the user more data than he asked for.

    The reason is that we first count up the number of bytes all the log
    records contains, then we walk the records again until we've skipped the
    records at the beginning that won't fit, and then we walk the rest of
    the records and copy them to the user space buffer.

    And in between that "skip the initial records that won't fit" and the
    "copy the records that *will* fit to user space", we reset the 'prev'
    variable that contained the record information for the last record not
    copied. That meant that when we started copying to user space, we now
    had a different character count than what we had originally calculated
    in the first record walk-through.

    The fix is to simply not clear the 'prev' flags value (in both cases
    where we had the same logic: syslog_print_all and kmsg_dump_get_buffer:
    the latter is used for pstore-like dumping)

    Reported-and-tested-by: Debabrata Banerjee
    Acked-by: Kay Sievers
    Cc: Greg Kroah-Hartman
    Cc: Jeff Mahoney
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

24 Jan, 2014

1 commit

  • 1d3fa3703   printk: flush conflicting continuation line ... Browse Code »

    An earlier newline was missing and current print is from different task.
    In this scenario flush the continuation line and store this line
    seperatly.

    This patch fix the below scenario of timestamp interleaving,
    [ 28.154370 ] read_word_reg : reg[0x 3], reg[0x 4] data [0x 642]
    [ 28.155428 ] uart disconnect
    [ 31.947341 ] dvfs[cpufreq.c]:plug-in cpu done
    [ 28.155445 ] UART detached : send switch state 201
    [ 32.014112 ] read_reg : reg[0x 3] data[0x21]

    [akpm@linux-foundation.org: simplify and condense the code]
    Signed-off-by: Arun KS
    Signed-off-by: Arun KS
    Cc: Joe Perches
    Cc: Tejun Heo
    Cc: Frederic Weisbecker
    Cc: Paul Gortmaker
    Cc: Kay Sievers
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arun KS
     

22 Jan, 2014

1 commit

  • 9da791dfa   kernel/printk/printk.c: use memblock apis for early memory allocations ... Browse Code »

    Switch to memblock interfaces for early memory allocator instead of
    bootmem allocator. No functional change in beahvior than what it is in
    current code from bootmem users points of view.

    Archs already converted to NO_BOOTMEM now directly use memblock
    interfaces instead of bootmem wrappers build on top of memblock. And
    the archs which still uses bootmem, these new apis just fallback to
    exiting bootmem APIs.

    Signed-off-by: Grygorii Strashko
    Signed-off-by: Santosh Shilimkar
    Cc: Yinghai Lu
    Cc: Tejun Heo
    Cc: "Rafael J. Wysocki"
    Cc: Arnd Bergmann
    Cc: Christoph Lameter
    Cc: Greg Kroah-Hartman
    Cc: H. Peter Anvin
    Cc: Johannes Weiner
    Cc: KAMEZAWA Hiroyuki
    Cc: Konrad Rzeszutek Wilk
    Cc: Michal Hocko
    Cc: Paul Walmsley
    Cc: Pavel Machek
    Cc: Russell King
    Cc: Tony Lindgren
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Santosh Shilimkar
     

13 Nov, 2013

4 commits

04 Sep, 2013

1 commit

  • 2f01ea908   Merge tag 'tty-3.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty ... Browse Code »

    Pull tty/serial driver patches from Greg KH:
    "Here's the big tty/serial driver pull request for 3.12-rc1.

    Lots of n_tty reworks to resolve some very long-standing issues,
    removing the 3-4 different locks that were taken for every character.
    This code has been beaten on for a long time in linux-next with no
    reported regressions.

    Other than that, a range of serial and tty driver updates and
    revisions. Full details in the shortlog"

    * tag 'tty-3.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (226 commits)
    hvc_xen: Remove unnecessary __GFP_ZERO from kzalloc
    serial: imx: initialize the local variable
    tty: ar933x_uart: add device tree support and binding documentation
    tty: ar933x_uart: allow to build the driver as a module
    ARM: dts: msm: Update uartdm compatible strings
    devicetree: serial: Document msm_serial bindings
    serial: unify serial bindings into a single dir
    serial: fsl-imx-uart: Cleanup duplicate device tree binding
    tty: ar933x_uart: use config_enabled() macro to clean up ifdefs
    tty: ar933x_uart: remove superfluous assignment of ar933x_uart_driver.nr
    tty: ar933x_uart: use the clk API to get the uart clock
    tty: serial: cpm_uart: Adding proper request of GPIO used by cpm_uart driver
    serial: sirf: fix the amount of serial ports
    serial: sirf: define macro for some magic numbers of USP
    serial: icom: move array overflow checks earlier
    TTY: amiserial, remove unnecessary platform_set_drvdata()
    serial: st-asc: remove unnecessary platform_set_drvdata()
    msm_serial: Send more than 1 character on the console w/ UARTDM
    msm_serial: Add support for non-GSBI UARTDM devices
    msm_serial: Switch clock consumer strings and simplify code
    ...

    Linus Torvalds
     

07 Aug, 2013

1 commit

  • 2cfe6c4ac   printk: Fix return of braille_register_console() ... Browse Code »

    Some of my configs I test with have CONFIG_A11Y_BRAILLE_CONSOLE set.
    When I started testing against v3.11-rc4 my console went bonkers. Using
    ktest to bisect the issue, it came down to:

    commit bbeddf52a "printk: move braille console support into separate
    braille.[ch] files"

    Looking into the patch I found the problem. It's with the return of
    braille_register_console(). As anything other than NULL is considered a
    failure.

    But for those of us that have CONFIG_A11Y_BRAILLE_CONSOLE set but do not
    define a "brl" or "brl=" on the command line, we still may want a
    console that those with sight can still use.

    Return NULL (success) if "brl" or "brl=" is not on the console line.

    Signed-off-by: Steven Rostedt
    Acked-by: Joe Perches
    Cc: Andrew Morton
    Signed-off-by: Linus Torvalds

    Steven Rostedt
     

05 Aug, 2013

1 commit

  • 16cf48a6d   register_console: prevent adding the same console twice ... Browse Code »

    This patch guards the console_drivers list to be corrupted. The
    for_each_console() macro insist on a strictly forward list ended by NULL:

    con0->next->con1->next->NULL

    Without this patch it may happen easily to destroy this list for example by
    adding 'earlyprintk' twice, especially on embedded devices where the early
    console is often a single static instance. This will result in the following
    list:

    con0->next->con0

    This in turn will result in an endless loop in console_unlock() later on by
    printing the first __log_buf line endlessly.

    Signed-off-by: Andreas Bießmann
    Cc: Kay Sievers
    Cc: Ben Hutchings
    Signed-off-by: Greg Kroah-Hartman

    Andreas Bießmann
     

01 Aug, 2013

5 commits