08 Apr, 2020

40 commits

  • There are several places where code is indented incorrectly. Fix these.

    Signed-off-by: Colin Ian King
    Signed-off-by: Andrew Morton
    Link: http://lkml.kernel.org/r/20200325135018.113431-1-colin.king@canonical.com
    Signed-off-by: Linus Torvalds

    Colin Ian King
     
  • kallsyms_lookup_name() and kallsyms_on_each_symbol() are exported to
    modules despite having no in-tree users and being wide open to abuse by
    out-of-tree modules that can use them as a method to invoke arbitrary
    non-exported kernel functions.

    Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol().

    Signed-off-by: Will Deacon
    Signed-off-by: Andrew Morton
    Reviewed-by: Greg Kroah-Hartman
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Masami Hiramatsu
    Reviewed-by: Quentin Perret
    Acked-by: Alexei Starovoitov
    Cc: Thomas Gleixner
    Cc: Frederic Weisbecker
    Cc: K.Prasad
    Cc: Miroslav Benes
    Cc: Petr Mladek
    Cc: Joe Lawrence
    Cc: Mathieu Desnoyers
    Link: http://lkml.kernel.org/r/20200221114404.14641-4-will@kernel.org
    Signed-off-by: Linus Torvalds

    Will Deacon
     
  • The 'data_breakpoint' test code is the only modular user of
    kallsyms_lookup_name(), which was exported as part of fixing the test in
    f60d24d2ad04 ("hw-breakpoints: Fix broken hw-breakpoint sample module").

    In preparation for un-exporting this symbol, switch the test over to using
    __symbol_get(), which can be used to place breakpoints on exported
    symbols.

    Signed-off-by: Will Deacon
    Signed-off-by: Andrew Morton
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Masami Hiramatsu
    Reviewed-by: Quentin Perret
    Cc: K.Prasad
    Cc: Thomas Gleixner
    Cc: Greg Kroah-Hartman
    Cc: Frederic Weisbecker
    Cc: Alexei Starovoitov
    Cc: Miroslav Benes
    Cc: Petr Mladek
    Cc: Joe Lawrence
    Link: http://lkml.kernel.org/r/20200221114404.14641-3-will@kernel.org
    Signed-off-by: Linus Torvalds

    Will Deacon
     
  • Patch series "Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()".

    Despite having just a single modular in-tree user that I could spot,
    kallsyms_lookup_name() is exported to modules and provides a mechanism
    for out-of-tree modules to access and invoke arbitrary, non-exported
    kernel symbols when kallsyms is enabled.

    This patch series fixes up that one user and unexports the symbol along
    with kallsyms_on_each_symbol(), since that could also be abused in a
    similar manner.

    I would like to avoid out-of-tree modules being easily able to call
    functions that are not exported. kallsyms_lookup_name() makes this
    trivial to the point that there is very little incentive to rework these
    modules to either use upstream interfaces correctly or propose
    functionality which may be otherwise missing upstream. Both of these
    latter solutions would be pre-requisites to upstreaming these modules, and
    the current state of things actively discourages that approach.

    The background here is that we are aiming for Android devices to be able
    to use a generic binary kernel image closely following upstream, with any
    vendor extensions coming in as kernel modules. In this case, we (Google)
    end up maintaining the binary module ABI within the scope of a single LTS
    kernel. Monitoring and managing the ABI surface is not feasible if it
    effectively includes all data and functions via kallsyms_lookup_name().
    Of course, we could just carry this patch in the Android kernel tree, but
    we're aiming to carry as little as possible (ideally nothing) and I think
    it's a sensible change in its own right. I'm surprised you object to it,
    in all honesty.

    Now, you could turn around and say "that's not upstream's problem", but it
    still seems highly undesirable to me to have an upstream bypass for
    exported symbols that isn't even used by upstream modules. It's ripe for
    abuse and encourages people to work outside of the upstream tree. The
    usual rule is that we don't export symbols without a user in the tree and
    that seems especially relevant in this case.

    Joe Lawrence said:

    : FWIW, kallsyms was historically used by the out-of-tree kpatch support
    : module to resolve external symbols as well as call set_memory_r{w,o}()
    : API. All of that support code has been merged upstream, so modern kpatch
    : modules* no longer leverage kallsyms by default.
    :
    : That said, there are still some users who still use the deprecated support
    : module with newer kernels, but that is not officially supported by the
    : project.

    This patch (of 3):

    Given the name of a kernel symbol, the 'data_breakpoint' test claims to
    "report any write operations on the kernel symbol". However, it creates
    the breakpoint using both HW_BREAKPOINT_W and HW_BREAKPOINT_R, which menas
    it also fires for read access.

    Drop HW_BREAKPOINT_R from the breakpoint attributes.

    Signed-off-by: Will Deacon
    Signed-off-by: Andrew Morton
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Masami Hiramatsu
    Reviewed-by: Quentin Perret
    Cc: K.Prasad
    Cc: Thomas Gleixner
    Cc: Greg Kroah-Hartman
    Cc: Frederic Weisbecker
    Cc: Alexei Starovoitov
    Cc: Miroslav Benes
    Cc: Petr Mladek
    Cc: Joe Lawrence
    Link: http://lkml.kernel.org/r/20200221114404.14641-2-will@kernel.org
    Signed-off-by: Linus Torvalds

    Will Deacon
     
  • Static executables don't need to free NULL pointer.

    It doesn't matter really because static executable is not common scenario
    but do it anyway out of pedantry.

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Andrew Morton
    Link: http://lkml.kernel.org/r/20200219185330.GA4933@avx2
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     
  • PT_INTERP ELF header can be spared if executable is static.

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Andrew Morton
    Link: http://lkml.kernel.org/r/20200219185012.GB4871@avx2
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     
  • "loc" variable became just a wrapper for PT_INTERP ELF header after main
    ELF header was moved to "bprm->buf". Delete it.

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Andrew Morton
    Link: http://lkml.kernel.org/r/20200219184847.GA4871@avx2
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     
  • Davidlohr Bueso pointed out that when CONFIG_DEBUG_LOCK_ALLOC is set
    ep_poll_safewake() can take several non-raw spinlocks after disabling
    interrupts. Since a spinlock can block in the -rt kernel, we can't take a
    spinlock after disabling interrupts. So let's re-work how we determine
    the nesting level such that it plays nicely with the -rt kernel.

    Let's introduce a 'nests' field in struct eventpoll that records the
    current nesting level during ep_poll_callback(). Then, if we nest again
    we can find the previous struct eventpoll that we were called from and
    increase our count by 1. The 'nests' field is protected by
    ep->poll_wait.lock.

    I've also moved the visited field to reduce the size of struct eventpoll
    from 184 bytes to 176 bytes on x86_64 for !CONFIG_DEBUG_LOCK_ALLOC, which
    is typical for a production config.

    Reported-by: Davidlohr Bueso
    Signed-off-by: Jason Baron
    Signed-off-by: Andrew Morton
    Reviewed-by: Davidlohr Bueso
    Cc: Roman Penyaev
    Cc: Eric Wong
    Cc: Al Viro
    Link: http://lkml.kernel.org/r/1582739816-13167-1-git-send-email-jbaron@akamai.com
    Signed-off-by: Linus Torvalds

    Jason Baron
     
  • This testcase repeats epollbug.c from the bug:

    https://bugzilla.kernel.org/show_bug.cgi?id=205933

    What it tests? It tests the race between epoll_ctl() and epoll_wait().
    New event mask passed to epoll_ctl() triggers wake up, which can be missed
    because of the bug described in the link. Reproduction is 100%, so easy
    to fix. Kudos, Max, for wonderful test case.

    Signed-off-by: Roman Penyaev
    Signed-off-by: Andrew Morton
    Cc: Max Neunhoeffer
    Cc: Jakub Kicinski
    Cc: Christopher Kohlhoff
    Cc: Davidlohr Bueso
    Cc: Jason Baron
    Cc: Jes Sorensen
    Link: http://lkml.kernel.org/r/20200214170211.561524-2-rpenyaev@suse.de
    Signed-off-by: Linus Torvalds

    Roman Penyaev
     
  • WARNING: function definition argument 'flags' should also have an identifier name
    #26: FILE: drivers/tty/serial/sh-sci.c:1348:
    + unsigned long uninitialized_var(flags);

    Special-case uninitialized_var() to prevent this.

    Signed-off-by: Joe Perches
    Signed-off-by: Andrew Morton
    Tested-by: Andrew Morton
    Link: http://lkml.kernel.org/r/7db7944761b0bd88c70eb17d4b7f40fe589e14ed.camel@perches.com
    Signed-off-by: Linus Torvalds

    Joe Perches
     
  • According to Devicetree maintainers (see Link: below), the Devicetree
    binding documents are preferrably licensed (GPL-2.0-only OR BSD-2-Clause).

    Let's check that. The actual check is a bit more relaxed, to allow more
    liberal but compatible licensing (e.g. GPL-2.0-or-later OR BSD-2-Clause).

    Signed-off-by: Lubomir Rintel
    Signed-off-by: Andrew Morton
    Acked-by: Joe Perches
    Acked-by: Laurent Pinchart
    Cc: Rob Herring
    Cc: Neil Armstrong
    Cc: Laurent Pinchart ,
    Cc: Jonas Karlman ,
    Cc: Jernej Skrabec ,
    Cc: Mark Rutland ,
    Cc: David Airlie
    Cc: Daniel Vetter ,
    Link: https://lore.kernel.org/lkml/20200108142132.GA4830@bogus/
    Link: http://lkml.kernel.org/r/20200309215153.38824-1-lkundrak@v3.sk
    Signed-off-by: Linus Torvalds

    Lubomir Rintel
     
  • The Gerrit Change-Id: entry is sometimes placed after a Signed-off-by:
    line. When this occurs, the Gerrit warning is not currently emitted as
    the first Signed-off-by: signature sets a flag to stop looking.

    Change the test to add a test for the --- patch separator and emit the
    warning before any before the --- and also before any diff file name.

    Signed-off-by: Joe Perches
    Signed-off-by: Andrew Morton
    Tested-by: John Stultz
    Link: http://lkml.kernel.org/r/2f6d5f8766fe7439a116c77ea8cc721a3f2d77a2.camel@perches.com
    Signed-off-by: Linus Torvalds

    Joe Perches
     
  • Linux kernel coding style requires a size of 8 characters for both TAB and
    indentation, and such value is embedded as magic value allover the
    checkpatch script.

    This makes hard to reuse the script by other projects with different
    requirements in their coding style (e.g. OpenOCD [1] requires TAB size of
    4 characters [2]).

    Replace the magic value 8 with a variable.

    Add a command-line option "--tab-size" to let the user select a
    TAB size value other than 8.

    [1] http://openocd.org/
    [2] http://openocd.org/doc/doxygen/html/stylec.html#styleformat

    Signed-off-by: Antonio Borneo
    Signed-off-by: Erik Ahlén
    Signed-off-by: Spencer Oliver
    Signed-off-by: Andrew Morton
    Cc: Joe Perches
    Link: http://lkml.kernel.org/r/20200122163852.124417-3-borneo.antonio@gmail.com
    Signed-off-by: Linus Torvalds

    Antonio Borneo
     
  • Commit 1574a29f8e76 ("checkpatch: allow multiple const * types") claims to
    support repetition of pattern "const *", but it actually allows only one
    extra instance.

    Check the following lines
    int a(char const * const x[]);
    int b(char const * const *x);
    int c(char const * const * const x[]);
    int d(char const * const * const *x);

    with command

    ./scripts/checkpatch.pl --show-types -f filename

    to find that only the first line passes the test, while a warning
    is triggered by the other 3 lines:

    WARNING:FUNCTION_ARGUMENTS: function definition argument
    'char const * const' should also have an identifier name

    The reason is that the pattern match halts at the second asterisk in the
    line, thus the remaining text starting with asterisk fails to match a
    valid name for a variable.

    Fixed by replacing "?" (Match 1 or 0 times) with "{0,4}" (Match no more
    than 4 times) in the regular expression. Fix also the similar test for
    types in unusual order.

    Fixes: 1574a29f8e76 ("checkpatch: allow multiple const * types")
    Signed-off-by: Antonio Borneo
    Signed-off-by: Andrew Morton
    Cc: Joe Perches
    Link: http://lkml.kernel.org/r/20200122163852.124417-1-borneo.antonio@gmail.com
    Signed-off-by: Linus Torvalds

    Antonio Borneo
     
  • Fix spelling of "concatenation".
    Don't use tab after space in indentation.

    Signed-off-by: Antonio Borneo
    Signed-off-by: Andrew Morton
    Cc: Joe Perches
    Link: http://lkml.kernel.org/r/20200122163852.124417-2-borneo.antonio@gmail.com
    Signed-off-by: Linus Torvalds

    Antonio Borneo
     
  • commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough' pseudo
    keyword for switch/case use") added the pseudo keyword so add a test for
    it to checkpatch.

    Warn on a patch or use --strict for files.

    Signed-off-by: Joe Perches
    Signed-off-by: Andrew Morton
    Link: http://lkml.kernel.org/r/8b6c1b9031ab9f3cdebada06b8d46467f1492d68.camel@perches.com
    Signed-off-by: Linus Torvalds

    Joe Perches
     
  • In order to support the get-lore-mbox.py tool described in [1], I ran:

    git format-patch --base= --cover-letter

    ... which generated a "base-commit: " tag at the end of the
    cover letter. However, checkpatch.pl generated an error upon encounting
    "base-commit:" in the cover letter:

    "ERROR: Please use git commit description style..."

    ... because it found the "commit" keyword, and failed to recognize that
    it was part of the "base-commit" phrase, and as such, should not be
    subjected to the same commit description style rules.

    Update checkpatch.pl to include a special case for "base-commit:" (at the
    start of the line, possibly with some leading whitespace) so that that tag
    no longer generates a checkpatch error.

    [1] https://lwn.net/Articles/811528/ "Better tools for kernel
    developers"

    Suggested-by: Joe Perches
    Signed-off-by: John Hubbard
    Signed-off-by: Andrew Morton
    Acked-by: Joe Perches
    Cc: Andy Whitcroft
    Cc: Konstantin Ryabitsev
    Cc: Jonathan Corbet
    Link: http://lkml.kernel.org/r/20200213055004.69235-2-jhubbard@nvidia.com
    Signed-off-by: Linus Torvalds

    John Hubbard
     
  • This adds a warning when a YAML file is lacking a SPDX header on first
    line, or it uses incorrect commenting style.

    Currently the only YAML files in the tree are Devicetree binding
    documents.

    Signed-off-by: Lubomir Rintel
    Signed-off-by: Andrew Morton
    Acked-by: Joe Perches
    Cc: Rob Herring
    Link: http://lkml.kernel.org/r/20200129123356.388669-1-lkundrak@v3.sk
    Signed-off-by: Linus Torvalds

    Lubomir Rintel
     
  • About 2% of the last 100K commits have email addresses that include an
    RFC2822 compliant comment like:

    Peter Zijlstra (Intel)

    checkpatch currently does a comparison of the complete name and address to
    the submitted author to determine if the author has signed-off and emits a
    warning if the exact email names and addresses do not match.

    Unfortunately, the author email address can be written without the comment
    like:

    Peter Zijlstra

    Add logic to compare the comment stripped email addresses to avoid this
    warning.

    Reported-by: Peter Zijlstra
    Signed-off-by: Joe Perches
    Signed-off-by: Andrew Morton
    Acked-by: Peter Zijlstra (Intel)
    Link: http://lkml.kernel.org/r/ebaa2f7c8f94e25520981945cddcc1982e70e072.camel@perches.com
    Signed-off-by: Linus Torvalds

    Joe Perches
     
  • Clang warns:

    ../lib/dynamic_debug.c:1034:24: warning: array comparison always
    evaluates to false [-Wtautological-compare]
    if (__start___verbose == __stop___verbose) {
    ^
    1 warning generated.

    These are not true arrays, they are linker defined symbols, which are just
    addresses. Using the address of operator silences the warning and does
    not change the resulting assembly with either clang/ld.lld or gcc/ld
    (tested with diff + objdump -Dr).

    Suggested-by: Nick Desaulniers
    Signed-off-by: Nathan Chancellor
    Signed-off-by: Andrew Morton
    Acked-by: Jason Baron
    Link: https://github.com/ClangBuiltLinux/linux/issues/894
    Link: http://lkml.kernel.org/r/20200220051320.10739-1-natechancellor@gmail.com
    Signed-off-by: Linus Torvalds

    Nathan Chancellor
     
  • GENMASK() and GENMASK_ULL() are supposed to be called with the high bit as
    the first argument and the low bit as the second argument. Mixing them
    will return a mask with zero bits set.

    Recent commits show getting this wrong is not uncommon, see e.g. commit
    aa4c0c9091b0 ("net: stmmac: Fix misuses of GENMASK macro") and commit
    9bdd7bb3a844 ("clocksource/drivers/npcm: Fix misuse of GENMASK macro").

    To prevent such mistakes from appearing again, add compile time sanity
    checking to the arguments of GENMASK() and GENMASK_ULL(). If both
    arguments are known at compile time, and the low bit is higher than the
    high bit, break the build to detect the mistake immediately.

    Since GENMASK() is used in declarations, BUILD_BUG_ON_ZERO() must be used
    instead of BUILD_BUG_ON().

    __builtin_constant_p does not evaluate is argument, it only checks if it
    is a constant or not at compile time, and __builtin_choose_expr does not
    evaluate the expression that is not chosen. Therefore, GENMASK(x++, 0)
    does only evaluate x++ once.

    Commit 95b980d62d52 ("linux/bits.h: make BIT(), GENMASK(), and friends
    available in assembly") made the macros in linux/bits.h available in
    assembly. Since BUILD_BUG_OR_ZERO() is not asm compatible, disable the
    checks if the file is included in an asm file.

    Due to bugs in GCC versions before 4.9 [0], disable the check if building
    with a too old GCC compiler.

    [0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449

    Signed-off-by: Rikard Falkeborn
    Signed-off-by: Andrew Morton
    Reviewed-by: Masahiro Yamada
    Reviewed-by: Kees Cook
    Cc: Borislav Petkov
    Cc: Geert Uytterhoeven
    Cc: Haren Myneni
    Cc: Joe Perches
    Cc: Johannes Berg
    Cc: lkml
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/20200308193954.2372399-1-rikard.falkeborn@gmail.com
    Signed-off-by: Linus Torvalds

    Rikard Falkeborn
     
  • The "info" pointer has already been dereferenced so checking here is too
    late. Fortunately, we never pass NULL pointers to the
    test_kmod_put_module() function so the test can simply be removed.

    Signed-off-by: Dan Carpenter
    Signed-off-by: Andrew Morton
    Acked-by: Luis Chamberlain
    Link: http://lkml.kernel.org/r/20200228092452.vwkhthsn77nrxdy6@kili.mountain
    Signed-off-by: Linus Torvalds

    Dan Carpenter
     
  • Leave blank space between the right-hand and left-hand side of the
    assignment to meet the kernel coding style better.

    Signed-off-by: chenqiwu
    Signed-off-by: Andrew Morton
    Reviewed-by: Michel Lespinasse
    Link: http://lkml.kernel.org/r/1582621140-25850-1-git-send-email-qiwuchen55@gmail.com
    Signed-off-by: Linus Torvalds

    chenqiwu
     
  • Commit 30544ed5de43 ("lib/bitmap: introduce bitmap_replace() helper")
    introduced some new test cases to the test_bitmap.c module. Among these
    it also introduced an (unused) definition. Let's make use of
    EXP2_IN_BITS.

    Reported-by: Alex Shi
    Signed-off-by: Andy Shevchenko
    Signed-off-by: Andrew Morton
    Reviewed-by: Alex Shi
    Link: http://lkml.kernel.org/r/20200121151847.75223-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     
  • "vm_committed_as.count" could be accessed concurrently as reported by
    KCSAN,

    BUG: KCSAN: data-race in __vm_enough_memory / percpu_counter_add_batch

    write to 0xffffffff9451c538 of 8 bytes by task 65879 on cpu 35:
    percpu_counter_add_batch+0x83/0xd0
    percpu_counter_add_batch at lib/percpu_counter.c:91
    __vm_enough_memory+0xb9/0x260
    dup_mm+0x3a4/0x8f0
    copy_process+0x2458/0x3240
    _do_fork+0xaa/0x9f0
    __do_sys_clone+0x125/0x160
    __x64_sys_clone+0x70/0x90
    do_syscall_64+0x91/0xb05
    entry_SYSCALL_64_after_hwframe+0x49/0xbe

    read to 0xffffffff9451c538 of 8 bytes by task 66773 on cpu 19:
    __vm_enough_memory+0x199/0x260
    percpu_counter_read_positive at include/linux/percpu_counter.h:81
    (inlined by) __vm_enough_memory at mm/util.c:839
    mmap_region+0x1b2/0xa10
    do_mmap+0x45c/0x700
    vm_mmap_pgoff+0xc0/0x130
    ksys_mmap_pgoff+0x6e/0x300
    __x64_sys_mmap+0x33/0x40
    do_syscall_64+0x91/0xb05
    entry_SYSCALL_64_after_hwframe+0x49/0xbe

    The read is outside percpu_counter::lock critical section which results in
    a data race. Fix it by adding a READ_ONCE() in
    percpu_counter_read_positive() which could also service as the existing
    compiler memory barrier.

    Signed-off-by: Qian Cai
    Signed-off-by: Andrew Morton
    Acked-by: Marco Elver
    Link: http://lkml.kernel.org/r/1582302724-2804-1-git-send-email-cai@lca.pw
    Signed-off-by: Linus Torvalds

    Qian Cai
     
  • filter_irq_stacks() can be used by other tools (e.g. KMSAN), so it needs
    to be moved to a common location. lib/stackdepot.c seems a good place, as
    filter_irq_stacks() is usually applied to the output of
    stack_trace_save().

    This patch has been previously mailed as part of KMSAN RFC patch series.

    [glider@google.co: nds32: linker script: add SOFTIRQENTRY_TEXT\
    Link: http://lkml.kernel.org/r/20200311121002.241430-1-glider@google.com
    [glider@google.com: add IRQENTRY_TEXT and SOFTIRQENTRY_TEXT to linker script]
    Link: http://lkml.kernel.org/r/20200311121124.243352-1-glider@google.com
    Signed-off-by: Alexander Potapenko
    Signed-off-by: Andrew Morton
    Cc: Vegard Nossum
    Cc: Dmitry Vyukov
    Cc: Marco Elver
    Cc: Andrey Konovalov
    Cc: Andrey Ryabinin
    Cc: Arnd Bergmann
    Cc: Sergey Senozhatsky
    Link: http://lkml.kernel.org/r/20200220141916.55455-3-glider@google.com
    Signed-off-by: Linus Torvalds

    Alexander Potapenko
     
  • Clang may replace stackdepot_memcmp() with a call to instrumented bcmp(),
    which is exactly what we wanted to avoid creating stackdepot_memcmp().
    Building the file with -fno-builtin prevents such optimizations.

    This patch has been previously mailed as part of KMSAN RFC patch series.

    Signed-off-by: Alexander Potapenko
    Signed-off-by: Andrew Morton
    Cc: Vegard Nossum
    Cc: Dmitry Vyukov
    Cc: Marco Elver
    Cc: Andrey Konovalov
    Cc: Sergey Senozhatsky
    Cc: Arnd Bergmann
    Cc: Andrey Ryabinin
    Link: http://lkml.kernel.org/r/20200220141916.55455-2-glider@google.com
    Signed-off-by: Linus Torvalds

    Alexander Potapenko
     
  • Avoid crashes on corrupted stack ids. Despite stack ID corruption may
    indicate other bugs in the program, we'd better fail gracefully on such
    IDs instead of crashing the kernel.

    This patch has been previously mailed as part of KMSAN RFC patch series.

    Link: http://lkml.kernel.org/r/20200220141916.55455-1-glider@google.com
    Signed-off-by: Alexander Potapenko
    Cc: Vegard Nossum
    Cc: Dmitry Vyukov
    Cc: Marco Elver
    Cc: Andrey Konovalov
    Cc: Andrey Ryabinin
    Cc: Arnd Bergmann
    Cc: Sergey Senozhatsky
    From: Dan Carpenter
    Subject: lib/stackdepot.c: fix a condition in stack_depot_fetch()

    We should check for a NULL pointer first before adding the offset.
    Otherwise if the pointer is NULL and the offset is non-zero, it will lead
    to an Oops.

    Fixes: d45048e65a59 ("lib/stackdepot.c: check depot_index before accessing the stack slab")
    Signed-off-by: Dan Carpenter
    Signed-off-by: Andrew Morton
    Acked-by: Alexander Potapenko
    Link: http://lkml.kernel.org/r/20200312113006.GA20562@mwanda
    Signed-off-by: Linus Torvalds

    Alexander Potapenko
     
  • The tests for initializing a variable defined between a switch statement's
    test and its first "case" statement are currently not initialized in
    Clang[1] nor the proposed auto-initialization feature in GCC.

    We should retain the test (so that we can evaluate compiler fixes), but
    mark it as an "expected fail". The rest of the kernel source will be
    adjusted to avoid this corner case.

    Also disable -Wswitch-unreachable for the test so that the intentionally
    broken code won't trigger warnings for GCC (nor future Clang) when
    initialization happens this unhandled place.

    [1] https://bugs.llvm.org/show_bug.cgi?id=44916

    Suggested-by: Alexander Potapenko
    Signed-off-by: Kees Cook
    Signed-off-by: Andrew Morton
    Cc: Jann Horn
    Cc: Ard Biesheuvel
    Link: http://lkml.kernel.org/r/202002191358.2897A07C6@keescook
    Signed-off-by: Linus Torvalds

    Kees Cook
     
  • Add the missing closing parenthesis to the description for the to_buffer
    parameter of sg_copy_buffer().

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Cc: Akinobu Mita

    Geert Uytterhoeven
     
  • The current codebase makes use of the zero-length array language extension
    to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning in
    case the flexible array does not occur last in the structure, which will
    help us prevent some kind of undefined behavior bugs from being
    inadvertenly introduced[3] to the codebase from now on.

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: Andrew Morton
    Link: http://lkml.kernel.org/r/20200211205948.GA26459@embeddedor
    Signed-off-by: Linus Torvalds

    Gustavo A. R. Silva
     
  • The current codebase makes use of the zero-length array language extension
    to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning in
    case the flexible array does not occur last in the structure, which will
    help us prevent some kind of undefined behavior bugs from being
    inadvertenly introduced[3] to the codebase from now on.

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: Andrew Morton
    Link: http://lkml.kernel.org/r/20200211205813.GA25602@embeddedor
    Signed-off-by: Linus Torvalds

    Gustavo A. R. Silva
     
  • The current codebase makes use of the zero-length array language extension
    to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning in
    case the flexible array does not occur last in the structure, which will
    help us prevent some kind of undefined behavior bugs from being
    inadvertenly introduced[3] to the codebase from now on.

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: Andrew Morton
    Link: http://lkml.kernel.org/r/20200211205620.GA24694@embeddedor
    Signed-off-by: Linus Torvalds

    Gustavo A. R. Silva
     
  • The current codebase makes use of the zero-length array language extension
    to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning in
    case the flexible array does not occur last in the structure, which will
    help us prevent some kind of undefined behavior bugs from being
    inadvertenly introduced[3] to the codebase from now on.

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: Andrew Morton
    Link: http://lkml.kernel.org/r/20200211205119.GA21234@embeddedor
    Signed-off-by: Linus Torvalds

    Gustavo A. R. Silva
     
  • file_path= defines file or directory to open
    lock_inode=Y set lock_rwsem_ptr to inode->i_rwsem
    lock_mapping=Y set lock_rwsem_ptr to mapping->i_mmap_rwsem
    lock_sb_umount=Y set lock_rwsem_ptr to sb->s_umount

    This gives safe and simple way to see how system reacts to contention of
    common vfs locks and how syscalls depend on them directly or indirectly.

    For example to block s_umount for 60 seconds:
    # modprobe test_lockup file_path=. lock_sb_umount time_secs=60 state=S

    This is useful for checking/testing scalability issues like this:
    https://lore.kernel.org/lkml/158497590858.7371.9311902565121473436.stgit@buzz/

    Signed-off-by: Konstantin Khlebnikov
    Signed-off-by: Andrew Morton
    Cc: Colin Ian King
    Cc: Greg Kroah-Hartman
    Cc: Guenter Roeck
    Cc: Kees Cook
    Cc: Peter Zijlstra
    Cc: Petr Mladek
    Cc: Sasha Levin
    Cc: Sergey Senozhatsky
    Cc: Steven Rostedt
    Link: http://lkml.kernel.org/r/158498153964.5621.83061779039255681.stgit@buzz
    Signed-off-by: Linus Torvalds

    Konstantin Khlebnikov
     
  • There is a spelling mistake in a pr_notice message. Fix it.

    Signed-off-by: Colin Ian King
    Signed-off-by: Andrew Morton
    Cc: Greg Kroah-Hartman
    Cc: Guenter Roeck
    Cc: Kees Cook
    Cc: Konstantin Khlebnikov
    Cc: Peter Zijlstra
    Cc: Petr Mladek
    Cc: Sasha Levin
    Cc: Sergey Senozhatsky
    Cc: Steven Rostedt
    Link: http://lkml.kernel.org/r/20200221155145.79522-1-colin.king@canonical.com
    Signed-off-by: Linus Torvalds

    Colin Ian King
     
  • CONFIG_TEST_LOCKUP=m adds module "test_lockup" that helps to make sure
    that watchdogs and lockup detectors are working properly.

    Depending on module parameters test_lockup could emulate soft or hard
    lockup, "hung task", hold arbitrary lock, allocate bunch of pages.

    Also it could generate series of lockups with cooling-down periods, in
    this way it could be used as "ping" for locks or page allocator. Loop
    checks signals between iteration thus could be stopped by ^C.

    # modinfo test_lockup
    ...
    parm: time_secs:lockup time in seconds, default 0 (uint)
    parm: time_nsecs:nanoseconds part of lockup time, default 0 (uint)
    parm: cooldown_secs:cooldown time between iterations in seconds, default 0 (uint)
    parm: cooldown_nsecs:nanoseconds part of cooldown, default 0 (uint)
    parm: iterations:lockup iterations, default 1 (uint)
    parm: all_cpus:trigger lockup at all cpus at once (bool)
    parm: state:wait in 'R' running (default), 'D' uninterruptible, 'K' killable, 'S' interruptible state (charp)
    parm: use_hrtimer:use high-resolution timer for sleeping (bool)
    parm: iowait:account sleep time as iowait (bool)
    parm: lock_read:lock read-write locks for read (bool)
    parm: lock_single:acquire locks only at one cpu (bool)
    parm: reacquire_locks:release and reacquire locks/irq/preempt between iterations (bool)
    parm: touch_softlockup:touch soft-lockup watchdog between iterations (bool)
    parm: touch_hardlockup:touch hard-lockup watchdog between iterations (bool)
    parm: call_cond_resched:call cond_resched() between iterations (bool)
    parm: measure_lock_wait:measure lock wait time (bool)
    parm: lock_wait_threshold:print lock wait time longer than this in nanoseconds, default off (ulong)
    parm: disable_irq:disable interrupts: generate hard-lockups (bool)
    parm: disable_softirq:disable bottom-half irq handlers (bool)
    parm: disable_preempt:disable preemption: generate soft-lockups (bool)
    parm: lock_rcu:grab rcu_read_lock: generate rcu stalls (bool)
    parm: lock_mmap_sem:lock mm->mmap_sem: block procfs interfaces (bool)
    parm: lock_rwsem_ptr:lock rw_semaphore at address (ulong)
    parm: lock_mutex_ptr:lock mutex at address (ulong)
    parm: lock_spinlock_ptr:lock spinlock at address (ulong)
    parm: lock_rwlock_ptr:lock rwlock at address (ulong)
    parm: alloc_pages_nr:allocate and free pages under locks (uint)
    parm: alloc_pages_order:page order to allocate (uint)
    parm: alloc_pages_gfp:allocate pages with this gfp_mask, default GFP_KERNEL (uint)
    parm: alloc_pages_atomic:allocate pages with GFP_ATOMIC (bool)
    parm: reallocate_pages:free and allocate pages between iterations (bool)

    Parameters for locking by address are unsafe and taints kernel. With
    CONFIG_DEBUG_SPINLOCK=y they at least check magics for embedded spinlocks.

    Examples:

    task hang in D-state:
    modprobe test_lockup time_secs=1 iterations=60 state=D

    task hang in io-wait D-state:
    modprobe test_lockup time_secs=1 iterations=60 state=D iowait

    softlockup:
    modprobe test_lockup time_secs=1 iterations=60 state=R

    hardlockup:
    modprobe test_lockup time_secs=1 iterations=60 state=R disable_irq

    system-wide hardlockup:
    modprobe test_lockup time_secs=1 iterations=60 state=R \
    disable_irq all_cpus

    rcu stall:
    modprobe test_lockup time_secs=1 iterations=60 state=R \
    lock_rcu touch_softlockup

    lock mmap_sem / block procfs interfaces:
    modprobe test_lockup time_secs=1 iterations=60 state=S lock_mmap_sem

    lock tasklist_lock for read / block forks:
    TASKLIST_LOCK=$(awk '$3 == "tasklist_lock" {print "0x"$1}' /proc/kallsyms)
    modprobe test_lockup time_secs=1 iterations=60 state=R \
    disable_irq lock_read lock_rwlock_ptr=$TASKLIST_LOCK

    lock namespace_sem / block vfs mount operations:
    NAMESPACE_SEM=$(awk '$3 == "namespace_sem" {print "0x"$1}' /proc/kallsyms)
    modprobe test_lockup time_secs=1 iterations=60 state=S \
    lock_rwsem_ptr=$NAMESPACE_SEM

    lock cgroup mutex / block cgroup operations:
    CGROUP_MUTEX=$(awk '$3 == "cgroup_mutex" {print "0x"$1}' /proc/kallsyms)
    modprobe test_lockup time_secs=1 iterations=60 state=S \
    lock_mutex_ptr=$CGROUP_MUTEX

    ping cgroup_mutex every second and measure maximum lock wait time:
    modprobe test_lockup cooldown_secs=1 iterations=60 state=S \
    lock_mutex_ptr=$CGROUP_MUTEX reacquire_locks measure_lock_wait

    [linux@roeck-us.net: rename disable_irq to fix build error]
    Link: http://lkml.kernel.org/r/20200317133614.23152-1-linux@roeck-us.net
    Signed-off-by: Konstantin Khlebnikov
    Signed-off-by: Guenter Roeck
    Signed-off-by: Andrew Morton
    Cc: Sasha Levin
    Cc: Petr Mladek
    Cc: Kees Cook
    Cc: Peter Zijlstra
    Cc: Greg Kroah-Hartman
    Cc: Steven Rostedt
    Cc: Sergey Senozhatsky
    Cc: Dmitry Monakhov
    Cc: Guenter Roeck
    Link: http://lkml.kernel.org/r/158132859146.2797.525923171323227836.stgit@buzz
    Signed-off-by: Linus Torvalds

    Konstantin Khlebnikov
     
  • With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports:

    drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled

    This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr()
    from the user_access_begin/end critical region (i.e, with SMAP disabled).

    While it's probably harmless in this case, in general we like to avoid
    extra function calls in SMAP-disabled regions because it can open up
    inadvertent security holes.

    Fix the warning by changing the sign extension helpers to __always_inline.
    This convinces GCC to inline gen8_canonical_addr().

    The sign extension functions are trivial anyway, so it makes sense to
    always inline them. With my test optimize-for-size-based config, this
    actually shrinks the text size of i915_gem_execbuffer.o by 45 bytes -- and
    no change for vmlinux.

    Reported-by: Randy Dunlap
    Signed-off-by: Josh Poimboeuf
    Signed-off-by: Andrew Morton
    Cc: Peter Zijlstra
    Cc: Al Viro
    Cc: Chris Wilson
    Link: http://lkml.kernel.org/r/740179324b2b18b750b16295c48357f00b5fa9ed.1582982020.git.jpoimboe@redhat.com
    Signed-off-by: Linus Torvalds

    Josh Poimboeuf
     
  • The MAINTAINERS file header has never shown a preferred order for the
    section entries but scripts/parse-maintainers.pl added a preferred order
    with commit 61f741645a35 ("parse-maintainers: Add section pattern
    sorting")

    Commit 5cdbec108fd2 ("parse-maintainers: Do not sort section content by
    default") changed the preferred order to be a bit more sensible.

    Update the MAINTAINERS section description block to use this preferred
    section entry ordering.

    Add a slightly better description for the N: entry too.

    Signed-off-by: Joe Perches
    Signed-off-by: Andrew Morton
    Reviewed-by: Andy Shevchenko
    Link: http://lkml.kernel.org/r/5aa5aad6fb1678230c260337dc066cd449a2bf32.camel@perches.com
    Signed-off-by: Linus Torvalds

    Joe Perches
     
  • compiletime_assert() uses __LINE__ to create a unique function name. This
    means that if you have more than one BUILD_BUG_ON() in the same source
    line (which can happen if they appear e.g. in a macro), then the error
    message from the compiler might output the wrong condition.

    For this source file:

    #include

    #define macro() \
    BUILD_BUG_ON(1); \
    BUILD_BUG_ON(0);

    void foo()
    {
    macro();
    }

    gcc would output:

    ./include/linux/compiler.h:350:38: error: call to `__compiletime_assert_9' declared with attribute error: BUILD_BUG_ON failed: 0
    _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)

    However, it was not the BUILD_BUG_ON(0) that failed, so it should say 1
    instead of 0. With this patch, we use __COUNTER__ instead of __LINE__, so
    each BUILD_BUG_ON() gets a different function name and the correct
    condition is printed:

    ./include/linux/compiler.h:350:38: error: call to `__compiletime_assert_0' declared with attribute error: BUILD_BUG_ON failed: 1
    _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)

    Signed-off-by: Vegard Nossum
    Signed-off-by: Andrew Morton
    Reviewed-by: Masahiro Yamada
    Reviewed-by: Daniel Santos
    Cc: Rasmus Villemoes
    Cc: Ian Abbott
    Cc: Joe Perches
    Link: http://lkml.kernel.org/r/20200331112637.25047-1-vegard.nossum@oracle.com
    Signed-off-by: Linus Torvalds

    Vegard Nossum