1. 31 7月, 2019 40 次提交
    • A
      mm/gup.c: remove some BUG_ONs from get_gate_page() · 041b127d
      Andy Lutomirski 提交于
      [ Upstream commit b5d1c39f34d1c9bca0c4b9ae2e339fbbe264a9c7 ]
      
      If we end up without a PGD or PUD entry backing the gate area, don't BUG
      -- just fail gracefully.
      
      It's not entirely implausible that this could happen some day on x86.  It
      doesn't right now even with an execute-only emulated vsyscall page because
      the fixmap shares the PUD, but the core mm code shouldn't rely on that
      particular detail to avoid OOPSing.
      
      Link: http://lkml.kernel.org/r/a1d9f4efb75b9d464e59fd6af00104b21c58f6f7.1561610798.git.luto@kernel.orgSigned-off-by: NAndy Lutomirski <luto@kernel.org>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Florian Weimer <fweimer@redhat.com>
      Cc: Jann Horn <jannh@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      041b127d
    • G
      mm/gup.c: mark undo_dev_pagemap as __maybe_unused · fa099d6d
      Guenter Roeck 提交于
      [ Upstream commit 790c73690c2bbecb3f6f8becbdb11ddc9bcff8cc ]
      
      Several mips builds generate the following build warning.
      
        mm/gup.c:1788:13: warning: 'undo_dev_pagemap' defined but not used
      
      The function is declared unconditionally but only called from behind
      various ifdefs. Mark it __maybe_unused.
      
      Link: http://lkml.kernel.org/r/1562072523-22311-1-git-send-email-linux@roeck-us.netSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fa099d6d
    • C
      9p: pass the correct prototype to read_cache_page · 8be4a30e
      Christoph Hellwig 提交于
      [ Upstream commit f053cbd4366051d7eb6ba1b8d529d20f719c2963 ]
      
      Fix the callback 9p passes to read_cache_page to actually have the
      proper type expected.  Casting around function pointers can easily
      hide typing bugs, and defeats control flow protection.
      
      Link: http://lkml.kernel.org/r/20190520055731.24538-5-hch@lst.deSigned-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Cc: Sami Tolvanen <samitolvanen@google.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8be4a30e
    • D
      mm/kmemleak.c: fix check for softirq context · 071f2135
      Dmitry Vyukov 提交于
      [ Upstream commit 6ef9056952532c3b746de46aa10d45b4d7797bd8 ]
      
      in_softirq() is a wrong predicate to check if we are in a softirq
      context.  It also returns true if we have BH disabled, so objects are
      falsely stamped with "softirq" comm.  The correct predicate is
      in_serving_softirq().
      
      If user does cat from /sys/kernel/debug/kmemleak previously they would
      see this, which is clearly wrong, this is system call context (see the
      comm):
      
      unreferenced object 0xffff88805bd661c0 (size 64):
        comm "softirq", pid 0, jiffies 4294942959 (age 12.400s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  ................
          00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
        backtrace:
          [<0000000007dcb30c>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
          [<0000000007dcb30c>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<0000000007dcb30c>] slab_alloc mm/slab.c:3326 [inline]
          [<0000000007dcb30c>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
          [<00000000969722b7>] kmalloc include/linux/slab.h:547 [inline]
          [<00000000969722b7>] kzalloc include/linux/slab.h:742 [inline]
          [<00000000969722b7>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline]
          [<00000000969722b7>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085
          [<00000000a4134b5f>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475
          [<00000000d20248ad>] do_ip_setsockopt.isra.0+0x19fe/0x1c00 net/ipv4/ip_sockglue.c:957
          [<000000003d367be7>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246
          [<000000003c7c76af>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
          [<000000000c1aeb23>] sock_common_setsockopt+0x3e/0x50 net/core/sock.c:3130
          [<000000000157b92b>] __sys_setsockopt+0x9e/0x120 net/socket.c:2078
          [<00000000a9f3d058>] __do_sys_setsockopt net/socket.c:2089 [inline]
          [<00000000a9f3d058>] __se_sys_setsockopt net/socket.c:2086 [inline]
          [<00000000a9f3d058>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
          [<000000001b8da885>] do_syscall_64+0x7c/0x1a0 arch/x86/entry/common.c:301
          [<00000000ba770c62>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      now they will see this:
      
      unreferenced object 0xffff88805413c800 (size 64):
        comm "syz-executor.4", pid 8960, jiffies 4294994003 (age 14.350s)
        hex dump (first 32 bytes):
          00 7a 8a 57 80 88 ff ff e0 00 00 01 00 00 00 00  .z.W............
          00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000c5d3be64>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
          [<00000000c5d3be64>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<00000000c5d3be64>] slab_alloc mm/slab.c:3326 [inline]
          [<00000000c5d3be64>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
          [<0000000023865be2>] kmalloc include/linux/slab.h:547 [inline]
          [<0000000023865be2>] kzalloc include/linux/slab.h:742 [inline]
          [<0000000023865be2>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline]
          [<0000000023865be2>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085
          [<000000003029a9d4>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475
          [<00000000ccd0a87c>] do_ip_setsockopt.isra.0+0x19fe/0x1c00 net/ipv4/ip_sockglue.c:957
          [<00000000a85a3785>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246
          [<00000000ec13c18d>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
          [<0000000052d748e3>] sock_common_setsockopt+0x3e/0x50 net/core/sock.c:3130
          [<00000000512f1014>] __sys_setsockopt+0x9e/0x120 net/socket.c:2078
          [<00000000181758bc>] __do_sys_setsockopt net/socket.c:2089 [inline]
          [<00000000181758bc>] __se_sys_setsockopt net/socket.c:2086 [inline]
          [<00000000181758bc>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
          [<00000000d4b73623>] do_syscall_64+0x7c/0x1a0 arch/x86/entry/common.c:301
          [<00000000c1098bec>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Link: http://lkml.kernel.org/r/20190517171507.96046-1-dvyukov@gmail.comSigned-off-by: NDmitry Vyukov <dvyukov@google.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      071f2135
    • S
      sh: prevent warnings when using iounmap · 7bd5902a
      Sam Ravnborg 提交于
      [ Upstream commit 733f0025f0fb43e382b84db0930ae502099b7e62 ]
      
      When building drm/exynos for sh, as part of an allmodconfig build, the
      following warning triggered:
      
        exynos7_drm_decon.c: In function `decon_remove':
        exynos7_drm_decon.c:769:24: warning: unused variable `ctx'
          struct decon_context *ctx = dev_get_drvdata(&pdev->dev);
      
      The ctx variable is only used as argument to iounmap().
      
      In sh - allmodconfig CONFIG_MMU is not defined
      so it ended up in:
      
      \#define __iounmap(addr)	do { } while (0)
      \#define iounmap		__iounmap
      
      Fix the warning by introducing a static inline function for iounmap.
      
      This is similar to several other architectures.
      
      Link: http://lkml.kernel.org/r/20190622114208.24427-1-sam@ravnborg.orgSigned-off-by: NSam Ravnborg <sam@ravnborg.org>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7bd5902a
    • W
      block/bio-integrity: fix a memory leak bug · af50d6a1
      Wenwen Wang 提交于
      [ Upstream commit e7bf90e5afe3aa1d1282c1635a49e17a32c4ecec ]
      
      In bio_integrity_prep(), a kernel buffer is allocated through kmalloc() to
      hold integrity metadata. Later on, the buffer will be attached to the bio
      structure through bio_integrity_add_page(), which returns the number of
      bytes of integrity metadata attached. Due to unexpected situations,
      bio_integrity_add_page() may return 0. As a result, bio_integrity_prep()
      needs to be terminated with 'false' returned to indicate this error.
      However, the allocated kernel buffer is not freed on this execution path,
      leading to a memory leak.
      
      To fix this issue, free the allocated buffer before returning from
      bio_integrity_prep().
      Reviewed-by: NMing Lei <ming.lei@redhat.com>
      Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NWenwen Wang <wenwen@cs.uga.edu>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      af50d6a1
    • O
      powerpc/eeh: Handle hugepages in ioremap space · 7f775a67
      Oliver O'Halloran 提交于
      [ Upstream commit 33439620680be5225c1b8806579a291e0d761ca0 ]
      
      In commit 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap
      space") support for using hugepages in the vmalloc and ioremap areas was
      enabled for radix. Unfortunately this broke EEH MMIO error checking.
      
      Detection works by inserting a hook which checks the results of the
      ioreadXX() set of functions.  When a read returns a 0xFFs response we
      need to check for an error which we do by mapping the (virtual) MMIO
      address back to a physical address, then mapping physical address to a
      PCI device via an interval tree.
      
      When translating virt -> phys we currently assume the ioremap space is
      only populated by PAGE_SIZE mappings. If a hugepage mapping is found we
      emit a WARN_ON(), but otherwise handles the check as though a normal
      page was found. In pathalogical cases such as copying a buffer
      containing a lot of 0xFFs from BAR memory this can result in the system
      not booting because it's too busy printing WARN_ON()s.
      
      There's no real reason to assume huge pages can't be present and we're
      prefectly capable of handling them, so do that.
      
      Fixes: 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap space")
      Reported-by: NSachin Sant <sachinp@linux.vnet.ibm.com>
      Signed-off-by: NOliver O'Halloran <oohall@gmail.com>
      Tested-by: NSachin Sant <sachinp@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190710150517.27114-1-oohall@gmail.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      7f775a67
    • D
      dlm: check if workqueues are NULL before flushing/destroying · e7a41b27
      David Windsor 提交于
      [ Upstream commit b355516f450703c9015316e429b66a93dfff0e6f ]
      
      If the DLM lowcomms stack is shut down before any DLM
      traffic can be generated, flush_workqueue() and
      destroy_workqueue() can be called on empty send and/or recv
      workqueues.
      
      Insert guard conditionals to only call flush_workqueue()
      and destroy_workqueue() on workqueues that are not NULL.
      Signed-off-by: NDavid Windsor <dwindsor@redhat.com>
      Signed-off-by: NDavid Teigland <teigland@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e7a41b27
    • M
      mailbox: handle failed named mailbox channel request · 5d59e28c
      morten petersen 提交于
      [ Upstream commit 25777e5784a7b417967460d4fcf9660d05a0c320 ]
      
      Previously, if mbox_request_channel_byname was used with a name
      which did not exist in the "mbox-names" property of a mailbox
      client, the mailbox corresponding to the last entry in the
      "mbox-names" list would be incorrectly selected.
      With this patch, -EINVAL is returned if the named mailbox is
      not found.
      Signed-off-by: NMorten Borup Petersen <morten_bp@live.dk>
      Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5d59e28c
    • O
      f2fs: avoid out-of-range memory access · 2140a6b0
      Ocean Chen 提交于
      [ Upstream commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a ]
      
      blkoff_off might over 512 due to fs corrupt or security
      vulnerability. That should be checked before being using.
      
      Use ENTRIES_IN_SUM to protect invalid value in cur_data_blkoff.
      Signed-off-by: NOcean Chen <oceanchen@google.com>
      Reviewed-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2140a6b0
    • J
      block: init flush rq ref count to 1 · 8a1a3d38
      Josef Bacik 提交于
      [ Upstream commit b554db147feea39617b533ab6bca247c91c6198a ]
      
      We discovered a problem in newer kernels where a disconnect of a NBD
      device while the flush request was pending would result in a hang.  This
      is because the blk mq timeout handler does
      
              if (!refcount_inc_not_zero(&rq->ref))
                      return true;
      
      to determine if it's ok to run the timeout handler for the request.
      Flush_rq's don't have a ref count set, so we'd skip running the timeout
      handler for this request and it would just sit there in limbo forever.
      
      Fix this by always setting the refcount of any request going through
      blk_init_rq() to 1.  I tested this with a nbd-server that dropped flush
      requests to verify that it hung, and then tested with this patch to
      verify I got the timeout as expected and the error handling kicked in.
      Thanks,
      Signed-off-by: NJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8a1a3d38
    • M
      powerpc/boot: add {get, put}_unaligned_be32 to xz_config.h · 4b9dc73a
      Masahiro Yamada 提交于
      [ Upstream commit 9e005b761e7ad153dcf40a6cba1d681fe0830ac6 ]
      
      The next commit will make the way of passing CONFIG options more robust.
      Unfortunately, it would uncover another hidden issue; without this
      commit, skiroot_defconfig would be broken like this:
      
      |   WRAP    arch/powerpc/boot/zImage.pseries
      | arch/powerpc/boot/wrapper.a(decompress.o): In function `bcj_powerpc.isra.10':
      | decompress.c:(.text+0x720): undefined reference to `get_unaligned_be32'
      | decompress.c:(.text+0x7a8): undefined reference to `put_unaligned_be32'
      | make[1]: *** [arch/powerpc/boot/Makefile;383: arch/powerpc/boot/zImage.pseries] Error 1
      | make: *** [arch/powerpc/Makefile;295: zImage] Error 2
      
      skiroot_defconfig is the only defconfig that enables CONFIG_KERNEL_XZ
      for ppc, which has never been correctly built before.
      
      I figured out the root cause in lib/decompress_unxz.c:
      
      | #ifdef CONFIG_PPC
      | #      define XZ_DEC_POWERPC
      | #endif
      
      CONFIG_PPC is undefined here in the ppc bootwrapper because autoconf.h
      is not included except by arch/powerpc/boot/serial.c
      
      XZ_DEC_POWERPC is not defined, therefore, bcj_powerpc() is not compiled
      for the bootwrapper.
      
      With the next commit passing CONFIG_PPC correctly, we would realize that
      {get,put}_unaligned_be32 was missing.
      
      Unlike the other decompressors, the ppc bootwrapper duplicates all the
      necessary helpers in arch/powerpc/boot/.
      
      The other architectures define __KERNEL__ and pull in helpers for
      building the decompressors.
      
      If ppc bootwrapper had defined __KERNEL__, lib/xz/xz_private.h would
      have included <asm/unaligned.h>:
      
      | #ifdef __KERNEL__
      | #       include <linux/xz.h>
      | #       include <linux/kernel.h>
      | #       include <asm/unaligned.h>
      
      However, doing so would cause tons of definition conflicts since the
      bootwrapper has duplicated everything.
      
      I just added copies of {get,put}_unaligned_be32, following the
      bootwrapper coding convention.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190705100144.28785-1-yamada.masahiro@socionext.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      4b9dc73a
    • Y
      PCI: dwc: pci-dra7xx: Fix compilation when !CONFIG_GPIOLIB · 549f726f
      YueHaibing 提交于
      [ Upstream commit 381ed79c8655a40268ee7391f716edd90c5c3a97 ]
      
      If CONFIG_GPIOLIB is not selected the compilation results in the
      following build errors:
      
      drivers/pci/controller/dwc/pci-dra7xx.c:
       In function dra7xx_pcie_probe:
      drivers/pci/controller/dwc/pci-dra7xx.c:777:10:
       error: implicit declaration of function devm_gpiod_get_optional;
       did you mean devm_regulator_get_optional? [-Werror=implicit-function-declaration]
      
        reset = devm_gpiod_get_optional(dev, NULL, GPIOD_OUT_HIGH);
      
      drivers/pci/controller/dwc/pci-dra7xx.c:778:45: error: ‘GPIOD_OUT_HIGH’
      undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’?
        reset = devm_gpiod_get_optional(dev, NULL, GPIOD_OUT_HIGH);
                                                   ^~~~~~~~~~~~~~
                                                   GPIOF_INIT_HIGH
      
      Fix them by including the appropriate header file.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      [lorenzo.pieralisi@arm.com: commit log]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      549f726f
    • K
      RDMA/rxe: Fill in wc byte_len with IB_WC_RECV_RDMA_WITH_IMM · 367cc371
      Konstantin Taranov 提交于
      [ Upstream commit bdce1290493caa3f8119f24b5dacc3fb7ca27389 ]
      
      Calculate the correct byte_len on the receiving side when a work
      completion is generated with IB_WC_RECV_RDMA_WITH_IMM opcode.
      
      According to the IBA byte_len must indicate the number of written bytes,
      whereas it was always equal to zero for the IB_WC_RECV_RDMA_WITH_IMM
      opcode, even though data was transferred.
      
      Fixes: 8700e3e7 ("Soft RoCE driver")
      Signed-off-by: NKonstantin Taranov <konstantin.taranov@inf.ethz.ch>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      367cc371
    • L
      perf hists browser: Fix potential NULL pointer dereference found by the smatch tool · 4fe7ea29
      Leo Yan 提交于
      [ Upstream commit ceb75476db1617a88cc29b09839acacb69aa076e ]
      
      Based on the following report from Smatch, fix the potential
      NULL pointer dereference check.
      
        tools/perf/ui/browsers/hists.c:641
        hist_browser__run() error: we previously assumed 'hbt' could be
        null (see line 625)
      
        tools/perf/ui/browsers/hists.c:3088
        perf_evsel__hists_browse() error: we previously assumed
        'browser->he_selection' could be null (see line 2902)
      
        tools/perf/ui/browsers/hists.c:3272
        perf_evsel_menu__run() error: we previously assumed 'hbt' could be
        null (see line 3260)
      
      This patch firstly validating the pointers before access them, so can
      fix potential NULL pointer dereference.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20190708143937.7722-2-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4fe7ea29
    • L
      perf annotate: Fix dereferencing freed memory found by the smatch tool · 915945f3
      Leo Yan 提交于
      [ Upstream commit 600c787dbf6521d8d07ee717ab7606d5070103ea ]
      
      Based on the following report from Smatch, fix the potential
      dereferencing freed memory check.
      
        tools/perf/util/annotate.c:1125
        disasm_line__parse() error: dereferencing freed memory 'namep'
      
        tools/perf/util/annotate.c
        1100 static int disasm_line__parse(char *line, const char **namep, char **rawp)
        1101 {
        1102         char tmp, *name = ltrim(line);
      
        [...]
      
        1114         *namep = strdup(name);
        1115
        1116         if (*namep == NULL)
        1117                 goto out_free_name;
      
        [...]
      
        1124 out_free_name:
        1125         free((void *)namep);
                                  ^^^^^
        1126         *namep = NULL;
                     ^^^^^^
        1127         return -1;
        1128 }
      
      If strdup() fails to allocate memory space for *namep, we don't need to
      free memory with pointer 'namep', which is resident in data structure
      disasm_line::ins::name; and *namep is NULL pointer for this failure, so
      it's pointless to assign NULL to *namep again.
      
      Committer note:
      
      Freeing namep, which is the address of the first entry of the 'struct
      ins' that is the first member of struct disasm_line would in fact free
      that disasm_line instance, if it was allocated via malloc/calloc, which,
      later, would a dereference of freed memory.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Alexios Zavras <alexios.zavras@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Changbin Du <changbin.du@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20190702103420.27540-5-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      915945f3
    • L
      perf session: Fix potential NULL pointer dereference found by the smatch tool · b305dcff
      Leo Yan 提交于
      [ Upstream commit f3c8d90757724982e5f07cd77d315eb64ca145ac ]
      
      Based on the following report from Smatch, fix the potential
      NULL pointer dereference check.
      
        tools/perf/util/session.c:1252
        dump_read() error: we previously assumed 'evsel' could be null
        (see line 1249)
      
        tools/perf/util/session.c
        1240 static void dump_read(struct perf_evsel *evsel, union perf_event *event)
        1241 {
        1242         struct read_event *read_event = &event->read;
        1243         u64 read_format;
        1244
        1245         if (!dump_trace)
        1246                 return;
        1247
        1248         printf(": %d %d %s %" PRIu64 "\n", event->read.pid, event->read.tid,
        1249                evsel ? perf_evsel__name(evsel) : "FAIL",
        1250                event->read.value);
        1251
        1252         read_format = evsel->attr.read_format;
                                   ^^^^^^^
      
      'evsel' could be NULL pointer, for this case this patch directly bails
      out without dumping read_event.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Alexios Zavras <alexios.zavras@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Changbin Du <changbin.du@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20190702103420.27540-9-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b305dcff
    • L
      perf top: Fix potential NULL pointer dereference detected by the smatch tool · 19cf571c
      Leo Yan 提交于
      [ Upstream commit 111442cfc8abdeaa7ec1407f07ef7b3e5f76654e ]
      
      Based on the following report from Smatch, fix the potential NULL
      pointer dereference check.
      
        tools/perf/builtin-top.c:109
        perf_top__parse_source() warn: variable dereferenced before check 'he'
        (see line 103)
      
        tools/perf/builtin-top.c:233
        perf_top__show_details() warn: variable dereferenced before check 'he'
        (see line 228)
      
        tools/perf/builtin-top.c
        101 static int perf_top__parse_source(struct perf_top *top, struct hist_entry *he)
        102 {
        103         struct perf_evsel *evsel = hists_to_evsel(he->hists);
                                                              ^^^^
        104         struct symbol *sym;
        105         struct annotation *notes;
        106         struct map *map;
        107         int err = -1;
        108
        109         if (!he || !he->ms.sym)
        110                 return -1;
      
      This patch moves the values assignment after validating pointer 'he'.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Alexios Zavras <alexios.zavras@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Changbin Du <changbin.du@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20190702103420.27540-4-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      19cf571c
    • L
      perf stat: Fix use-after-freed pointer detected by the smatch tool · 995527db
      Leo Yan 提交于
      [ Upstream commit c74b05030edb3b52f4208d8415b8c933bc509a29 ]
      
      Based on the following report from Smatch, fix the use-after-freed
      pointer.
      
        tools/perf/builtin-stat.c:1353
        add_default_attributes() warn: passing freed memory 'str'.
      
      The pointer 'str' has been freed but later it is still passed into the
      function parse_events_print_error().  This patch fixes this
      use-after-freed issue.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Alexios Zavras <alexios.zavras@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Changbin Du <changbin.du@intel.com>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Link: http://lkml.kernel.org/r/20190702103420.27540-3-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      995527db
    • N
      perf test mmap-thread-lookup: Initialize variable to suppress memory sanitizer warning · 3b8c4eae
      Numfor Mbiziwo-Tiapo 提交于
      [ Upstream commit 4e4cf62b37da5ff45c904a3acf242ab29ed5881d ]
      
      Running the 'perf test' command after building perf with a memory
      sanitizer causes a warning that says:
      
        WARNING: MemorySanitizer: use-of-uninitialized-value... in mmap-thread-lookup.c
      
      Initializing the go variable to 0 silences this harmless warning.
      
      Committer warning:
      
      This was harmless, just a simple test writing whatever was at that
      sizeof(int) memory area just to signal another thread blocked reading
      that file created with pipe(). Initialize it tho so that we don't get
      this warning.
      Signed-off-by: NNumfor Mbiziwo-Tiapo <nums@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mark Drayton <mbd@fb.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20190702173716.181223-1-nums@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3b8c4eae
    • H
      PCI: mobiveil: Use the 1st inbound window for MEM inbound transactions · dd0a0c72
      Hou Zhiqiang 提交于
      [ Upstream commit f7fee1b42fe4f8171a4b1cad05c61907c33c53f6 ]
      
      The inbound and outbound windows have completely separate control
      registers sets in the host controller MMIO space. Windows control
      register are accessed through an MMIO base address and an offset
      that depends on the window index.
      
      Since inbound and outbound windows control registers are completely
      separate there is no real need to use different window indexes in the
      inbound/outbound windows initialization routines to prevent clashing.
      
      To fix this inconsistency, change the MEM inbound window index to 0,
      mirroring the outbound window set-up.
      Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com>
      [lorenzo.pieralisi@arm.com: update commit log]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NMinghuan Lian <Minghuan.Lian@nxp.com>
      Reviewed-by: NSubrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dd0a0c72
    • H
      PCI: mobiveil: Initialize Primary/Secondary/Subordinate bus numbers · 270972df
      Hou Zhiqiang 提交于
      [ Upstream commit 6f3ab451aa5c2cbff33197d82fe8489cbd55ad91 ]
      
      The reset value of Primary, Secondary and Subordinate bus numbers is
      zero which is a broken setup.
      
      Program a sensible default value for Primary/Secondary/Subordinate
      bus numbers.
      Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NMinghuan Lian <Minghuan.Lian@nxp.com>
      Reviewed-by: NSubrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      270972df
    • V
      kallsyms: exclude kasan local symbols on s390 · 9eb4f288
      Vasily Gorbik 提交于
      [ Upstream commit 33177f01ca3fe550146bb9001bec2fd806b2f40c ]
      
      gcc asan instrumentation emits the following sequence to store frame pc
      when the kernel is built with CONFIG_RELOCATABLE:
      debug/vsprintf.s:
              .section        .data.rel.ro.local,"aw"
              .align  8
      .LC3:
              .quad   .LASANPC4826@GOTOFF
      .text
              .align  8
              .type   number, @function
      number:
      .LASANPC4826:
      
      and in case reloc is issued for LASANPC label it also gets into .symtab
      with the same address as actual function symbol:
      $ nm -n vmlinux | grep 0000000001397150
      0000000001397150 t .LASANPC4826
      0000000001397150 t number
      
      In the end kernel backtraces are almost unreadable:
      [  143.748476] Call Trace:
      [  143.748484] ([<000000002da3e62c>] .LASANPC2671+0x114/0x190)
      [  143.748492]  [<000000002eca1a58>] .LASANPC2612+0x110/0x160
      [  143.748502]  [<000000002de9d830>] print_address_description+0x80/0x3b0
      [  143.748511]  [<000000002de9dd64>] __kasan_report+0x15c/0x1c8
      [  143.748521]  [<000000002ecb56d4>] strrchr+0x34/0x60
      [  143.748534]  [<000003ff800a9a40>] kasan_strings+0xb0/0x148 [test_kasan]
      [  143.748547]  [<000003ff800a9bba>] kmalloc_tests_init+0xe2/0x528 [test_kasan]
      [  143.748555]  [<000000002da2117c>] .LASANPC4069+0x354/0x748
      [  143.748563]  [<000000002dbfbb16>] do_init_module+0x136/0x3b0
      [  143.748571]  [<000000002dbff3f4>] .LASANPC3191+0x2164/0x25d0
      [  143.748580]  [<000000002dbffc4c>] .LASANPC3196+0x184/0x1b8
      [  143.748587]  [<000000002ecdf2ec>] system_call+0xd8/0x2d8
      
      Since LASANPC labels are not even unique and get into .symtab only due
      to relocs filter them out in kallsyms.
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9eb4f288
    • H
      PCI: mobiveil: Fix the Class Code field · 4613f46e
      Hou Zhiqiang 提交于
      [ Upstream commit 0122af0a08243f344a438f924e5c2486486555b3 ]
      
      Fix up the Class Code field in PCI configuration space and set it to
      PCI_CLASS_BRIDGE_PCI.
      
      Move the Class Code fixup to function mobiveil_host_init() where
      it belongs.
      
      Fixes: 9af6bcb1 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP driver")
      Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NMinghuan Lian <Minghuan.Lian@nxp.com>
      Reviewed-by: NSubrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4613f46e
    • H
      PCI: mobiveil: Fix PCI base address in MEM/IO outbound windows · 51308ec5
      Hou Zhiqiang 提交于
      [ Upstream commit f99536e9d2f55996038158a6559d4254a7cc1693 ]
      
      The outbound memory windows PCI base addresses should be taken
      from the 'ranges' property of DT node to setup MEM/IO outbound
      windows decoding correctly instead of being hardcoded to zero.
      
      Update the code to retrieve the PCI base address for each range
      and use it to program the outbound windows address decoders
      
      Fixes: 9af6bcb1 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP driver")
      Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NMinghuan Lian <Minghuan.Lian@nxp.com>
      Reviewed-by: NSubrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      51308ec5
    • J
      arm64: assembler: Switch ESB-instruction with a vanilla nop if !ARM64_HAS_RAS · 05959ed8
      James Morse 提交于
      [ Upstream commit 2b68a2a963a157f024c67c0697b16f5f792c8a35 ]
      
      The ESB-instruction is a nop on CPUs that don't implement the RAS
      extensions. This lets us use it in places like the vectors without
      having to use alternatives.
      
      If someone disables CONFIG_ARM64_RAS_EXTN, this instruction still has
      its RAS extensions behaviour, but we no longer read DISR_EL1 as this
      register does depend on alternatives.
      
      This could go wrong if we want to synchronize an SError from a KVM
      guest. On a CPU that has the RAS extensions, but the KConfig option
      was disabled, we consume the pending SError with no chance of ever
      reading it.
      
      Hide the ESB-instruction behind the CONFIG_ARM64_RAS_EXTN option,
      outputting a regular nop if the feature has been disabled.
      Reported-by: NJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      05959ed8
    • V
      IB/ipoib: Add child to parent list only if device initialized · 007b01a2
      Valentine Fatiev 提交于
      [ Upstream commit 91b01061fef9c57d2f5b712a6322ef51061f4efd ]
      
      Despite failure in ipoib_dev_init() we continue with initialization flow
      and creation of child device. It causes to the situation where this child
      device is added too early to parent device list.
      
      Change the logic, so in case of failure we properly return error from
      ipoib_dev_init() and add child only in success path.
      
      Fixes: eaeb3984 ("IB/ipoib: Move init code to ndo_init")
      Signed-off-by: NValentine Fatiev <valentinef@mellanox.com>
      Reviewed-by: NFeras Daoud <ferasda@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      007b01a2
    • A
      powerpc/mm: Handle page table allocation failures · d48720ba
      Aneesh Kumar K.V 提交于
      [ Upstream commit 2230ebf6e6dd0b7751e2921b40f6cfe34f09bb16 ]
      
      This fixes kernel crash that arises due to not handling page table allocation
      failures while allocating hugetlb page table.
      
      Fixes: e2b3d202 ("powerpc: Switch 16GB and 16MB explicit hugepages to a different page table format")
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d48720ba
    • P
      IB/mlx5: Fixed reporting counters on 2nd port for Dual port RoCE · f14537bb
      Parav Pandit 提交于
      [ Upstream commit 2f40cf30c8644360d37287861d5288f00eab35e5 ]
      
      Currently during dual port IB device registration in below code flow,
      
      ib_register_device()
        ib_device_register_sysfs()
          ib_setup_port_attrs()
            add_port()
              get_counter_table()
                get_perf_mad()
                  process_mad()
                    mlx5_ib_process_mad()
      
      mlx5_ib_process_mad() fails on 2nd port when both the ports are not fully
      setup at the device level (because 2nd port is unaffiliated).
      
      As a result, get_perf_mad() registers different PMA counter group for 1st
      and 2nd port, namely pma_counter_ext and pma_counter. However both ports
      have the same capability and counter offsets.
      
      Due to this when counters are read by the user via sysfs in below code
      flow, counters are queried from wrong location from the device mainly from
      PPCNT instead of VPORT counters.
      
      show_pma_counter()
        get_perf_mad()
          process_mad()
            mlx5_ib_process_mad()
              process_pma_cmd()
      
      This shows all zero counters for 2nd port.
      
      To overcome this, process_pma_cmd() is invoked, and when unaffiliated port
      is not yet setup during device registration phase, make the query on the
      first port.  while at it, only process_pma_cmd() needs to work on the
      native port number and underlying mdev, so shift the get, put calls to
      where its needed inside process_pma_cmd().
      
      Fixes: 212f2a87 ("IB/mlx5: Route MADs for dual port RoCE")
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Reviewed-by: NDaniel Jurgens <danielj@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f14537bb
    • G
      serial: sh-sci: Fix TX DMA buffer flushing and workqueue races · d03aeb8d
      Geert Uytterhoeven 提交于
      [ Upstream commit 8493eab02608b0e82f67b892aa72882e510c31d0 ]
      
      When uart_flush_buffer() is called, the .flush_buffer() callback zeroes
      the tx_dma_len field.  This may race with the work queue function
      handling transmit DMA requests:
      
        1. If the buffer is flushed before the first DMA API call,
           dmaengine_prep_slave_single() may be called with a zero length,
           causing the DMA request to never complete, leading to messages
           like:
      
              rcar-dmac e7300000.dma-controller: Channel Address Error happen
      
           and, with debug enabled:
      
      	sh-sci e6e88000.serial: sci_dma_tx_work_fn: ffff800639b55000: 0...0, cookie 126
      
           and DMA timeouts.
      
        2. If the buffer is flushed after the first DMA API call, but before
           the second, dma_sync_single_for_device() may be called with a zero
           length, causing the transmit data not to be flushed to RAM, and
           leading to stale data being output.
      
      Fix this by:
        1. Letting sci_dma_tx_work_fn() return immediately if the transmit
           buffer is empty,
        2. Extending the critical section to cover all DMA preparational work,
           so tx_dma_len stays consistent for all of it,
        3. Using local copies of circ_buf.head and circ_buf.tail, to make sure
           they match the actual operation above.
      Reported-by: NEugeniu Rosca <erosca@de.adit-jv.com>
      Suggested-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NEugeniu Rosca <erosca@de.adit-jv.com>
      Tested-by: NEugeniu Rosca <erosca@de.adit-jv.com>
      Link: https://lore.kernel.org/r/20190624123540.20629-2-geert+renesas@glider.beSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d03aeb8d
    • G
      serial: sh-sci: Terminate TX DMA during buffer flushing · 48c73b8e
      Geert Uytterhoeven 提交于
      [ Upstream commit 775b7ffd7d6d5db320d99b0a485c51e04dfcf9f1 ]
      
      While the .flush_buffer() callback clears sci_port.tx_dma_len since
      commit 1cf4a7ef ("serial: sh-sci: Fix race condition causing
      garbage during shutdown"), it does not terminate a transmit DMA
      operation that may be in progress.
      
      Fix this by terminating any pending DMA operations, and resetting the
      corresponding cookie.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NEugeniu Rosca <erosca@de.adit-jv.com>
      Tested-by: NEugeniu Rosca <erosca@de.adit-jv.com>
      
      Link: https://lore.kernel.org/r/20190624123540.20629-3-geert+renesas@glider.beSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      48c73b8e
    • L
      RDMA/i40iw: Set queue pair state when being queried · ca730bf0
      Liu, Changcheng 提交于
      [ Upstream commit 2e67e775845373905d2c2aecb9062c2c4352a535 ]
      
      The API for ib_query_qp requires the driver to set qp_state and
      cur_qp_state on return, add the missing sets.
      
      Fixes: d3749841 ("i40iw: add files for iwarp interface")
      Signed-off-by: NChangcheng Liu <changcheng.liu@aliyun.com>
      Acked-by: NShiraz Saleem <shiraz.saleem@intel.com>
      Reviewed-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ca730bf0
    • C
      powerpc/4xx/uic: clear pending interrupt after irq type/pol change · 52373ab6
      Christian Lamparter 提交于
      [ Upstream commit 3ab3a0689e74e6aa5b41360bc18861040ddef5b1 ]
      
      When testing out gpio-keys with a button, a spurious
      interrupt (and therefore a key press or release event)
      gets triggered as soon as the driver enables the irq
      line for the first time.
      
      This patch clears any potential bogus generated interrupt
      that was caused by the switching of the associated irq's
      type and polarity.
      Signed-off-by: NChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      52373ab6
    • J
      um: Silence lockdep complaint about mmap_sem · 74520144
      Johannes Berg 提交于
      [ Upstream commit 80bf6ceaf9310b3f61934c69b382d4912deee049 ]
      
      When we get into activate_mm(), lockdep complains that we're doing
      something strange:
      
          WARNING: possible circular locking dependency detected
          5.1.0-10252-gb00152307319-dirty #121 Not tainted
          ------------------------------------------------------
          inside.sh/366 is trying to acquire lock:
          (____ptrval____) (&(&p->alloc_lock)->rlock){+.+.}, at: flush_old_exec+0x703/0x8d7
      
          but task is already holding lock:
          (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7
      
          which lock already depends on the new lock.
      
          the existing dependency chain (in reverse order) is:
      
          -> #1 (&mm->mmap_sem){++++}:
                 [...]
                 __lock_acquire+0x12ab/0x139f
                 lock_acquire+0x155/0x18e
                 down_write+0x3f/0x98
                 flush_old_exec+0x748/0x8d7
                 load_elf_binary+0x2ca/0xddb
                 [...]
      
          -> #0 (&(&p->alloc_lock)->rlock){+.+.}:
                 [...]
                 __lock_acquire+0x12ab/0x139f
                 lock_acquire+0x155/0x18e
                 _raw_spin_lock+0x30/0x83
                 flush_old_exec+0x703/0x8d7
                 load_elf_binary+0x2ca/0xddb
                 [...]
      
          other info that might help us debug this:
      
           Possible unsafe locking scenario:
      
                 CPU0                    CPU1
                 ----                    ----
            lock(&mm->mmap_sem);
                                         lock(&(&p->alloc_lock)->rlock);
                                         lock(&mm->mmap_sem);
            lock(&(&p->alloc_lock)->rlock);
      
           *** DEADLOCK ***
      
          2 locks held by inside.sh/366:
           #0: (____ptrval____) (&sig->cred_guard_mutex){+.+.}, at: __do_execve_file+0x12d/0x869
           #1: (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7
      
          stack backtrace:
          CPU: 0 PID: 366 Comm: inside.sh Not tainted 5.1.0-10252-gb00152307319-dirty #121
          Stack:
           [...]
          Call Trace:
           [<600420de>] show_stack+0x13b/0x155
           [<6048906b>] dump_stack+0x2a/0x2c
           [<6009ae64>] print_circular_bug+0x332/0x343
           [<6009c5c6>] check_prev_add+0x669/0xdad
           [<600a06b4>] __lock_acquire+0x12ab/0x139f
           [<6009f3d0>] lock_acquire+0x155/0x18e
           [<604a07e0>] _raw_spin_lock+0x30/0x83
           [<60151e6a>] flush_old_exec+0x703/0x8d7
           [<601a8eb8>] load_elf_binary+0x2ca/0xddb
           [...]
      
      I think it's because in exec_mmap() we have
      
      	down_read(&old_mm->mmap_sem);
      ...
              task_lock(tsk);
      ...
      	activate_mm(active_mm, mm);
      	(which does down_write(&mm->mmap_sem))
      
      I'm not really sure why lockdep throws in the whole knowledge
      about the task lock, but it seems that old_mm and mm shouldn't
      ever be the same (and it doesn't deadlock) so tell lockdep that
      they're different.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      74520144
    • I
      mm/swap: fix release_pages() when releasing devmap pages · 30edc7c1
      Ira Weiny 提交于
      [ Upstream commit c5d6c45e90c49150670346967971e14576afd7f1 ]
      
      release_pages() is an optimized version of a loop around put_page().
      Unfortunately for devmap pages the logic is not entirely correct in
      release_pages().  This is because device pages can be more than type
      MEMORY_DEVICE_PUBLIC.  There are in fact 4 types, private, public, FS DAX,
      and PCI P2PDMA.  Some of these have specific needs to "put" the page while
      others do not.
      
      This logic to handle any special needs is contained in
      put_devmap_managed_page().  Therefore all devmap pages should be processed
      by this function where we can contain the correct logic for a page put.
      
      Handle all device type pages within release_pages() by calling
      put_devmap_managed_page() on all devmap pages.  If
      put_devmap_managed_page() returns true the page has been put and we
      continue with the next page.  A false return of put_devmap_managed_page()
      means the page did not require special processing and should fall to
      "normal" processing.
      
      This was found via code inspection while determining if release_pages()
      and the new put_user_pages() could be interchangeable.[1]
      
      [1] https://lkml.kernel.org/r/20190523172852.GA27175@iweiny-DESK2.sc.intel.com
      
      Link: https://lkml.kernel.org/r/20190605214922.17684-1-ira.weiny@intel.com
      Cc: Jérôme Glisse <jglisse@redhat.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Reviewed-by: NDan Williams <dan.j.williams@intel.com>
      Reviewed-by: NJohn Hubbard <jhubbard@nvidia.com>
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      30edc7c1
    • A
      mfd: hi655x-pmic: Fix missing return value check for devm_regmap_init_mmio_clk · b4e77006
      Axel Lin 提交于
      [ Upstream commit 7efd105c27fd2323789b41b64763a0e33ed79c08 ]
      
      Since devm_regmap_init_mmio_clk can fail, add return value checking.
      Signed-off-by: NAxel Lin <axel.lin@ingics.com>
      Acked-by: NChen Feng <puck.chen@hisilicon.com>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b4e77006
    • A
      mfd: arizona: Fix undefined behavior · 9b1691c3
      Arnd Bergmann 提交于
      [ Upstream commit 5da6cbcd2f395981aa9bfc571ace99f1c786c985 ]
      
      When the driver is used with a subdevice that is disabled in the
      kernel configuration, clang gets a little confused about the
      control flow and fails to notice that n_subdevs is only
      uninitialized when subdevs is NULL, and we check for that,
      leading to a false-positive warning:
      
      drivers/mfd/arizona-core.c:1423:19: error: variable 'n_subdevs' is uninitialized when used here
            [-Werror,-Wuninitialized]
                                    subdevs, n_subdevs, NULL, 0, NULL);
                                             ^~~~~~~~~
      drivers/mfd/arizona-core.c:999:15: note: initialize the variable 'n_subdevs' to silence this warning
              int n_subdevs, ret, i;
                           ^
                            = 0
      
      Ideally, we would rearrange the code to avoid all those early
      initializations and have an explicit exit in each disabled case,
      but it's much easier to chicken out and add one more initialization
      here to shut up the warning.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9b1691c3
    • R
      mfd: core: Set fwnode for created devices · d9c74176
      Robert Hancock 提交于
      [ Upstream commit c176c6d7e932662668bcaec2d763657096589d85 ]
      
      The logic for setting the of_node on devices created by mfd did not set
      the fwnode pointer to match, which caused fwnode-based APIs to
      malfunction on these devices since the fwnode pointer was null. Fix
      this.
      Signed-off-by: NRobert Hancock <hancock@sedsystems.ca>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d9c74176
    • D
      mfd: madera: Add missing of table registration · 7b24a4a3
      Daniel Gomez 提交于
      [ Upstream commit 5aa3709c0a5c026735b0ddd4ec80810a23d65f5b ]
      
      MODULE_DEVICE_TABLE(of, <of_match_table>) should be called to complete DT
      OF mathing mechanism and register it.
      
      Before this patch:
      modinfo ./drivers/mfd/madera.ko | grep alias
      
      After this patch:
      modinfo ./drivers/mfd/madera.ko | grep alias
      alias:          of:N*T*Ccirrus,wm1840C*
      alias:          of:N*T*Ccirrus,wm1840
      alias:          of:N*T*Ccirrus,cs47l91C*
      alias:          of:N*T*Ccirrus,cs47l91
      alias:          of:N*T*Ccirrus,cs47l90C*
      alias:          of:N*T*Ccirrus,cs47l90
      alias:          of:N*T*Ccirrus,cs47l85C*
      alias:          of:N*T*Ccirrus,cs47l85
      alias:          of:N*T*Ccirrus,cs47l35C*
      alias:          of:N*T*Ccirrus,cs47l35
      Reported-by: NJavier Martinez Canillas <javier@dowhile0.org>
      Signed-off-by: NDaniel Gomez <dagmcr@gmail.com>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7b24a4a3
    • N
      recordmcount: Fix spurious mcount entries on powerpc · e00cf1da
      Naveen N. Rao 提交于
      [ Upstream commit 80e5302e4bc85a6b685b7668c36c6487b5f90e9a ]
      
      An impending change to enable HAVE_C_RECORDMCOUNT on powerpc leads to
      warnings such as the following:
      
        # modprobe kprobe_example
        ftrace-powerpc: Not expected bl: opcode is 3c4c0001
        WARNING: CPU: 0 PID: 227 at kernel/trace/ftrace.c:2001 ftrace_bug+0x90/0x318
        Modules linked in:
        CPU: 0 PID: 227 Comm: modprobe Not tainted 5.2.0-rc6-00678-g1c329100b942 #2
        NIP:  c000000000264318 LR: c00000000025d694 CTR: c000000000f5cd30
        REGS: c000000001f2b7b0 TRAP: 0700   Not tainted  (5.2.0-rc6-00678-g1c329100b942)
        MSR:  900000010282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 28228222  XER: 00000000
        CFAR: c0000000002642fc IRQMASK: 0
        <snip>
        NIP [c000000000264318] ftrace_bug+0x90/0x318
        LR [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0
        Call Trace:
        [c000000001f2ba40] [0000000000000004] 0x4 (unreliable)
        [c000000001f2bad0] [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0
        [c000000001f2bb90] [c00000000020ff10] load_module+0x25b0/0x30c0
        [c000000001f2bd00] [c000000000210cb0] sys_finit_module+0xc0/0x130
        [c000000001f2be20] [c00000000000bda4] system_call+0x5c/0x70
        Instruction dump:
        419e0018 2f83ffff 419e00bc 2f83ffea 409e00cc 4800001c 0fe00000 3c62ff96
        39000001 39400000 386386d0 480000c4 <0fe00000> 3ce20003 39000001 3c62ff96
        ---[ end trace 4c438d5cebf78381 ]---
        ftrace failed to modify
        [<c0080000012a0008>] 0xc0080000012a0008
         actual:   01:00:4c:3c
        Initializing ftrace call sites
        ftrace record flags: 2000000
         (0)
         expected tramp: c00000000006af4c
      
      Looking at the relocation records in __mcount_loc shows a few spurious
      entries:
      
        RELOCATION RECORDS FOR [__mcount_loc]:
        OFFSET           TYPE              VALUE
        0000000000000000 R_PPC64_ADDR64    .text.unlikely+0x0000000000000008
        0000000000000008 R_PPC64_ADDR64    .text.unlikely+0x0000000000000014
        0000000000000010 R_PPC64_ADDR64    .text.unlikely+0x0000000000000060
        0000000000000018 R_PPC64_ADDR64    .text.unlikely+0x00000000000000b4
        0000000000000020 R_PPC64_ADDR64    .init.text+0x0000000000000008
        0000000000000028 R_PPC64_ADDR64    .init.text+0x0000000000000014
      
      The first entry in each section is incorrect. Looking at the
      relocation records, the spurious entries correspond to the
      R_PPC64_ENTRY records:
      
        RELOCATION RECORDS FOR [.text.unlikely]:
        OFFSET           TYPE              VALUE
        0000000000000000 R_PPC64_REL64     .TOC.-0x0000000000000008
        0000000000000008 R_PPC64_ENTRY     *ABS*
        0000000000000014 R_PPC64_REL24     _mcount
        <snip>
      
      The problem is that we are not validating the return value from
      get_mcountsym() in sift_rel_mcount(). With this entry, mcountsym is 0,
      but Elf_r_sym(relp) also ends up being 0. Fix this by ensuring
      mcountsym is valid before processing the entry.
      Signed-off-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Tested-by: NSatheesh Rajendran <sathnaga@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e00cf1da