1. 13 Jan, 2019 40 commits
    • Shuah Khan's avatar
      selftests: Fix test errors related to lib.mk khdr target · a05257f9
      Shuah Khan authored
      commit 211929fd upstream.
      Commit b2d35fa5 ("selftests: add headers_install to lib.mk") added
      khdr target to run headers_install target from the main Makefile. The
      logic uses KSFT_KHDR_INSTALL and top_srcdir as controls to initialize
      variables and include files to run headers_install from the top level
      Makefile. There are a few problems with this logic.
      1. Exposes top_srcdir to all tests
      2. Common logic impacts all tests
      3. Uses KSFT_KHDR_INSTALL, top_srcdir, and khdr in an adhoc way. Tests
         add "khdr" dependency in their Makefiles to TEST_PROGS_EXTENDED in
         some cases, and STATIC_LIBS in other cases. This makes this framework
         confusing to use.
      The common logic that runs for all tests even when KSFT_KHDR_INSTALL
      isn't defined by the test. top_srcdir is initialized to a default value
      when test doesn't initialize it. It works for all tests without a sub-dir
      structure and tests with sub-dir structure fail to build.
      e.g: make -C sparc64/drivers/ or make -C drivers/dma-buf
      ../../lib.mk:20: ../../../../scripts/subarch.include: No such file or directory
      make: *** No rule to make target '../../../../scripts/subarch.include'.  Stop.
      There is no reason to require all tests to define top_srcdir and there is
      no need to require tests to add khdr dependency using adhoc changes to
      TEST_* and other variables.
      Fix it with a consistent use of KSFT_KHDR_INSTALL and top_srcdir from tests
      that have the dependency on headers_install.
      Change common logic to include khdr target define and "all" target with
      dependency on khdr when KSFT_KHDR_INSTALL is defined.
      Only tests that have dependency on headers_install have to define just
      the KSFT_KHDR_INSTALL, and top_srcdir variables and there is no need to
      specify khdr dependency in the test Makefiles.
      Fixes: b2d35fa5 ("selftests: add headers_install to lib.mk")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarShuah Khan <shuah@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Christian Lamparter's avatar
      powerpc/4xx/ocm: Fix compilation error due to PAGE_KERNEL usage · 178538f8
      Christian Lamparter authored
      commit d0757237 upstream.
      This patch fixes a recent compilation regression in ocm:
        ocm.c: In function ‘ocm_init_node’:
        ocm.c:182:18: error: invalid operands to binary |
              (have ‘int’ and ‘pgprot_t’ {aka ‘struct <anonymous>’})
              _PAGE_EXEC | PAGE_KERNEL_NCG);
        ocm.c:197:17: error: invalid operands to binary |
              (have ‘int’ and ‘pgprot_t’ {aka ‘struct <anonymous>’})
               _PAGE_EXEC | PAGE_KERNEL);
      Fixes: 56f3c141 ("powerpc/mm: properly set PAGE_KERNEL flags in ioremap()")
      Cc: stable@vger.kernel.org # v4.20
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Reviewed-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Shaokun Zhang's avatar
      drivers/perf: hisi: Fixup one DDRC PMU register offset · bb9cc97b
      Shaokun Zhang authored
      commit eb4f5213 upstream.
      For DDRC PMU, each PMU counter is fixed-purpose. There is a mismatch
      between perf list and driver definition on rw_chg event.
      # perf list | grep chg
        hisi_sccl1_ddrc0/rnk_chg/                          [Kernel PMU event]
        hisi_sccl1_ddrc0/rw_chg/                           [Kernel PMU event]
      But the register offset of rw_chg event is not defined in the driver,
      meanwhile bnk_chg register offset is mis-defined, let's fixup it.
      Fixes: 904dcf03 ("perf: hisi: Add support for HiSilicon SoC DDRC PMU driver")
      Cc: stable@vger.kernel.org
      Cc: John Garry <john.garry@huawei.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarWeijian Huang <huangweijian4@hisilicon.com>
      Signed-off-by: default avatarShaokun Zhang <zhangshaokun@hisilicon.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • YueHaibing's avatar
      video: fbdev: pxafb: Fix "WARNING: invalid free of devm_ allocated data" · d0e9298c
      YueHaibing authored
      commit 26073918 upstream.
      'info->modes' got allocated with devm_kcalloc in of_get_pxafb_display.
      This gives this error message:
        ./drivers/video/fbdev/pxafb.c:2238:2-7: WARNING: invalid free of devm_ allocated data
      Fixes: c8f96304 ("video: fbdev: pxafb: switch to devm_* API")
      Cc: stable@kernel.org [v4.19+]
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarDaniel Mack <daniel@zonque.org>
      Cc: Robert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Yan, Zheng's avatar
      ceph: don't update importing cap's mseq when handing cap export · 1b308355
      Yan, Zheng authored
      commit 3c1392d4 upstream.
      Updating mseq makes client think importer mds has accepted all prior
      cap messages and importer mds knows what caps client wants. Actually
      some cap messages may have been dropped because of mseq mismatch.
      If mseq is left untouched, importing cap's mds_wanted later will get
      reset by cap import message.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Linus Torvalds's avatar
      sched/fair: Fix infinite loop in update_blocked_averages() by reverting a9e7f654 · 7a400b91
      Linus Torvalds authored
      commit c40f7d74 upstream.
      Zhipeng Xie, Xie XiuQi and Sargun Dhillon reported lockups in the
      scheduler under high loads, starting at around the v4.18 time frame,
      and Zhipeng Xie tracked it down to bugs in the rq->leaf_cfs_rq_list
      Do a (manual) revert of:
        a9e7f654 ("sched/fair: Fix O(nr_cgroups) in load balance path")
      It turns out that the list_del_leaf_cfs_rq() introduced by this commit
      is a surprising property that was not considered in followup commits
      such as:
        9c2791f9 ("sched/fair: Fix hierarchical order in rq->leaf_cfs_rq_list")
      As Vincent Guittot explains:
       "I think that there is a bigger problem with commit a9e7f654 and
        cfs_rq throttling:
        Let take the example of the following topology TG2 --> TG1 --> root:
         1) The 1st time a task is enqueued, we will add TG2 cfs_rq then TG1
            cfs_rq to leaf_cfs_rq_list and we are sure to do the whole branch in
            one path because it has never been used and can't be throttled so
            tmp_alone_branch will point to leaf_cfs_rq_list at the end.
         2) Then TG1 is throttled
         3) and we add TG3 as a new child of TG1.
         4) The 1st enqueue of a task on TG3 will add TG3 cfs_rq just before TG1
            cfs_rq and tmp_alone_branch will stay  on rq->leaf_cfs_rq_list.
        With commit a9e7f654, we can del a cfs_rq from rq->leaf_cfs_rq_list.
        So if the load of TG1 cfs_rq becomes NULL before step 2) above, TG1
        cfs_rq is removed from the list.
        Then at step 4), TG3 cfs_rq is added at the beginning of rq->leaf_cfs_rq_list
        but tmp_alone_branch still points to TG3 cfs_rq because its throttled
        parent can't be enqueued when the lock is released.
        tmp_alone_branch doesn't point to rq->leaf_cfs_rq_list whereas it should.
        So if TG3 cfs_rq is removed or destroyed before tmp_alone_branch
        points on another TG cfs_rq, the next TG cfs_rq that will be added,
        will be linked outside rq->leaf_cfs_rq_list - which is bad.
        In addition, we can break the ordering of the cfs_rq in
        rq->leaf_cfs_rq_list but this ordering is used to update and
        propagate the update from leaf down to root."
      Instead of trying to work through all these cases and trying to reproduce
      the very high loads that produced the lockup to begin with, simplify
      the code temporarily by reverting a9e7f654 - which change was clearly
      not thought through completely.
      This (hopefully) gives us a kernel that doesn't lock up so people
      can continue to enjoy their holidays without worrying about regressions. ;-)
      [ mingo: Wrote changelog, fixed weird spelling in code comment while at it. ]
      Analyzed-by: default avatarXie XiuQi <xiexiuqi@huawei.com>
      Analyzed-by: default avatarVincent Guittot <vincent.guittot@linaro.org>
      Reported-by: default avatarZhipeng Xie <xiezhipeng1@huawei.com>
      Reported-by: Sargun Dhillon's avatarSargun Dhillon <sargun@sargun.me>
      Reported-by: default avatarXie XiuQi <xiexiuqi@huawei.com>
      Tested-by: default avatarZhipeng Xie <xiezhipeng1@huawei.com>
      Tested-by: Sargun Dhillon's avatarSargun Dhillon <sargun@sargun.me>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: default avatarVincent Guittot <vincent.guittot@linaro.org>
      Cc: <stable@vger.kernel.org> # v4.13+
      Cc: Bin Li <huawei.libin@huawei.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: a9e7f654 ("sched/fair: Fix O(nr_cgroups) in load balance path")
      Link: http://lkml.kernel.org/r/1545879866-27809-1-git-send-email-xiexiuqi@huawei.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Sohil Mehta's avatar
      iommu/vt-d: Handle domain agaw being less than iommu agaw · 8c47bf0c
      Sohil Mehta authored
      commit 3569dd07 upstream.
      The Intel IOMMU driver opportunistically skips a few top level page
      tables from the domain paging directory while programming the IOMMU
      context entry. However there is an implicit assumption in the code that
      domain's adjusted guest address width (agaw) would always be greater
      than IOMMU's agaw.
      The IOMMU capabilities in an upcoming platform cause the domain's agaw
      to be lower than IOMMU's agaw. The issue is seen when the IOMMU supports
      both 4-level and 5-level paging. The domain builds a 4-level page table
      based on agaw of 2. However the IOMMU's agaw is set as 3 (5-level). In
      this case the code incorrectly tries to skip page page table levels.
      This causes the IOMMU driver to avoid programming the context entry. The
      fix handles this case and programs the context entry accordingly.
      Fixes: de24e553 ("iommu/vt-d: Simplify domain_context_mapping_one")
      Cc: <stable@vger.kernel.org>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
      Cc: Lu Baolu <baolu.lu@linux.intel.com>
      Reviewed-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Reported-by: default avatarRamos Falcon, Ernesto R <ernesto.r.ramos.falcon@intel.com>
      Tested-by: default avatarRicardo Neri <ricardo.neri-calderon@linux.intel.com>
      Signed-off-by: default avatarSohil Mehta <sohil.mehta@intel.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Steve Wise's avatar
      RDMA/iwcm: Don't copy past the end of dev_name() string · de3b4f54
      Steve Wise authored
      commit d53ec8af upstream.
      We now use dev_name(&ib_device->dev) instead of ib_device->name in iwpm
      messages.  The name field in struct device is a const char *, where as
      ib_device->name is a char array of size IB_DEVICE_NAME_MAX, and it is
      pre-initialized to zeros.
      Since iw_cm_map() was using memcpy() to copy in the device name, and
      copying IWPM_DEVNAME_SIZE bytes, it ends up copying past the end of the
      source device name string and copying random bytes.  This results in iwpmd
      failing the REGISTER_PID request from iwcm.  Thus port mapping is broken.
      Validate the device and if names, and use strncpy() to inialize the entire
      message field.
      Fixes: 896de009 ("RDMA/core: Use dev_name instead of ibdev->name")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Bart Van Assche's avatar
      RDMA/srpt: Fix a use-after-free in the channel release code · e4387615
      Bart Van Assche authored
      commit ed041919 upstream.
      This patch avoids that KASAN sporadically reports the following:
      BUG: KASAN: use-after-free in rxe_run_task+0x1e/0x60 [rdma_rxe]
      Read of size 1 at addr ffff88801c50d8f4 by task check/24830
      CPU: 4 PID: 24830 Comm: check Not tainted 4.20.0-rc6-dbg+ #3
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
      Call Trace:
       rxe_run_task+0x1e/0x60 [rdma_rxe]
       rxe_post_send+0x4bd/0x8d0 [rdma_rxe]
       srpt_zerolength_write+0xe1/0x160 [ib_srpt]
       srpt_close_ch+0x8b/0xe0 [ib_srpt]
       srpt_set_enabled+0xe7/0x150 [ib_srpt]
       srpt_tpg_enable_store+0xc0/0x100 [ib_srpt]
      Allocated by task 13856:
       rxe_alloc+0xff/0x1f0 [rdma_rxe]
       rxe_create_qp+0x9f/0x160 [rdma_rxe]
       ib_create_qp+0xf5/0x690 [ib_core]
       rdma_create_qp+0x6a/0x140 [rdma_cm]
       srpt_cm_req_recv.cold.59+0x1588/0x237b [ib_srpt]
       srpt_rdma_cm_req_recv.isra.35+0x1d5/0x220 [ib_srpt]
       srpt_rdma_cm_handler+0x6f/0x100 [ib_srpt]
       cma_listen_handler+0x59/0x60 [rdma_cm]
       cma_ib_req_handler+0xd5b/0x2570 [rdma_cm]
       cm_process_work+0x2e/0x110 [ib_cm]
       cm_work_handler+0x2aae/0x502b [ib_cm]
      Freed by task 3440:
       rxe_elem_release+0x66/0xe0 [rdma_rxe]
       rxe_destroy_qp+0x3f/0x50 [rdma_rxe]
       ib_destroy_qp+0x140/0x360 [ib_core]
       srpt_release_channel_work+0xdc/0x310 [ib_srpt]
      Cc: Sergey Gorenko <sergeygo@mellanox.com>
      Cc: Max Gurtovoy <maxg@mellanox.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: Doug Ledford's avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alexander Shishkin's avatar
      stm class: Fix a module refcount leak in policy creation error path · a64a09ed
      Alexander Shishkin authored
      commit c18614a1 upstream.
      Commit c7fd62bc ("stm class: Introduce framing protocol drivers")
      adds a bug into the error path of policy creation, that would do a
      module_put() on a wrong module, if one tried to create a policy for
      an stm device which already has a policy, using a different protocol.
      | mkdir /config/stp-policy/dummy_stm.0:p_basic.test
      | mkdir /config/stp-policy/dummy_stm.0:p_sys-t.test # puts "p_basic"
      | mkdir /config/stp-policy/dummy_stm.0:p_sys-t.test # "p_basic" -> -1
      | general protection fault: 0000 [#1] SMP PTI
      | CPU: 3 PID: 2887 Comm: mkdir
      | RIP: 0010:module_put.part.31+0xe/0x90
      | Call Trace:
      |  module_put+0x13/0x20
      |  stm_put_protocol+0x11/0x20 [stm_core]
      |  stp_policy_make+0xf1/0x210 [stm_core]
      |  ? __kmalloc+0x183/0x220
      |  ? configfs_mkdir+0x10d/0x4c0
      |  configfs_mkdir+0x169/0x4c0
      |  vfs_mkdir+0x108/0x1c0
      |  do_mkdirat+0xe8/0x110
      |  __x64_sys_mkdir+0x1b/0x20
      |  do_syscall_64+0x5a/0x140
      |  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      Correct this sad mistake by calling calling 'put' on the correct
      reference, which happens to match another error path in the same
      function, so we consolidate the two at the same time.
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Fixes: c7fd62bc ("stm class: Introduce framing protocol drivers")
      Reported-by: default avatarAmmy Yi <ammy.yi@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Sagi Grimberg's avatar
      rxe: fix error completion wr_id and qp_num · 739f7f1b
      Sagi Grimberg authored
      commit e48d8ed9 upstream.
      Error completions must still contain a valid wr_id and
      qp_num such that the consumer can rely on. Correctly
      fill these fields in receive error completions.
      Reported-by: Ben Walker's avatarWalker Benjamin <benjamin.walker@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: Sagi Grimberg's avatarSagi Grimberg <sagi@grimberg.me>
      Reviewed-by: default avatarZhu Yanjun <yanjun.zhu@oracle.com>
      Tested-by: default avatarZhu Yanjun <yanjun.zhu@oracle.com>
      Signed-off-by: Doug Ledford's avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dominique Martinet's avatar
      9p/net: put a lower bound on msize · 7030ab2d
      Dominique Martinet authored
      commit 574d356b upstream.
      If the requested msize is too small (either from command line argument
      or from the server version reply), we won't get any work done.
      If it's *really* too small, nothing will work, and this got caught by
      syzbot recently (on a new kmem_cache_create_usercopy() call)
      Just set a minimum msize to 4k in both code paths, until someone
      complains they have a use-case for a smaller msize.
      We need to check in both mount option and server reply individually
      because the msize for the first version request would be unchecked
      with just a global check on clnt->msize.
      Link: http://lkml.kernel.org/r/1541407968-31350-1-git-send-email-asmadeus@codewreck.org
      Reported-by: syzbot+0c1d61e4db7db94102ca@syzkaller.appspotmail.com
      Signed-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Latchesar Ionkov <lucho@ionkov.net>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mircea Caprioru's avatar
      iio: dac: ad5686: fix bit shift read register · 0fc78fa0
      Mircea Caprioru authored
      commit 0e76df5c upstream.
      This patch solves the register readback issue with the bit shift. When the
      dac resolution was lower than the register size (ex. 12 bits out of 16
      bits) the readback value was not shifted with the difference in bits and
      the value was higher. Also a mask is applied on the read value in order to
      get the value relative to the actual bit size.
      Fixes: 0357e488 ("iio:dac:ad5686: Refactor the driver")
      Signed-off-by: default avatarMircea Caprioru <mircea.caprioru@analog.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Evan Green's avatar
      iio: adc: qcom-spmi-adc5: Initialize prescale properly · 30533049
      Evan Green authored
      commit db23d887 upstream.
      adc5_get_dt_data uses a local, prop, feeds it to adc5_get_dt_channel_data,
      and then puts the result into adc->chan_props. The problem is
      adc5_get_dt_channel_data may not initialize that structure fully, so a
      garbage value is used for prescale if the optional "qcom,pre-scaling" is
      not defined in DT. adc5_read_raw then uses this as an array index,
      generating a crash that looks like this:
      [    6.683186] Unable to handle kernel paging request at virtual address ffffff90e78c7964
      Call trace:
      Unfortunately, when I went to add the initializer for this and tried to
      boot it, my machine shut down immediately, complaining that it was
      hotter than the sun. It appears that adc5_chans_pmic and adc5_chans_rev2
      were initializing prescale_index as if it were directly a divisor,
      rather than the index into adc5_prescale_ratios that it is.
      Fix the uninitialized value, and change the static initialization to use
      indices into adc5_prescale_ratios.
      Signed-off-by: default avatarEvan Green <evgreen@chromium.org>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Breno Leitao's avatar
      powerpc/tm: Set MSR[TS] just prior to recheckpoint · 21e5f402
      Breno Leitao authored
      commit e1c3743e upstream.
      On a signal handler return, the user could set a context with MSR[TS] bits
      set, and these bits would be copied to task regs->msr.
      At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set,
      several __get_user() are called and then a recheckpoint is executed.
      This is a problem since a page fault (in kernel space) could happen when
      calling __get_user(). If it happens, the process MSR[TS] bits were
      already set, but recheckpoint was not executed, and SPRs are still invalid.
      The page fault can cause the current process to be de-scheduled, with
      MSR[TS] active and without tm_recheckpoint() being called.  More
      importantly, without TEXASR[FS] bit set also.
      Since TEXASR might not have the FS bit set, and when the process is
      scheduled back, it will try to reclaim, which will be aborted because of
      the CPU is not in the suspended state, and, then, recheckpoint. This
      recheckpoint will restore thread->texasr into TEXASR SPR, which might be
      zero, hitting a BUG_ON().
      	kernel BUG at /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
      	cpu 0xb: Vector: 700 (Program Check) at [c00000041f1576d0]
      	    pc: c000000000054550: restore_gprs+0xb0/0x180
      	    lr: 0000000000000000
      	    sp: c00000041f157950
      	   msr: 8000000100021033
      	  current = 0xc00000041f143000
      	  paca    = 0xc00000000fb86300	 softe: 0	 irq_happened: 0x01
      	    pid   = 1021, comm = kworker/11:1
      	kernel BUG at /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
      	Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)
      	enter ? for help
      	[c00000041f157b30] c00000000001bc3c tm_recheckpoint.part.11+0x6c/0xa0
      	[c00000041f157b70] c00000000001d184 __switch_to+0x1e4/0x4c0
      	[c00000041f157bd0] c00000000082eeb8 __schedule+0x2f8/0x990
      	[c00000041f157cb0] c00000000082f598 schedule+0x48/0xc0
      	[c00000041f157ce0] c0000000000f0d28 worker_thread+0x148/0x610
      	[c00000041f157d80] c0000000000f96b0 kthread+0x120/0x140
      	[c00000041f157e30] c00000000000c0e0 ret_from_kernel_thread+0x5c/0x7c
      This patch simply delays the MSR[TS] set, so, if there is any page fault in
      the __get_user() section, it does not have regs->msr[TS] set, since the TM
      structures are still invalid, thus avoiding doing TM operations for
      in-kernel exceptions and possible process reschedule.
      With this patch, the MSR[TS] will only be set just before recheckpointing
      and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in
      invalid state.
      Other than that, if CONFIG_PREEMPT is set, there might be a preemption just
      after setting MSR[TS] and before tm_recheckpoint(), thus, this block must
      be atomic from a preemption perspective, thus, calling
      preempt_disable/enable() on this code.
      It is not possible to move tm_recheckpoint to happen earlier, because it is
      required to get the checkpointed registers from userspace, with
      __get_user(), thus, the only way to avoid this undesired behavior is
      delaying the MSR[TS] set.
      The 32-bits signal handler seems to be safe this current issue, but, it
      might be exposed to the preemption issue, thus, disabling preemption in
      this chunk of code.
      Changes from v2:
       * Run the critical section with preempt_disable.
      Fixes: 87b4e539 ("powerpc/tm: Fix return of active 64bit signals")
      Cc: stable@vger.kernel.org (v3.9+)
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Greg Kroah-Hartman's avatar
      Revert "powerpc/tm: Unset MSR[TS] if not recheckpointing" · cecc8920
      Greg Kroah-Hartman authored
      This reverts commit d412deb8 which is
      commit 6f5b9f01 upstream.
      It breaks the powerpc build, so drop it from the tree until a fix goes
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: Breno Leitao <leitao@debian.org>
      Cc: Michal Suchánek <msuchanek@suse.de>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • J. Bruce Fields's avatar
      nfsd4: zero-length WRITE should succeed · 0a1246ed
      J. Bruce Fields authored
      commit fdec6114 upstream.
      Zero-length writes are legal; from 5661 section 18.32.3: "If the count
      is zero, the WRITE will succeed and return a count of zero subject to
      permissions checking".
      This check is unnecessary and is causing zero-length reads to return
      Cc: stable@vger.kernel.org
      Fixes: 3fd9557a "NFSD: Refactor the generic write vector fill helper"
      Cc: Chuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Chuck Lever's avatar
      xprtrdma: Yet another double DMA-unmap · c7e10e59
      Chuck Lever authored
      commit e2f34e26 upstream.
      While chasing yet another set of DMAR fault reports, I noticed that
      the frwr recycler conflates whether or not an MR has been DMA
      unmapped with frwr->fr_state. Actually the two have only an indirect
      relationship. It's in fact impossible to guess reliably whether the
      MR has been DMA unmapped based on its fr_state field, especially as
      the surrounding code and its assumptions have changed over time.
      A better approach is to track the DMA mapping status explicitly so
      that the recycler is less brittle to unexpected situations, and
      attempts to DMA-unmap a second time are prevented.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: stable@vger.kernel.org # v4.20
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Benjamin Coddington's avatar
      lockd: Show pid of lockd for remote locks · 2fd246ad
      Benjamin Coddington authored
      commit b8eee0e9 upstream.
      Commit 9d5b86ac ("fs/locks: Remove fl_nspid and use fs-specific l_pid
      for remote locks") specified that the l_pid returned for F_GETLK on a local
      file that has a remote lock should be the pid of the lock manager process.
      That commit, while updating other filesystems, failed to update lockd, such
      that locks created by lockd had their fl_pid set to that of the remote
      process holding the lock.  Fix that here to be the pid of lockd.
      Also, fix the client case so that the returned lock pid is negative, which
      indicates a remote lock on a remote file.
      Fixes: 9d5b86ac ("fs/locks: Remove fl_nspid and use fs-specific...")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jarkko Nikula's avatar
      PCI / PM: Allow runtime PM without callback functions · 39e1be32
      Jarkko Nikula authored
      commit c5eb1190 upstream.
      a9c8088c ("i2c: i801: Don't restore config registers on runtime PM")
      nullified the runtime PM suspend/resume callback pointers while keeping the
      runtime PM enabled.
      This caused the SMBus PCI device to stay in D0 with
      /sys/devices/.../power/runtime_status showing "error" when the runtime PM
      framework attempted to autosuspend the device.  This is due to PCI bus
      runtime PM, which checks for driver runtime PM callbacks and returns
      -ENOSYS if they are not set.
      Since i2c-i801.c doesn't need to do anything device-specific for runtime
      PM, Jean Delvare proposed this be fixed in the PCI core rather than adding
      dummy runtime PM callback functions in the PCI drivers.
      Change pci_pm_runtime_suspend()/pci_pm_runtime_resume() so they allow
      changing the PCI device power state during runtime PM transitions even if
      the driver supplies no runtime PM callbacks.
      This fixes the runtime PM regression on i2c-i801.c.
      It is not obvious why the code previously required the runtime PM
      callbacks.  The test has been there since the code was introduced by
      6cbf8214 ("PCI PM: Run-time callbacks for PCI bus type").
      On the other hand, a similar change was done to generic runtime PM
      callbacks in 05aa55dd ("PM / Runtime: Lenient generic runtime pm
      Fixes: a9c8088c ("i2c: i801: Don't restore config registers on runtime PM")
      Reported-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarJean Delvare <jdelvare@suse.de>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: stable@vger.kernel.org	# v4.18+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ondrej Mosnáček's avatar
      selinux: policydb - fix byte order and alignment issues · 33068413
      Ondrej Mosnáček authored
      commit 5df275cd upstream.
      Do the LE conversions before doing the Infiniband-related range checks.
      The incorrect checks are otherwise causing a failure to load any policy
      with an ibendportcon rule on BE systems. This can be reproduced by
      running (on e.g. ppc64):
      cat >my_module.cil <<EOF
      (type test_ibendport_t)
      (roletype object_r test_ibendport_t)
      (ibendportcon mlx4_0 1 (system_u object_r test_ibendport_t ((s0) (s0))))
      semodule -i my_module.cil
      Also, fix loading/storing the 64-bit subnet prefix for OCON_IBPKEY to
      use a correctly aligned buffer.
      Finally, do not use the 'nodebuf' (u32) buffer where 'buf' (__le32)
      should be used instead.
      Tested internally on a ppc64 machine with a RHEL 7 kernel with this
      patch applied.
      Cc: Daniel Jurgens <danielj@mellanox.com>
      Cc: Eli Cohen <eli@mellanox.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: <stable@vger.kernel.org> # 4.13+
      Fixes: a806f7a1 ("selinux: Create policydb version for Infiniband support")
      Signed-off-by: Ondrej Mosnáček's avatarOndrej Mosnacek <omosnace@redhat.com>
      Acked-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Larry Finger's avatar
      b43: Fix error in cordic routine · 047ecbc9
      Larry Finger authored
      commit 8ea3819c upstream.
      The cordic routine for calculating sines and cosines that was added in
      commit 6f98e62a ("b43: update cordic code to match current specs")
      contains an error whereby a quantity declared u32 can in fact go negative.
      This problem was detected by Priit Laes who is switching b43 to use the
      routine in the library functions of the kernel.
      Fixes: 98650454 ("b43: make cordic common (LP-PHY and N-PHY need it)")
      Reported-by: Priit Laes's avatarPriit Laes <plaes@plaes.org>
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Cc: Stable <stable@vger.kernel.org> # 2.6.34
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: Priit Laes's avatarPriit Laes <plaes@plaes.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Andreas Gruenbacher's avatar
      gfs2: Fix loop in gfs2_rbm_find · a62b07e9
      Andreas Gruenbacher authored
      commit 2d29f6b9 upstream.
      Fix the resource group wrap-around logic in gfs2_rbm_find that commit
      e579ed4f broke.  The bug can lead to unnecessary repeated scanning of the
      same bitmaps; there is a risk that future changes will turn this into an
      endless loop.
      Fixes: e579ed4f ("GFS2: Introduce rbm field bii")
      Cc: stable@vger.kernel.org # v3.13+
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Andreas Gruenbacher's avatar
      gfs2: Get rid of potential double-freeing in gfs2_create_inode · dfb1922a
      Andreas Gruenbacher authored
      commit 6ff9b09e upstream.
      In gfs2_create_inode, after setting and releasing the acl / default_acl, the
      acl / default_acl pointers are not set to NULL as they should be.  In that
      state, when the function reaches label fail_free_acls, gfs2_create_inode will
      try to release the same acls again.
      Fix that by setting the pointers to NULL after releasing the acls.  Slightly
      simplify the logic.  Also, posix_acl_release checks for NULL already, so
      there is no need to duplicate those checks here.
      Fixes: e01580bf ("gfs2: use generic posix ACL infrastructure")
      Reported-by: default avatarPan Bian <bianpan2016@163.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org # v4.9+
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      dlm: memory leaks on error path in dlm_user_request() · d6d47998
      Vasily Averin authored
      commit d47b41ac upstream.
      According to comment in dlm_user_request() ua should be freed
      in dlm_free_lkb() after successful attach to lkb.
      However ua is attached to lkb not in set_lock_args() but later,
      inside request_lock().
      Fixes 597d0cae ("[DLM] dlm: user locks")
      Cc: stable@kernel.org # 2.6.19
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: David Teigland's avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      dlm: lost put_lkb on error path in receive_convert() and receive_unlock() · b956f5bf
      Vasily Averin authored
      commit c0174726 upstream.
      Fixes 6d40c4a7 ("dlm: improve error and debug messages")
      Cc: stable@kernel.org # 3.5
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: David Teigland's avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      dlm: possible memory leak on error path in create_lkb() · 1f00b0a6
      Vasily Averin authored
      commit 23851e97 upstream.
      Fixes 3d6aa675 ("dlm: keep lkbs in idr")
      Cc: stable@kernel.org # 3.1
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: David Teigland's avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasily Averin's avatar
      dlm: fixed memory leaks after failed ls_remove_names allocation · 78460f37
      Vasily Averin authored
      commit b982896c upstream.
      If allocation fails on last elements of array need to free already
      allocated elements.
      v2: just move existing out_rsbtbl label to right place
      Fixes 789924ba635f ("dlm: fix race between remove and lookup")
      Cc: stable@kernel.org # 3.6
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: David Teigland's avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jaegeuk Kim's avatar
      dm: do not allow readahead to limit IO size · 0a2fff24
      Jaegeuk Kim authored
      commit c6d6e9b0 upstream.
      Update DM to set the bdi's io_pages.  This fixes reads to be capped at
      the device's max request size (even if user's read IO exceeds the
      established readahead setting).
      Fixes: 9491ae4a ("mm: don't cap request size based on read-ahead setting")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Damien Le Moal's avatar
      block: mq-deadline: Fix write completion handling · d902258a
      Damien Le Moal authored
      commit 7211aef8 upstream.
      For a zoned block device using mq-deadline, if a write request for a
      zone is received while another write was already dispatched for the same
      zone, dd_dispatch_request() will return NULL and the newly inserted
      write request is kept in the scheduler queue waiting for the ongoing
      zone write to complete. With this behavior, when no other request has
      been dispatched, rq_list in blk_mq_sched_dispatch_requests() is empty
      and blk_mq_sched_mark_restart_hctx() not called. This in turn leads to
      __blk_mq_free_request() call of blk_mq_sched_restart() to not run the
      queue when the already dispatched write request completes. The newly
      dispatched request stays stuck in the scheduler queue until eventually
      another request is submitted.
      This problem does not affect SCSI disk as the SCSI stack handles queue
      restart on request completion. However, this problem is can be triggered
      the nullblk driver with zoned mode enabled.
      Fix this by always requesting a queue restart in dd_dispatch_request()
      if no request was dispatched while WRITE requests are queued.
      Fixes: 5700f691 ("mq-deadline: Introduce zone locking support")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@wdc.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Add missing export of blk_mq_sched_restart()
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
    • Ming Lei's avatar
      block: deactivate blk_stat timer in wbt_disable_default() · 7571b18b
      Ming Lei authored
      commit 544fbd16 upstream.
      rwb_enabled() can't be changed when there is any inflight IO.
      wbt_disable_default() may set rwb->wb_normal as zero, however the
      blk_stat timer may still be pending, and the timer function will update
      wrb->wb_normal again.
      This patch introduces blk_stat_deactivate() and applies it in
      wbt_disable_default(), then the following IO hang triggered when running
      parted & switching io scheduler can be fixed:
      [  369.937806] INFO: task parted:3645 blocked for more than 120 seconds.
      [  369.938941]       Not tainted 4.20.0-rc6-00284-g906c801e5248 #498
      [  369.939797] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  369.940768] parted          D    0  3645   3239 0x00000000
      [  369.941500] Call Trace:
      [  369.941874]  ? __schedule+0x6d9/0x74c
      [  369.942392]  ? wbt_done+0x5e/0x5e
      [  369.942864]  ? wbt_cleanup_cb+0x16/0x16
      [  369.943404]  ? wbt_done+0x5e/0x5e
      [  369.943874]  schedule+0x67/0x78
      [  369.944298]  io_schedule+0x12/0x33
      [  369.944771]  rq_qos_wait+0xb5/0x119
      [  369.945193]  ? karma_partition+0x1c2/0x1c2
      [  369.945691]  ? wbt_cleanup_cb+0x16/0x16
      [  369.946151]  wbt_wait+0x85/0xb6
      [  369.946540]  __rq_qos_throttle+0x23/0x2f
      [  369.947014]  blk_mq_make_request+0xe6/0x40a
      [  369.947518]  generic_make_request+0x192/0x2fe
      [  369.948042]  ? submit_bio+0x103/0x11f
      [  369.948486]  ? __radix_tree_lookup+0x35/0xb5
      [  369.949011]  submit_bio+0x103/0x11f
      [  369.949436]  ? blkg_lookup_slowpath+0x25/0x44
      [  369.949962]  submit_bio_wait+0x53/0x7f
      [  369.950469]  blkdev_issue_flush+0x8a/0xae
      [  369.951032]  blkdev_fsync+0x2f/0x3a
      [  369.951502]  do_fsync+0x2e/0x47
      [  369.951887]  __x64_sys_fsync+0x10/0x13
      [  369.952374]  do_syscall_64+0x89/0x149
      [  369.952819]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  369.953492] RIP: 0033:0x7f95a1e729d4
      [  369.953996] Code: Bad RIP value.
      [  369.954456] RSP: 002b:00007ffdb570dd48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
      [  369.955506] RAX: ffffffffffffffda RBX: 000055c2139c6be0 RCX: 00007f95a1e729d4
      [  369.956389] RDX: 0000000000000001 RSI: 0000000000001261 RDI: 0000000000000004
      [  369.957325] RBP: 0000000000000002 R08: 0000000000000000 R09: 000055c2139c6ce0
      [  369.958199] R10: 0000000000000000 R11: 0000000000000246 R12: 000055c2139c0380
      [  369.959143] R13: 0000000000000004 R14: 0000000000000100 R15: 0000000000000008
      Cc: stable@vger.kernel.org
      Cc: Paolo Valente <paolo.valente@linaro.org>
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Matthew Wilcox's avatar
      Fix failure path in alloc_pid() · db4570bb
      Matthew Wilcox authored
      commit 1a80dade upstream.
      The failure path removes the allocated PIDs from the wrong namespace.
      This could lead to us inadvertently reusing PIDs in the leaf namespace
      and leaking PIDs in parent namespaces.
      Fixes: 95846ecf ("pid: replace pid bitmap implementation with IDR API")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatthew Wilcox <willy@infradead.org>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Rafael J. Wysocki's avatar
      driver core: Add missing dev->bus->need_parent_lock checks · 1fdd2859
      Rafael J. Wysocki authored
      commit e121a833 upstream.
      __device_release_driver() has to check dev->bus->need_parent_lock
      before dropping the parent lock and acquiring it again as it may
      attempt to drop a lock that hasn't been acquired or lock a device
      that shouldn't be locked and create a lock imbalance.
      Fixes: 8c97a46a (driver core: hold dev's parent lock when needed)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dennis Krein's avatar
      srcu: Lock srcu_data structure in srcu_gp_start() · a38adf5a
      Dennis Krein authored
      commit eb4c2382 upstream.
      The srcu_gp_start() function is called with the srcu_struct structure's
      ->lock held, but not with the srcu_data structure's ->lock.  This is
      problematic because this function accesses and updates the srcu_data
      structure's ->srcu_cblist, which is protected by that lock.  Failing to
      hold this lock can result in corruption of the SRCU callback lists,
      which in turn can result in arbitrarily bad results.
      This commit therefore makes srcu_gp_start() acquire the srcu_data
      structure's ->lock across the calls to rcu_segcblist_advance() and
      rcu_segcblist_accelerate(), thus preventing this corruption.
      Reported-by: default avatarBart Van Assche <bvanassche@acm.org>
      Reported-by: default avatarChristoph Hellwig <hch@infradead.org>
      Reported-by: default avatarSebastian Kuzminsky <seb.kuzminsky@gmail.com>
      Signed-off-by: default avatarDennis Krein <Dennis.Krein@netapp.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.ibm.com>
      Tested-by: default avatarDennis Krein <Dennis.Krein@netapp.com>
      Cc: <stable@vger.kernel.org> # 4.16.x
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Takashi Iwai's avatar
      ALSA: usb-audio: Always check descriptor sizes in parser code · 9dfe7ee5
      Takashi Iwai authored
      commit 3e96d728 upstream.
      There are a few places where we access the data without checking the
      actual object size from the USB audio descriptor.  This may result in
      OOB access, as recently reported.
      This patch addresses these missing checks.  Most of added codes are
      simple bLength checks in the caller side.  For the input and output
      terminal parsers, we put the length check in the parser functions.
      For the input terminal, a new argument is added to distinguish between
      UAC1 and the rest, as they treat different objects.
      Reported-by: Mathias Payer's avatarMathias Payer <mathias.payer@nebelwelt.net>
      Reported-by: default avatarHui Peng <benquike@163.com>
      Tested-by: default avatarHui Peng <benquike@163.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hui Peng's avatar
      ALSA: usb-audio: Fix an out-of-bound read in create_composite_quirks · 0005a468
      Hui Peng authored
      commit cbb2ebf7 upstream.
      In `create_composite_quirk`, the terminating condition of for loops is
      `quirk->ifnum < 0`. So any composite quirks should end with `struct
      snd_usb_audio_quirk` object with ifnum < 0.
          for (quirk = quirk_comp->data; quirk->ifnum >= 0; ++quirk) {
      the data field of Bower's & Wilkins PX headphones usb device device quirks
      do not end with {.ifnum = -1}, wihch may result in out-of-bound read.
      This Patch fix the bug by adding an ending quirk object.
      Fixes: 240a8af9 ("ALSA: usb-audio: Add a quirck for B&W PX headphones")
      Signed-off-by: default avatarHui Peng <benquike@163.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Takashi Iwai's avatar
      ALSA: usb-audio: Check mixer unit descriptors more strictly · cd5564f4
      Takashi Iwai authored
      commit 0bfe5e43 upstream.
      We've had some sanity checks of the mixer unit descriptors but they
      are too loose and some corner cases are overlooked.  Add more strict
      checks in uac_mixer_unit_get_channels() for avoiding possible OOB
      accesses by malformed descriptors.
      This also changes the semantics of uac_mixer_unit_get_channels()
      slightly.  Now it returns zero for the cases where the descriptor
      lacks of bmControls instead of -EINVAL.  Then the caller side skips
      the mixer creation for such unit while it keeps parsing it.
      This corresponds to the case like Maya44.
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Takashi Iwai's avatar
      ALSA: usb-audio: Avoid access before bLength check in build_audio_procunit() · 3d2a19f8
      Takashi Iwai authored
      commit f4351a19 upstream.
      The parser for the processing unit reads bNrInPins field before the
      bLength sanity check, which may lead to an out-of-bound access when a
      malformed descriptor is given.  Fix it by assignment after the bLength
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dan Carpenter's avatar
      ALSA: cs46xx: Potential NULL dereference in probe · e189fc04
      Dan Carpenter authored
      commit 1524f4e4 upstream.
      The "chip->dsp_spos_instance" can be NULL on some of the ealier error
      paths in snd_cs46xx_create().
      Reported-by: default avatar"Yavuz, Tuba" <tuba@ece.ufl.edu>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Brad Love's avatar
      media: cx23885: only reset DMA on problematic CPUs · 0fde9064
      Brad Love authored
      commit 4bd46aa0 upstream.
      It is reported that commit 95f408bb ("media: cx23885: Ryzen DMA
      related RiSC engine stall fixes") caused regresssions with other CPUs.
      Ensure that the quirk will be applied only for the CPUs that
      are known to cause problems.
      A module option is added for explicit control of the behaviour.
      Fixes: 95f408bb ("media: cx23885: Ryzen DMA related RiSC engine stall fixes")
      Signed-off-by: default avatarBrad Love <brad@nextdimension.cc>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>