1. 03 Jul, 2019 5 commits
    • zhong jiang's avatar
      mm/mempolicy.c: fix an incorrect rebind node in mpol_rebind_nodemask · 41ceb21b
      zhong jiang authored
      commit 29b190fa upstream.
      
      mpol_rebind_nodemask() is called for MPOL_BIND and MPOL_INTERLEAVE
      mempoclicies when the tasks's cpuset's mems_allowed changes.  For
      policies created without MPOL_F_STATIC_NODES or MPOL_F_RELATIVE_NODES,
      it works by remapping the policy's allowed nodes (stored in v.nodes)
      using the previous value of mems_allowed (stored in
      w.cpuset_mems_allowed) as the domain of map and the new mems_allowed
      (passed as nodes) as the range of the map (see the comment of
      bitmap_remap() for details).
      
      The result of remapping is stored back as policy's nodemask in v.nodes,
      and the new value of mems_allowed should be stored in
      w.cpuset_mems_allowed to facilitate the next rebind, if it happens.
      
      However, 213980c0 ("mm, mempolicy: simplify rebinding mempolicies
      when updating cpusets") introduced a bug where the result of remapping
      is stored in w.cpuset_mems_allowed instead.  Thus, a mempolicy's
      allowed nodes can evolve in an unexpected way after a series of
      rebinding due to cpuset mems_allowed changes, possibly binding to a
      wrong node or a smaller number of nodes which may e.g.  overload them.
      This patch fixes the bug so rebinding again works as intended.
      
      [vbabka@suse.cz: new changlog]
        Link: http://lkml.kernel.org/r/ef6a69c6-c052-b067-8f2c-9d615c619bb9@suse.cz
      Link: http://lkml.kernel.org/r/1558768043-23184-1-git-send-email-zhongjiang@huawei.com
      Fixes: 213980c0 ("mm, mempolicy: simplify rebinding mempolicies when updating cpusets")
      Signed-off-by: default avatarzhong jiang <zhongjiang@huawei.com>
      Reviewed-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Ralph Campbell <rcampbell@nvidia.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      41ceb21b
    • John Ogness's avatar
      fs/proc/array.c: allow reporting eip/esp for all coredumping threads · f1fb34c2
      John Ogness authored
      commit cb8f381f upstream.
      
      0a1eb2d4 ("fs/proc: Stop reporting eip and esp in /proc/PID/stat")
      stopped reporting eip/esp and fd7d5627 ("fs/proc: Report eip/esp in
      /prod/PID/stat for coredumping") reintroduced the feature to fix a
      regression with userspace core dump handlers (such as minicoredumper).
      
      Because PF_DUMPCORE is only set for the primary thread, this didn't fix
      the original problem for secondary threads.  Allow reporting the eip/esp
      for all threads by checking for PF_EXITING as well.  This is set for all
      the other threads when they are killed.  coredump_wait() waits for all the
      tasks to become inactive before proceeding to invoke a core dumper.
      
      Link: http://lkml.kernel.org/r/87y32p7i7a.fsf@linutronix.de
      Link: http://lkml.kernel.org/r/20190522161614.628-1-jlu@pengutronix.de
      Fixes: fd7d5627 ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping")
      Signed-off-by: default avatarJohn Ogness <john.ogness@linutronix.de>
      Reported-by: default avatarJan Luebbe <jlu@pengutronix.de>
      Tested-by: default avatarJan Luebbe <jlu@pengutronix.de>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1fb34c2
    • Bjørn Mork's avatar
      qmi_wwan: Fix out-of-bounds read · 4d750447
      Bjørn Mork authored
      [ Upstream commit 904d88d7 ]
      
      The syzbot reported
      
       Call Trace:
        __dump_stack lib/dump_stack.c:77 [inline]
        dump_stack+0xca/0x13e lib/dump_stack.c:113
        print_address_description+0x67/0x231 mm/kasan/report.c:188
        __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
        kasan_report+0xe/0x20 mm/kasan/common.c:614
        qmi_wwan_probe+0x342/0x360 drivers/net/usb/qmi_wwan.c:1417
        usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
        really_probe+0x281/0x660 drivers/base/dd.c:509
        driver_probe_device+0x104/0x210 drivers/base/dd.c:670
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
      
      Caused by too many confusing indirections and casts.
      id->driver_info is a pointer stored in a long.  We want the
      pointer here, not the address of it.
      
      Thanks-to: Hillf Danton <hdanton@sina.com>
      Reported-by: syzbot+b68605d7fadd21510de1@syzkaller.appspotmail.com
      Cc: Kristian Evensen <kristian.evensen@gmail.com>
      Fixes: e4bf6348 ("qmi_wwan: Add quirk for Quectel dynamic config")
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4d750447
    • Sasha Levin's avatar
      Revert "x86/uaccess, ftrace: Fix ftrace_likely_update() vs. SMAP" · 0d1d9244
      Sasha Levin authored
      This reverts commit b65b70ba, which was
      upstream commit 4a6c91fb.
      
      On Tue, Jun 25, 2019 at 09:39:45AM +0200, Sebastian Andrzej Siewior wrote:
      >Please backport commit e74deb11 to
      >stable _or_ revert the backport of commit 4a6c91fb ("x86/uaccess,
      >ftrace: Fix ftrace_likely_update() vs. SMAP"). It uses
      >user_access_{save|restore}() which has been introduced in the following
      >commit.
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0d1d9244
    • Nathan Chancellor's avatar
      arm64: Don't unconditionally add -Wno-psabi to KBUILD_CFLAGS · 507ad93a
      Nathan Chancellor authored
      commit fa63da2a upstream.
      
      This is a GCC only option, which warns about ABI changes within GCC, so
      unconditionally adding it breaks Clang with tons of:
      
      warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
      
      and link time failures:
      
      ld.lld: error: undefined symbol: __efistub___stack_chk_guard
      >>> referenced by arm-stub.c:73
      (/home/nathan/cbl/linux/drivers/firmware/efi/libstub/arm-stub.c:73)
      >>>               arm-stub.stub.o:(__efistub_install_memreserve_table)
      in archive ./drivers/firmware/efi/libstub/lib.a
      
      These failures come from the lack of -fno-stack-protector, which is
      added via cc-option in drivers/firmware/efi/libstub/Makefile. When an
      unknown flag is added to KBUILD_CFLAGS, clang will noisily warn that it
      is ignoring the option like above, unlike gcc, who will just error.
      
      $ echo "int main() { return 0; }" > tmp.c
      
      $ clang -Wno-psabi tmp.c; echo $?
      warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
      1 warning generated.
      0
      
      $ gcc -Wsometimes-uninitialized tmp.c; echo $?
      gcc: error: unrecognized command line option
      ‘-Wsometimes-uninitialized’; did you mean ‘-Wmaybe-uninitialized’?
      1
      
      For cc-option to work properly with clang and behave like gcc, -Werror
      is needed, which was done in commit c3f0d0bc ("kbuild, LLVMLinux:
      Add -Werror to cc-option to support clang").
      
      $ clang -Werror -Wno-psabi tmp.c; echo $?
      error: unknown warning option '-Wno-psabi'
      [-Werror,-Wunknown-warning-option]
      1
      
      As a consequence of this, when an unknown flag is unconditionally added
      to KBUILD_CFLAGS, it will cause cc-option to always fail and those flags
      will never get added:
      
      $ clang -Werror -Wno-psabi -fno-stack-protector tmp.c; echo $?
      error: unknown warning option '-Wno-psabi'
      [-Werror,-Wunknown-warning-option]
      1
      
      This can be seen when compiling the whole kernel as some warnings that
      are normally disabled (see below) show up. The full list of flags
      missing from drivers/firmware/efi/libstub are the following (gathered
      from diffing .arm64-stub.o.cmd):
      
      -fno-delete-null-pointer-checks
      -Wno-address-of-packed-member
      -Wframe-larger-than=2048
      -Wno-unused-const-variable
      -fno-strict-overflow
      -fno-merge-all-constants
      -fno-stack-check
      -Werror=date-time
      -Werror=incompatible-pointer-types
      -ffreestanding
      -fno-stack-protector
      
      Use cc-disable-warning so that it gets disabled for GCC and does nothing
      for Clang.
      
      Fixes: ebcc5928 ("arm64: Silence gcc warnings about arch ABI drift")
      Link: https://github.com/ClangBuiltLinux/linux/issues/511Reported-by: default avatarQian Cai <cai@lca.pw>
      Acked-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      507ad93a
  2. 25 Jun, 2019 35 commits