1. 14 Jun, 2020 6 commits
  2. 12 Jun, 2020 8 commits
    • Linus Torvalds's avatar
      Merge tag 'locking-kcsan-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · b791d1bd
      Linus Torvalds authored
      Pull the Kernel Concurrency Sanitizer from Thomas Gleixner:
       "The Kernel Concurrency Sanitizer (KCSAN) is a dynamic race detector,
        which relies on compile-time instrumentation, and uses a
        watchpoint-based sampling approach to detect races.
      
        The feature was under development for quite some time and has already
        found legitimate bugs.
      
        Unfortunately it comes with a limitation, which was only understood
        late in the development cycle:
      
           It requires an up to date CLANG-11 compiler
      
        CLANG-11 is not yet released (scheduled for June), but it's the only
        compiler today which handles the kernel requirements and especially
        the annotations of functions to exclude them from KCSAN
        instrumentation correctly.
      
        These annotations really need to work so that low level entry code and
        especially int3 text poke handling can be completely isolated.
      
        A detailed discussion of the requirements and compiler issues can be
        found here:
      
          https://lore.kernel.org/lkml/CANpmjNMTsY_8241bS7=XAfqvZHFLrVEkv_uM4aDUWE_kh3Rvbw@mail.gmail.com/
      
        We came to the conclusion that trying to work around compiler
        limitations and bugs again would end up in a major trainwreck, so
        requiring a working compiler seemed to be the best choice.
      
        For Continous Integration purposes the compiler restriction is
        manageable and that's where most xxSAN reports come from.
      
        For a change this limitation might make GCC people actually look at
        their bugs. Some issues with CSAN in GCC are 7 years old and one has
        been 'fixed' 3 years ago with a half baken solution which 'solved' the
        reported issue but not the underlying problem.
      
        The KCSAN developers also ponder to use a GCC plugin to become
        independent, but that's not something which will show up in a few
        days.
      
        Blocking KCSAN until wide spread compiler support is available is not
        a really good alternative because the continuous growth of lockless
        optimizations in the kernel demands proper tooling support"
      
      * tag 'locking-kcsan-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (76 commits)
        compiler_types.h, kasan: Use __SANITIZE_ADDRESS__ instead of CONFIG_KASAN to decide inlining
        compiler.h: Move function attributes to compiler_types.h
        compiler.h: Avoid nested statement expression in data_race()
        compiler.h: Remove data_race() and unnecessary checks from {READ,WRITE}_ONCE()
        kcsan: Update Documentation to change supported compilers
        kcsan: Remove 'noinline' from __no_kcsan_or_inline
        kcsan: Pass option tsan-instrument-read-before-write to Clang
        kcsan: Support distinguishing volatile accesses
        kcsan: Restrict supported compilers
        kcsan: Avoid inserting __tsan_func_entry/exit if possible
        ubsan, kcsan: Don't combine sanitizer with kcov on clang
        objtool, kcsan: Add kcsan_disable_current() and kcsan_enable_current_nowarn()
        kcsan: Add __kcsan_{enable,disable}_current() variants
        checkpatch: Warn about data_race() without comment
        kcsan: Use GFP_ATOMIC under spin lock
        Improve KCSAN documentation a bit
        kcsan: Make reporting aware of KCSAN tests
        kcsan: Fix function matching in report
        kcsan: Change data_race() to no longer require marking racing accesses
        kcsan: Move kcsan_{disable,enable}_current() to kcsan-checks.h
        ...
      b791d1bd
    • Linus Torvalds's avatar
      Merge tag 'locking-urgent-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 9716e57a
      Linus Torvalds authored
      Pull atomics rework from Thomas Gleixner:
       "Peter Zijlstras rework of atomics and fallbacks. This solves two
        problems:
      
         1) Compilers uninline small atomic_* static inline functions which
            can expose them to instrumentation.
      
         2) The instrumentation of atomic primitives was done at the
            architecture level while composites or fallbacks were provided at
            the generic level. As a result there are no uninstrumented
            variants of the fallbacks.
      
        Both issues were in the way of fully isolating fragile entry code
        pathes and especially the text poke int3 handler which is prone to an
        endless recursion problem when anything in that code path is about to
        be instrumented. This was always a problem, but got elevated due to
        the new batch mode updates of tracing.
      
        The solution is to mark the functions __always_inline and to flip the
        fallback and instrumentation so the non-instrumented variants are at
        the architecture level and the instrumentation is done in generic
        code.
      
        The latter introduces another fallback variant which will go away once
        all architectures have been moved over to arch_atomic_*"
      
      * tag 'locking-urgent-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        locking/atomics: Flip fallbacks and instrumentation
        asm-generic/atomic: Use __always_inline for fallback wrappers
      9716e57a
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · b1a62749
      Linus Torvalds authored
      Pull updates from Andrew Morton:
       "A few fixes and stragglers.
      
        Subsystems affected by this patch series: mm/memory-failure, ocfs2,
        lib/lzo, misc"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        amdgpu: a NULL ->mm does not mean a thread is a kthread
        lib/lzo: fix ambiguous encoding bug in lzo-rle
        ocfs2: fix build failure when TCP/IP is disabled
        mm/memory-failure: send SIGBUS(BUS_MCEERR_AR) only to current thread
        mm/memory-failure: prioritize prctl(PR_MCE_KILL) over vm.memory_failure_early_kill
      b1a62749
    • Christoph Hellwig's avatar
      amdgpu: a NULL ->mm does not mean a thread is a kthread · 8449d150
      Christoph Hellwig authored
      Use the proper API instead.
      
      Fixes: 70539bd7 ("drm/amd: Update MEC HQD loading code for KFD")
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Tested-by: default avatarJens Axboe <axboe@kernel.dk>
      Reviewed-by: default avatarFelix Kuehling <Felix.Kuehling@amd.com>
      Reviewed-by: default avatarJens Axboe <axboe@kernel.dk>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Link: http://lkml.kernel.org/r/20200404094101.672954-1-hch@lst.de
      Link: http://lkml.kernel.org/r/20200404094101.672954-2-hch@lst.deSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8449d150
    • Dave Rodgman's avatar
      lib/lzo: fix ambiguous encoding bug in lzo-rle · b5265c81
      Dave Rodgman authored
      In some rare cases, for input data over 32 KB, lzo-rle could encode two
      different inputs to the same compressed representation, so that
      decompression is then ambiguous (i.e.  data may be corrupted - although
      zram is not affected because it operates over 4 KB pages).
      
      This modifies the compressor without changing the decompressor or the
      bitstream format, such that:
      
       - there is no change to how data produced by the old compressor is
         decompressed
      
       - an old decompressor will correctly decode data from the updated
         compressor
      
       - performance and compression ratio are not affected
      
       - we avoid introducing a new bitstream format
      
      In testing over 12.8M real-world files totalling 903 GB, three files
      were affected by this bug.  I also constructed 37M semi-random 64 KB
      files totalling 2.27 TB, and saw no affected files.  Finally I tested
      over files constructed to contain each of the ~1024 possible bad input
      sequences; for all of these cases, updated lzo-rle worked correctly.
      
      There is no significant impact to performance or compression ratio.
      Signed-off-by: default avatarDave Rodgman <dave.rodgman@arm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Dave Rodgman <dave.rodgman@arm.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Markus F.X.J. Oberhumer <markus@oberhumer.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Chao Yu <yuchao0@huawei.com>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/20200507100203.29785-1-dave.rodgman@arm.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b5265c81
    • Tom Seewald's avatar
      ocfs2: fix build failure when TCP/IP is disabled · fce1affe
      Tom Seewald authored
      After commit 12abc5ee ("tcp: add tcp_sock_set_nodelay") and commit
      c488aead ("tcp: add tcp_sock_set_user_timeout"), building the kernel
      with OCFS2_FS=y but without INET=y causes it to fail with:
      
        ld: fs/ocfs2/cluster/tcp.o: in function `o2net_accept_many':
        tcp.c:(.text+0x21b1): undefined reference to `tcp_sock_set_nodelay'
        ld: tcp.c:(.text+0x21c1): undefined reference to `tcp_sock_set_user_timeout'
        ld: fs/ocfs2/cluster/tcp.o: in function `o2net_start_connect':
        tcp.c:(.text+0x2633): undefined reference to `tcp_sock_set_nodelay'
        ld: tcp.c:(.text+0x2643): undefined reference to `tcp_sock_set_user_timeout'
      
      This is due to tcp_sock_set_nodelay() and tcp_sock_set_user_timeout()
      being declared in linux/tcp.h and defined in net/ipv4/tcp.c, which
      depend on TCP/IP being enabled.
      
      To fix this, make OCFS2_FS depend on INET=y which already requires
      NET=y.
      
      Fixes: 12abc5ee ("tcp: add tcp_sock_set_nodelay")
      Fixes: c488aead ("tcp: add tcp_sock_set_user_timeout")
      Signed-off-by: default avatarTom Seewald <tseewald@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Sagi Grimberg <sagi@grimberg.me>
      Cc: Jason Gunthorpe <jgg@mellanox.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Changwei Ge <gechangwei@live.cn>
      Cc: Gang He <ghe@suse.com>
      Cc: Jun Piao <piaojun@huawei.com>
      Link: http://lkml.kernel.org/r/20200606190827.23954-1-tseewald@gmail.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fce1affe
    • Naoya Horiguchi's avatar
      mm/memory-failure: send SIGBUS(BUS_MCEERR_AR) only to current thread · 03151c6e
      Naoya Horiguchi authored
      Action Required memory error should happen only when a processor is
      about to access to a corrupted memory, so it's synchronous and only
      affects current process/thread.
      
      Recently commit 872e9a20 ("mm, memory_failure: don't send
      BUS_MCEERR_AO for action required error") fixed the issue that Action
      Required memory could unnecessarily send SIGBUS to the processes which
      share the error memory.  But we still have another issue that we could
      send SIGBUS to a wrong thread.
      
      This is because collect_procs() and task_early_kill() fails to add the
      current process to "to-kill" list.  So this patch is suggesting to fix
      it.  With this fix, SIGBUS(BUS_MCEERR_AR) is never sent to non-current
      process/thread.
      Signed-off-by: default avatarNaoya Horiguchi <naoya.horiguchi@nec.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Acked-by: default avatarPankaj Gupta <pankaj.gupta.linux@gmail.com>
      Link: http://lkml.kernel.org/r/1591321039-22141-3-git-send-email-naoya.horiguchi@nec.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      03151c6e
    • Naoya Horiguchi's avatar
      mm/memory-failure: prioritize prctl(PR_MCE_KILL) over vm.memory_failure_early_kill · 4e018b45
      Naoya Horiguchi authored
      Patch series "hwpoison: fixes signaling on memory error"
      
      This is a small patchset to solve issues in memory error handler to send
      SIGBUS to proper process/thread as expected in configuration.  Please
      see descriptions in individual patches for more details.
      
      This patch (of 2):
      
      Early-kill policy is controlled from two types of settings, one is
      per-process setting prctl(PR_MCE_KILL) and the other is system-wide
      setting vm.memory_failure_early_kill.  Users expect per-process setting
      to override system-wide setting as many other settings do, but
      early-kill setting doesn't work as such.
      
      For example, if a system configures vm.memory_failure_early_kill to 1
      (enabled), a process receives SIGBUS even if it's configured to
      explicitly disable PF_MCE_KILL by prctl().  That's not desirable for
      applications with their own policies.
      
      This patch is suggesting to change the priority of these two types of
      settings, by checking sysctl_memory_failure_early_kill only when a given
      process has the default kill policy.
      
      Note that this patch is solving a thread choice issue too.
      
      Originally, collect_procs() always chooses the main thread when
      vm.memory_failure_early_kill is 1, even if the process has a dedicated
      thread for memory error handling.  SIGBUS should be sent to the
      dedicated thread if early-kill is enabled via
      vm.memory_failure_early_kill as we are doing for PR_MCE_KILL_EARLY
      processes.
      Signed-off-by: default avatarNaoya Horiguchi <naoya.horiguchi@nec.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
      Link: http://lkml.kernel.org/r/1591321039-22141-1-git-send-email-naoya.horiguchi@nec.com
      Link: http://lkml.kernel.org/r/1591321039-22141-2-git-send-email-naoya.horiguchi@nec.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4e018b45
  3. 11 Jun, 2020 26 commits