18 Mar, 2016

40 commits

  • The traceoff_on_warning option doesn't have any effect on s390, powerpc,
    arm64, parisc, and sh because there are two different types of WARN
    implementations:

    1) The above mentioned architectures treat WARN() as a special case of a
    BUG() exception. They handle warnings in report_bug() in lib/bug.c.

    2) All other architectures just call warn_slowpath_*() directly. Their
    warnings are handled in warn_slowpath_common() in kernel/panic.c.

    Support traceoff_on_warning on all architectures and prevent any future
    divergence by using a single common function to emit the warning.

    Also remove the '()' from '%pS()', because the parentheses look funky:

    [ 45.607629] WARNING: at /root/warn_mod/warn_mod.c:17 .init_dummy+0x20/0x40 [warn_mod]()

    Reported-by: Chunyu Hu
    Signed-off-by: Josh Poimboeuf
    Acked-by: Heiko Carstens
    Tested-by: Prarit Bhargava
    Acked-by: Prarit Bhargava
    Acked-by: Steven Rostedt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josh Poimboeuf
     
  • This changes several users of manual "on"/"off" parsing to use
    strtobool.

    Some side-effects:
    - these uses will now parse y/n/1/0 meaningfully too
    - the early_param uses will now bubble up parse errors

    Signed-off-by: Kees Cook
    Acked-by: Heiko Carstens
    Acked-by: Michael Ellerman
    Cc: Amitkumar Karwar
    Cc: Andy Shevchenko
    Cc: Daniel Borkmann
    Cc: Joe Perches
    Cc: Kalle Valo
    Cc: Martin Schwidefsky
    Cc: Nishant Sarmukadam
    Cc: Rasmus Villemoes
    Cc: Steve French
    Cc: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kees Cook
     
  • Add support for "on" and "off" when converting to boolean.

    Signed-off-by: Kees Cook
    Cc: Amitkumar Karwar
    Cc: Andy Shevchenko
    Cc: Daniel Borkmann
    Cc: Heiko Carstens
    Cc: Joe Perches
    Cc: Kalle Valo
    Cc: Martin Schwidefsky
    Cc: Michael Ellerman
    Cc: Nishant Sarmukadam
    Cc: Rasmus Villemoes
    Cc: Steve French
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kees Cook
     
  • Some callers of strtobool() were passing a pointer to unterminated
    strings. In preparation of adding multi-character processing to
    kstrtobool(), update the callers to not pass single-character pointers,
    and switch to using the new kstrtobool_from_user() helper where
    possible.

    Signed-off-by: Kees Cook
    Cc: Amitkumar Karwar
    Cc: Nishant Sarmukadam
    Cc: Kalle Valo
    Cc: Steve French
    Cc: Andy Shevchenko
    Cc: Daniel Borkmann
    Cc: Heiko Carstens
    Cc: Joe Perches
    Cc: Kees Cook
    Cc: Martin Schwidefsky
    Cc: Michael Ellerman
    Cc: Rasmus Villemoes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kees Cook
     
  • Create the kstrtobool_from_user() helper and move strtobool() logic into
    the new kstrtobool() (matching all the other kstrto* functions).
    Provides an inline wrapper for existing strtobool() callers.

    Signed-off-by: Kees Cook
    Cc: Joe Perches
    Cc: Andy Shevchenko
    Cc: Rasmus Villemoes
    Cc: Daniel Borkmann
    Cc: Amitkumar Karwar
    Cc: Nishant Sarmukadam
    Cc: Kalle Valo
    Cc: Steve French
    Cc: Michael Ellerman
    Cc: Heiko Carstens
    Cc: Martin Schwidefsky
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kees Cook
     
  • Sometimes gcc mysteriously doesn't inline
    very small functions we expect to be inlined. See

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122

    With this .config:
    http://busybox.net/~vda/kernel_config_OPTIMIZE_INLINING_and_Os,
    the following functions get deinlined many times.
    Examples of disassembly:

    (24 copies, 108 calls):
    66 8b 07 mov (%rdi),%ax
    55 push %rbp
    48 89 e5 mov %rsp,%rbp
    86 e0 xchg %ah,%al
    5d pop %rbp
    c3 retq

    (25 copies, 181 calls):
    8b 07 mov (%rdi),%eax
    55 push %rbp
    48 89 e5 mov %rsp,%rbp
    0f c8 bswap %eax
    5d pop %rbp
    c3 retq

    (23 copies, 94 calls):
    48 8b 07 mov (%rdi),%rax
    55 push %rbp
    48 89 e5 mov %rsp,%rbp
    48 0f c8 bswap %rax
    5d pop %rbp
    c3 retq

    (2 copies, 11 calls):
    89 f8 mov %edi,%eax
    55 push %rbp
    c1 ef 08 shr $0x8,%edi
    c1 e0 08 shl $0x8,%eax
    09 c7 or %eax,%edi
    48 89 e5 mov %rsp,%rbp
    66 89 3e mov %di,(%rsi)

    (8 copies, 43 calls):
    55 push %rbp
    0f cf bswap %edi
    89 3e mov %edi,(%rsi)
    48 89 e5 mov %rsp,%rbp
    5d pop %rbp
    c3 retq

    (26 copies, 157 calls):
    55 push %rbp
    48 0f cf bswap %rdi
    48 89 3e mov %rdi,(%rsi)
    48 89 e5 mov %rsp,%rbp
    5d pop %rbp
    c3 retq

    This patch fixes this via s/inline/__always_inline/.

    It only affects arches with efficient unaligned access insns, such as x86.
    (arched which lack such ops do not include linux/unaligned/access_ok.h)

    Code size decrease after the patch is ~8.5k:

    text data bss dec hex filename
    92197848 20826112 36417536 149441496 8e84bd8 vmlinux
    92189231 20826144 36417536 149432911 8e82a4f vmlinux6_unaligned_be_after

    Signed-off-by: Denys Vlasenko
    Acked-by: Ingo Molnar
    Cc: Thomas Graf
    Cc: Peter Zijlstra
    Cc: David Rientjes
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denys Vlasenko
     
  • Sometimes gcc mysteriously doesn't inline
    very small functions we expect to be inlined. See

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122

    With this .config:
    http://busybox.net/~vda/kernel_config_OPTIMIZE_INLINING_and_Os,
    the following functions get deinlined many times.
    Examples of disassembly:

    (12 copies, 51 calls):
    66 8b 07 mov (%rdi),%ax
    55 push %rbp
    48 89 e5 mov %rsp,%rbp
    86 e0 xchg %ah,%al
    5d pop %rbp
    c3 retq

    (12 copies, 135 calls):
    8b 07 mov (%rdi),%eax
    55 push %rbp
    48 89 e5 mov %rsp,%rbp
    0f c8 bswap %eax
    5d pop %rbp
    c3 retq

    (2 copies, 20 calls):
    48 8b 07 mov (%rdi),%rax
    55 push %rbp
    48 89 e5 mov %rsp,%rbp
    48 0f c8 bswap %rax
    5d pop %rbp
    c3 retq

    (16 copies, 146 calls):
    55 push %rbp
    89 f8 mov %edi,%eax
    86 e0 xchg %ah,%al
    48 89 e5 mov %rsp,%rbp
    5d pop %rbp
    c3 retq

    (43 copies, ~560 calls):
    55 push %rbp
    89 f8 mov %edi,%eax
    0f c8 bswap %eax
    48 89 e5 mov %rsp,%rbp
    5d pop %rbp
    c3 retq

    (21 copies, 119 calls):
    55 push %rbp
    48 89 f8 mov %rdi,%rax
    48 0f c8 bswap %rax
    48 89 e5 mov %rsp,%rbp
    5d pop %rbp
    c3 retq

    (6 copies, 47 calls):
    8b 07 mov (%rdi),%eax
    55 push %rbp
    48 89 e5 mov %rsp,%rbp
    0f c8 bswap %eax
    89 07 mov %eax,(%rdi)
    5d pop %rbp
    c3 retq

    This patch fixes this via s/inline/__always_inline/.
    Code size decrease after the patch is ~4.5k:

    text data bss dec hex filename
    92202377 20826112 36417536 149446025 8e85d89 vmlinux
    92197848 20826112 36417536 149441496 8e84bd8 vmlinux5_swap_after

    Signed-off-by: Denys Vlasenko
    Acked-by: Ingo Molnar
    Cc: Thomas Graf
    Cc: Peter Zijlstra
    Cc: David Rientjes
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denys Vlasenko
     
  • Sometimes gcc mysteriously doesn't inline
    very small functions we expect to be inlined. See

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122

    With this .config:
    http://busybox.net/~vda/kernel_config_OPTIMIZE_INLINING_and_Os,
    atomic_long_inc(), atomic_long_dec() and atomic_long_add()
    functions get deinlined about 40 times. Examples of disassembly:

    (21 copies, 147 calls):
    55 push %rbp
    48 89 e5 mov %rsp,%rbp
    f0 48 ff 07 lock incq (%rdi)
    5d pop %rbp
    c3 retq

    (4 copies, 14 calls) is similar to inc.

    (11 copies, 41 calls):
    55 push %rbp
    48 89 e5 mov %rsp,%rbp
    f0 48 01 3e lock add %rdi,(%rsi)
    5d pop %rbp
    c3 retq

    This patch fixes this via s/inline/__always_inline/.
    Code size decrease after the patch is ~1.3k:

    text data bss dec hex filename
    92203657 20826112 36417536 149447305 8e86289 vmlinux
    92202377 20826112 36417536 149446025 8e85d89 vmlinux4_atomiclong_after

    Signed-off-by: Denys Vlasenko
    Cc: Ingo Molnar
    Cc: Thomas Graf
    Cc: Peter Zijlstra
    Cc: David Rientjes
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denys Vlasenko
     
  • The new helper returns index of the mathing string in an array. We
    would use it here.

    Signed-off-by: Heikki Krogerus
    Signed-off-by: Andy Shevchenko
    Cc: Greg Kroah-Hartman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heikki Krogerus
     
  • The new helper returns index of the mathing string in an array. We
    would use it here.

    Signed-off-by: Andy Shevchenko
    Cc: "David S. Miller"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     
  • The new helper returns index of the mathing string in an array. We
    would use it here.

    Signed-off-by: Andy Shevchenko
    Acked-by: Tejun Heo
    Cc: Bartlomiej Zolnierkiewicz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     
  • The new helper returns index of the mathing string in an array. We
    would use it here.

    Signed-off-by: Andy Shevchenko
    Acked-by: Linus Walleij
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     
  • The new helper returns index of the mathing string in an array. We
    would use it here.

    Signed-off-by: Andy Shevchenko
    Cc: Sebastian Reichel
    Cc: Dmitry Eremin-Solenikov
    Cc: David Woodhouse
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     
  • The new helper returns index of the mathing string in an array. We
    would use it here.

    Signed-off-by: Andy Shevchenko
    Cc: David Airlie
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     
  • The new helper returns index of the mathing string in an array. We
    would use it here.

    Signed-off-by: Andy Shevchenko
    Acked-by: Linus Walleij
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     
  • The new helper returns index of the mathing string in an array. We
    would use it here.

    Signed-off-by: Andy Shevchenko
    Reviewed-by: Mika Westerberg
    Acked-by: Rafael J. Wysocki
    Cc: Rasmus Villemoes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     
  • Occasionally we have to search for an occurrence of a string in an array
    of strings. Make a simple helper for that purpose.

    Signed-off-by: Andy Shevchenko
    Cc: "David S. Miller"
    Cc: Bartlomiej Zolnierkiewicz
    Cc: David Airlie
    Cc: David Woodhouse
    Cc: Dmitry Eremin-Solenikov
    Cc: Greg Kroah-Hartman
    Cc: Heikki Krogerus
    Cc: Linus Walleij
    Cc: Mika Westerberg
    Cc: Rafael J. Wysocki
    Cc: Sebastian Reichel
    Cc: Tejun Heo
    Cc: Rasmus Villemoes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     
  • Without fix test crashes inside tagged iteration.

    Signed-off-by: Konstantin Khlebnikov
    Cc: Matthew Wilcox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Konstantin Khlebnikov
     
  • After calling radix_tree_iter_retry(), 'slot' will be set to NULL. This
    can cause radix_tree_next_slot() to dereference the NULL pointer. Add
    Konstantin Khlebnikov's test to the regression framework.

    Signed-off-by: Matthew Wilcox
    Reported-by: Konstantin Khlebnikov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Konstantin Khlebnikov
     
  • shmem likes to occasionally drop the lock, schedule, then reacqire the
    lock and continue with the iteration from the last place it left off.
    This is currently done with a pretty ugly goto. Introduce
    radix_tree_iter_next() and use it throughout shmem.c.

    [koct9i@gmail.com: fix bug in radix_tree_iter_next() for tagged iteration]
    Signed-off-by: Matthew Wilcox
    Cc: Hugh Dickins
    Signed-off-by: Konstantin Khlebnikov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     
  • Instead of a 'goto restart', we can now use radix_tree_iter_retry() to
    restart from our current position. This will make a difference when
    there are more ways to happen across an indirect pointer. And it
    eliminates some confusing gotos.

    [vbabka@suse.cz: remove now-obsolete-and-misleading comment]
    Signed-off-by: Matthew Wilcox
    Cc: Hugh Dickins
    Cc: Konstantin Khlebnikov
    Signed-off-by: Vlastimil Babka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     
  • Even though this is a 'can't happen' situation, use the new
    radix_tree_iter_retry() pattern to eliminate a goto.

    [akpm@linux-foundation.org: fix btrfs build]
    Signed-off-by: Matthew Wilcox
    Cc: Hugh Dickins
    Cc: Konstantin Khlebnikov
    Cc: Chris Mason
    Cc: Josef Bacik
    Cc: David Sterba
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     
  • This is debug code which is #if 0 out.

    Signed-off-by: Matthew Wilcox
    Cc: Johannes Weiner
    Cc: Matthew Wilcox
    Cc: "Kirill A. Shutemov"
    Cc: Ross Zwisler
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     
  • With huge pages, it is convenient to have the radix tree be able to
    return an entry that covers multiple indices. Previous attempts to deal
    with the problem have involved inserting N duplicate entries, which is a
    waste of memory and leads to problems trying to handle aliased tags, or
    probing the tree multiple times to find alternative entries which might
    cover the requested index.

    This approach inserts one canonical entry into the tree for a given
    range of indices, and may also insert other entries in order to ensure
    that lookups find the canonical entry.

    This solution only tolerates inserting powers of two that are greater
    than the fanout of the tree. If we wish to expand the radix tree's
    abilities to support large-ish pages that is less than the fanout at the
    penultimate level of the tree, then we would need to add one more step
    in lookup to ensure that any sibling nodes in the final level of the
    tree are dereferenced and we return the canonical entry that they
    reference.

    Signed-off-by: Matthew Wilcox
    Cc: Johannes Weiner
    Cc: Matthew Wilcox
    Cc: "Kirill A. Shutemov"
    Cc: Ross Zwisler
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     
  • When we introduce entries that can cover multiple indices, we will need
    to stop in __radix_tree_create based on the shift, not the height.
    Split out for ease of bisect.

    Signed-off-by: Matthew Wilcox
    Cc: Johannes Weiner
    Cc: Matthew Wilcox
    Cc: "Kirill A. Shutemov"
    Cc: Ross Zwisler
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     
  • Set the 'indirect_ptr' bit on all the pointers to internal nodes, not
    just on the root node. This enables the following patches to support
    multi-order entries in the radix tree. This patch is split out for ease
    of bisection.

    Signed-off-by: Matthew Wilcox
    Cc: Johannes Weiner
    Cc: Matthew Wilcox
    Cc: "Kirill A. Shutemov"
    Cc: Ross Zwisler
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     
  • This code is mostly from Andrew Morton and Nick Piggin; tarball downloaded
    from http://ozlabs.org/~akpm/rtth.tar.gz with sha1sum
    0ce679db9ec047296b5d1ff7a1dfaa03a7bef1bd

    Some small modifications were necessary to the test harness to fix the
    build with the current Linux source code.

    I also made minor modifications to automatically test the radix-tree.c
    and radix-tree.h files that are in the current source tree, as opposed
    to a copied and slightly modified version. I am sure more could be done
    to tidy up the harness, as well as adding more tests.

    [koct9i@gmail.com: fix compilation]
    Signed-off-by: Matthew Wilcox
    Cc: Shuah Khan
    Cc: Johannes Weiner
    Cc: Matthew Wilcox
    Cc: "Kirill A. Shutemov"
    Cc: Ross Zwisler
    Cc: Hugh Dickins
    Signed-off-by: Konstantin Khlebnikov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     
  • The radix-tree header uses the __ffs() function, which is defined in
    bitops.h. The current kernel headers implicitly include bitops.h, but
    the userspace test harness does not.

    Signed-off-by: Matthew Wilcox
    Cc: Johannes Weiner
    Cc: Matthew Wilcox
    Cc: "Kirill A. Shutemov"
    Cc: Ross Zwisler
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     
  • Christian Borntraeger reported that panic_on_warn doesn't have any
    effect on s390.

    The panic_on_warn feature was introduced with 9e3961a09798 ("kernel: add
    panic_on_warn"). However it did care only for the case when
    WANT_WARN_ON_SLOWPATH is defined. This is turn is only the case for
    architectures which do not have an own __WARN_TAINT defined.

    Other architectures which do have __WARN_TAINT defined call report_bug()
    for warnings within lib/bug.c which does not call panic() in case
    panic_on_warn is set.

    Let's simply enable the panic_on_warn feature by adding the same code
    like it was added to warn_slowpath_common() in panic.c.

    This enables panic_on_warn also for arm64, parisc, powerpc, s390 and sh.

    Signed-off-by: Heiko Carstens
    Reported-by: Christian Borntraeger
    Tested-by: Christian Borntraeger
    Acked-by: Prarit Bhargava
    Cc: Catalin Marinas
    Cc: Will Deacon
    Cc: "James E.J. Bottomley"
    Cc: Helge Deller
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Tested-by: Michael Ellerman (powerpc)
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     
  • hlist_bl_unhashed() and hlist_bl_empty() are all boolean functions, so
    return bool instead of int.

    Signed-off-by: Chen Gang
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chen Gang
     
  • Benjamin Romer is no longer a maintainer for the Unisys s-Par driver,
    presently in drivers/staging/unisys/.

    Signed-off-by: David Kershner
    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Kershner
     
  • This allows us to extract from the vmcore only the messages emitted
    since the last time the ring buffer was cleared. We just have to make
    sure its value is always up-to-date, when old messages are discarded to
    free space in log_make_free_space() for example.

    Signed-off-by: Zeyu Zhao
    Signed-off-by: Ivan Delalande
    Cc: Kay Sievers
    Cc: Neil Horman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ivan Delalande
     
  • have_callable_console() must also test CON_ENABLED bit, not just
    CON_ANYTIME. We may have disabled CON_ANYTIME console so printk can
    wrongly assume that it's safe to call_console_drivers().

    Signed-off-by: Sergey Senozhatsky
    Reviewed-by: Petr Mladek
    Cc: Jan Kara
    Cc: Tejun Heo
    Cc: Kyle McMartin
    Cc: Dave Jones
    Cc: Calvin Owens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sergey Senozhatsky
     
  • console_unlock() allows to cond_resched() if its caller has set
    `console_may_schedule' to 1, since 8d91f8b15361 ("printk: do
    cond_resched() between lines while outputting to consoles").

    The rules are:
    -- console_lock() always sets `console_may_schedule' to 1
    -- console_trylock() always sets `console_may_schedule' to 0

    However, console_trylock() callers (among them is printk()) do not
    always call printk() from atomic contexts, and some of them can
    cond_resched() in console_unlock(), so console_trylock() can set
    `console_may_schedule' to 1 for such processes.

    For !CONFIG_PREEMPT_COUNT kernels, however, console_trylock() always
    sets `console_may_schedule' to 0.

    It's possible to drop explicit preempt_disable()/preempt_enable() in
    vprintk_emit(), because console_unlock() and console_trylock() are now
    smart enough:
    a) console_unlock() does not cond_resched() when it's unsafe
    (console_trylock() takes care of that)
    b) console_unlock() does can_use_console() check.

    Signed-off-by: Sergey Senozhatsky
    Reviewed-by: Petr Mladek
    Cc: Jan Kara
    Cc: Tejun Heo
    Cc: Kyle McMartin
    Cc: Dave Jones
    Cc: Calvin Owens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sergey Senozhatsky
     
  • console_unlock() allows to cond_resched() if its caller has set
    `console_may_schedule' to 1 (this functionality is present since
    8d91f8b15361 ("printk: do cond_resched() between lines while outputting
    to consoles").

    The rules are:
    -- console_lock() always sets `console_may_schedule' to 1
    -- console_trylock() always sets `console_may_schedule' to 0

    printk() calls console_unlock() with preemption desabled, which
    basically can lead to RCU stalls, watchdog soft lockups, etc. if
    something is simultaneously calling printk() frequent enough (IOW,
    console_sem owner always has new data to send to console divers and
    can't leave console_unlock() for a long time).

    printk()->console_trylock() callers do not necessarily execute in atomic
    contexts, and some of them can cond_resched() in console_unlock().
    console_trylock() can set `console_may_schedule' to 1 (allow
    cond_resched() later in consoe_unlock()) when it's safe.

    This patch (of 3):

    vprintk_emit() disables preemption around console_trylock_for_printk()
    and console_unlock() calls for a strong reason -- can_use_console()
    check. The thing is that vprintl_emit() can be called on a CPU that is
    not fully brought up yet (!cpu_online()), which potentially can cause
    problems if console driver wants to access per-cpu data. A console
    driver can explicitly state that it's safe to call it from !online cpu
    by setting CON_ANYTIME bit in console ->flags. That's why for
    !cpu_online() can_use_console() iterates all the console to find out if
    there is a CON_ANYTIME console, otherwise console_unlock() must be
    avoided.

    can_use_console() ensures that console_unlock() call is safe in
    vprintk_emit() only; console_lock() and console_trylock() are not
    covered by this check. Even though call_console_drivers(), invoked from
    console_cont_flush() and console_unlock(), tests `!cpu_online() &&
    CON_ANYTIME' for_each_console(), it may be too late, which can result in
    messages loss.

    Assume that we have 2 cpus -- CPU0 is online, CPU1 is !online, and no
    CON_ANYTIME consoles available.

    CPU0 online CPU1 !online
    console_trylock()
    ...
    console_unlock()
    console_cont_flush
    spin_lock logbuf_lock
    if (!cont.len) {
    spin_unlock logbuf_lock
    return
    }
    for (;;) {
    vprintk_emit
    spin_lock logbuf_lock
    log_store
    spin_unlock logbuf_lock
    spin_lock logbuf_lock
    !console_trylock_for_printk msg_print_text
    return console_idx = log_next()
    console_seq++
    console_prev = msg->flags
    spin_unlock logbuf_lock

    call_console_drivers()
    for_each_console(con) {
    if (!cpu_online() &&
    !(con->flags & CON_ANYTIME))
    continue;
    }
    /*
    * no message printed, we lost it
    */
    vprintk_emit
    spin_lock logbuf_lock
    log_store
    spin_unlock logbuf_lock
    !console_trylock_for_printk
    return
    /*
    * go to the beginning of the loop,
    * find out there are new messages,
    * lose it
    */
    }

    console_trylock()/console_lock() call on CPU1 may come from cpu
    notifiers registered on that CPU. Since notifiers are not getting
    unregistered when CPU is going DOWN, all of the notifiers receive
    notifications during CPU UP. For example, on my x86_64, I see around 50
    notification sent from offline CPU to itself

    [swapper/2] from cpu:2 to:2 action:CPU_STARTING hotplug_hrtick
    [swapper/2] from cpu:2 to:2 action:CPU_STARTING blk_mq_main_cpu_notify
    [swapper/2] from cpu:2 to:2 action:CPU_STARTING blk_mq_queue_reinit_notify
    [swapper/2] from cpu:2 to:2 action:CPU_STARTING console_cpu_notify

    while doing
    echo 0 > /sys/devices/system/cpu/cpu2/online
    echo 1 > /sys/devices/system/cpu/cpu2/online

    So grabbing the console_sem lock while CPU is !online is possible,
    in theory.

    This patch moves can_use_console() check out of
    console_trylock_for_printk(). Instead it calls it in console_unlock(),
    so now console_lock()/console_unlock() are also 'protected' by
    can_use_console(). This also means that console_trylock_for_printk() is
    not really needed anymore and can be removed.

    Signed-off-by: Sergey Senozhatsky
    Reviewed-by: Petr Mladek
    Cc: Jan Kara
    Cc: Tejun Heo
    Cc: Kyle McMartin
    Cc: Dave Jones
    Cc: Calvin Owens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sergey Senozhatsky
     
  • The v850 port was removed by commits f606ddf42fd4 and 07a887d399b8 in
    2008. These #defines are not used in the current kernel.

    Signed-off-by: Rob Landley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rob Landley
     
  • There are various email addresses for me throughout the kernel. Use the
    one that will always be valid.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     
  • This has hit me a couple of times already. I would be debugging code
    and the system would simply hang and then reboot. Finally, I found that
    the problem was caused by WARN_ON_ONCE() and friends.

    The macro WARN_ON_ONCE(condition) is defined as:

    static bool __section(.data.unlikely) __warned;
    int __ret_warn_once = !!(condition);

    if (unlikely(__ret_warn_once))
    if (WARN_ON(!__warned))
    __warned = true;

    unlikely(__ret_warn_once);

    Which looks great and all. But what I have hit, is an issue when
    WARN_ON() itself hits the same WARN_ON_ONCE() code. Because, the
    variable __warned is not yet set. Then it too calls WARN_ON() and that
    triggers the warning again. It keeps doing this until the stack is
    overflowed and the system crashes.

    By setting __warned first before calling WARN_ON() makes the original
    WARN_ON_ONCE() really only warn once, and not an infinite amount of
    times if the WARN_ON() also triggers the warning.

    Signed-off-by: Steven Rostedt
    Acked-by: Peter Zijlstra (Intel)
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Steven Rostedt
     
  • arch/mn10300/kernel/fpu-nofpu.c:27:36: error: unknown type name 'elf_fpregset_t'
    int dump_fpu(struct pt_regs *regs, elf_fpregset_t *fpreg)

    Reported-by: kbuild test robot
    Cc: Josh Triplett
    Cc: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • CONFIG_BUG=n && CONFIG_GENERIC_BUG=y make no sense and things break:

    In file included from include/linux/page-flags.h:9:0,
    from kernel/bounds.c:9:
    include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list
    static inline int is_warning_bug(const struct bug_entry *bug)
    ^
    include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want
    include/linux/bug.h: In function 'is_warning_bug':
    >> include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type
    return bug->flags & BUGFLAG_WARNING;

    Reported-by: kbuild test robot
    Cc: Josh Triplett
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton