1. 06 Mar, 2017 40 commits
    • Kinglong Mee's avatar
      SUNRPC: cleanup ida information when removing sunrpc module · eee6e0db
      Kinglong Mee authored
      [ Upstream commit c929ea0b ]
      
      After removing sunrpc module, I get many kmemleak information as,
      unreferenced object 0xffff88003316b1e0 (size 544):
        comm "gssproxy", pid 2148, jiffies 4294794465 (age 4200.081s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffffb0cfb58a>] kmemleak_alloc+0x4a/0xa0
          [<ffffffffb03507fe>] kmem_cache_alloc+0x15e/0x1f0
          [<ffffffffb0639baa>] ida_pre_get+0xaa/0x150
          [<ffffffffb0639cfd>] ida_simple_get+0xad/0x180
          [<ffffffffc06054fb>] nlmsvc_lookup_host+0x4ab/0x7f0 [lockd]
          [<ffffffffc0605e1d>] lockd+0x4d/0x270 [lockd]
          [<ffffffffc06061e5>] param_set_timeout+0x55/0x100 [lockd]
          [<ffffffffc06cba24>] svc_defer+0x114/0x3f0 [sunrpc]
          [<ffffffffc06cbbe7>] svc_defer+0x2d7/0x3f0 [sunrpc]
          [<ffffffffc06c71da>] rpc_show_info+0x8a/0x110 [sunrpc]
          [<ffffffffb044a33f>] proc_reg_write+0x7f/0xc0
          [<ffffffffb038e41f>] __vfs_write+0xdf/0x3c0
          [<ffffffffb0390f1f>] vfs_write+0xef/0x240
          [<ffffffffb0392fbd>] SyS_write+0xad/0x130
          [<ffffffffb0d06c37>] entry_SYSCALL_64_fastpath+0x1a/0xa9
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      I found, the ida information (dynamic memory) isn't cleanup.
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Fixes: 2f048db4 ("SUNRPC: Add an identifier for struct rpc_clnt")
      Cc: stable@vger.kernel.org # v3.12+
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      eee6e0db
    • Chuck Lever's avatar
      nfs: Don't increment lock sequence ID after NFS4ERR_MOVED · 07fc9a9e
      Chuck Lever authored
      [ Upstream commit 059aa734 ]
      
      Xuan Qi reports that the Linux NFSv4 client failed to lock a file
      that was migrated. The steps he observed on the wire:
      
      1. The client sent a LOCK request to the source server
      2. The source server replied NFS4ERR_MOVED
      3. The client switched to the destination server
      4. The client sent the same LOCK request to the destination
         server with a bumped lock sequence ID
      5. The destination server rejected the LOCK request with
         NFS4ERR_BAD_SEQID
      
      RFC 3530 section 8.1.5 provides a list of NFS errors which do not
      bump a lock sequence ID.
      
      However, RFC 3530 is now obsoleted by RFC 7530. In RFC 7530 section
      9.1.7, this list has been updated by the addition of NFS4ERR_MOVED.
      Reported-by: default avatarXuan Qi <xuan.qi@oracle.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: stable@vger.kernel.org # v3.7+
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      07fc9a9e
    • Bjørn Mork's avatar
      USB: serial: option: add device ID for HP lt2523 (Novatel E371) · 7b745775
      Bjørn Mork authored
      [ Upstream commit 5d03a2fd ]
      
      Yet another laptop vendor rebranded Novatel E371.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7b745775
    • Gavin Shan's avatar
      powerpc/eeh: Fix wrong flag passed to eeh_unfreeze_pe() · bbc56ad0
      Gavin Shan authored
      [ Upstream commit f05fea5b ]
      
      In __eeh_clear_pe_frozen_state(), we should pass the flag's value
      instead of its address to eeh_unfreeze_pe(). The isolated flag is
      cleared if no error returned from __eeh_clear_pe_frozen_state(). We
      never observed the error from the function. So the isolated flag should
      have been always cleared, no real issue is caused because of the misused
      @flag.
      
      This fixes the code by passing the value of @flag to eeh_unfreeze_pe().
      
      Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
      Cc: stable@vger.kernel.org # v3.18+
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      bbc56ad0
    • Darren Stevens's avatar
      powerpc: Add missing error check to prom_find_boot_cpu() · 078d15b1
      Darren Stevens authored
      [ Upstream commit af2b7fa1 ]
      
      prom_init.c calls 'instance-to-package' twice, but the return
      is not checked during prom_find_boot_cpu(). The result is then
      passed to prom_getprop(), which could be PROM_ERROR. Add a return check
      to prevent this.
      
      This was found on a pasemi system, where CFE doesn't have a working
      'instance-to package' prom call.
      
      Before Commit 5c0484e2 ('powerpc: Endian safe trampoline') the area
      around addr 0 was mostly 0's and this doesn't cause a problem. Once the
      macro 'FIXUP_ENDIAN' has been added to head_64.S, the low memory area
      now has non-zero values, which cause the prom_getprop() call
      to hang.
      
      mpe: Also confirmed that under SLOF if 'instance-to-package' did fail
      with PROM_ERROR we would crash in SLOF. So the bug is not specific to
      CFE, it's just that other open firmwares don't trigger it because they
      have a working 'instance-to-package'.
      
      Fixes: 5c0484e2 ("powerpc: Endian safe trampoline")
      Cc: stable@vger.kernel.org # v3.13+
      Signed-off-by: default avatarDarren Stevens <darren@stevens-zone.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      078d15b1
    • Ard Biesheuvel's avatar
      crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes · 574c2c0b
      Ard Biesheuvel authored
      [ Upstream commit 11e3b725 ]
      
      Update the ARMv8 Crypto Extensions and the plain NEON AES implementations
      in CBC and CTR modes to return the next IV back to the skcipher API client.
      This is necessary for chaining to work correctly.
      
      Note that for CTR, this is only done if the request is a round multiple of
      the block size, since otherwise, chaining is impossible anyway.
      
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      574c2c0b
    • Salvatore Benedetto's avatar
      crypto: api - Clear CRYPTO_ALG_DEAD bit before registering an alg · ec956aab
      Salvatore Benedetto authored
      [ Upstream commit d6040764 ]
      
      Make sure CRYPTO_ALG_DEAD bit is cleared before proceeding with
      the algorithm registration. This fixes qat-dh registration when
      driver is restarted
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSalvatore Benedetto <salvatore.benedetto@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ec956aab
    • Fabien Parent's avatar
      ARM: dts: da850-evm: fix read access to SPI flash · 3e9067b2
      Fabien Parent authored
      [ Upstream commit 43849785 ]
      
      Read access to the SPI flash are broken on da850-evm, i.e. the data
      read is not what is actually programmed on the flash.
      According to the datasheet for the M25P64 part present on the da850-evm,
      if the SPI frequency is higher than 20MHz then the READ command is not
      usable anymore and only the FAST_READ command can be used to read data.
      
      This commit specifies in the DTS that we should use FAST_READ command
      instead of the READ command.
      
      Cc: stable@vger.kernel.org
      Tested-by: default avatarKevin Hilman <khilman@baylibre.com>
      Signed-off-by: default avatarFabien Parent <fparent@baylibre.com>
      [nsekhar@ti.com: subject line adjustment]
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3e9067b2
    • Aleksander Morgado's avatar
      USB: serial: qcserial: add Dell DW5570 QDL · 4730dec8
      Aleksander Morgado authored
      [ Upstream commit 24d615a6 ]
      
      The Dell DW5570 is a re-branded Sierra Wireless MC8805 which will by
      default boot with vid 0x413c and pid 0x81a3. When triggered QDL download
      mode, the device switches to pid 0x81a6 and provides the standard TTY
      used for firmware upgrade.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAleksander Morgado <aleksander@aleksander.es>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      4730dec8
    • Dave Martin's avatar
      arm64/ptrace: Reject attempts to set incomplete hardware breakpoint fields · 6b6b456e
      Dave Martin authored
      [ Upstream commit ad9e202a ]
      
      We cannot preserve partial fields for hardware breakpoints, because
      the values written by userspace to the hardware breakpoint
      registers can't subsequently be recovered intact from the hardware.
      
      So, just reject attempts to write incomplete fields with -EINVAL.
      
      Cc: <stable@vger.kernel.org> # 3.7.x-
      Fixes: 478fcb2c ("arm64: Debugging support")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarWill Deacon <Will.Deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6b6b456e
    • Dave Martin's avatar
      arm64/ptrace: Avoid uninitialised struct padding in fpr_set() · 113634c0
      Dave Martin authored
      [ Upstream commit aeb1f39d ]
      
      This patch adds an explicit __reserved[] field to user_fpsimd_state
      to replace what was previously unnamed padding.
      
      This ensures that data in this region are propagated across
      assignment rather than being left possibly uninitialised at the
      destination.
      
      Cc: <stable@vger.kernel.org> # 3.7.x-
      Fixes: 60ffc30d ("arm64: Exception handling")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarWill Deacon <Will.Deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      113634c0
    • Dave Martin's avatar
      arm64/ptrace: Preserve previous registers for short regset write · 521aff7c
      Dave Martin authored
      [ Upstream commit 9a17b876 ]
      
      Ensure that if userspace supplies insufficient data to
      PTRACE_SETREGSET to fill all the registers, the thread's old
      registers are preserved.
      
      Cc: <stable@vger.kernel.org> # 3.7.x-
      Fixes: 478fcb2c ("arm64: Debugging support")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarWill Deacon <Will.Deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      521aff7c
    • Jeff Layton's avatar
      ceph: fix bad endianness handling in parse_reply_info_extra · af9c6633
      Jeff Layton authored
      [ Upstream commit 6df8c9d8 ]
      
      sparse says:
      
          fs/ceph/mds_client.c:291:23: warning: restricted __le32 degrades to integer
          fs/ceph/mds_client.c:293:28: warning: restricted __le32 degrades to integer
          fs/ceph/mds_client.c:294:28: warning: restricted __le32 degrades to integer
          fs/ceph/mds_client.c:296:28: warning: restricted __le32 degrades to integer
      
      The op value is __le32, so we need to convert it before comparing it.
      
      Cc: stable@vger.kernel.org # needs backporting for < 3.14
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      af9c6633
    • Yegor Yefremov's avatar
      can: ti_hecc: add missing prepare and unprepare of the clock · 23fdc77d
      Yegor Yefremov authored
      [ Upstream commit befa6011 ]
      
      In order to make the driver work with the common clock framework, this
      patch converts the clk_enable()/clk_disable() to
      clk_prepare_enable()/clk_disable_unprepare().
      
      Also add error checking for clk_prepare_enable().
      Signed-off-by: default avatarYegor Yefremov <yegorslists@googlemail.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      23fdc77d
    • Einar Jón's avatar
      can: c_can_pci: fix null-pointer-deref in c_can_start() - set device pointer · 656e7d39
      Einar Jón authored
      [ Upstream commit c97c52be ]
      
      The priv->device pointer for c_can_pci is never set, but it is used
      without a NULL check in c_can_start(). Setting it in c_can_pci_probe()
      like c_can_plat_probe() prevents c_can_pci.ko from crashing, with and
      without CONFIG_PM.
      
      This might also cause the pm_runtime_*() functions in c_can.c to
      actually be executed for c_can_pci devices - they are the only other
      place where priv->device is used, but they all contain a null check.
      Signed-off-by: default avatarEinar Jón <tolvupostur@gmail.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      656e7d39
    • Quinn Tran's avatar
      qla2xxx: Fix crash due to null pointer access · de99814c
      Quinn Tran authored
      [ Upstream commit fc1ffd6c ]
      
      During code inspection, while investigating following stack trace
      seen on one of the test setup, we found out there was possibility
      of memory leak becuase driver was not unwinding the stack properly.
      
      This issue has not been reproduced in a test environment or on a
      customer setup.
      
      Here's stack trace that was seen.
      
      [1469877.797315] Call Trace:
      [1469877.799940]  [<ffffffffa03ab6e9>] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx]
      [1469877.806980]  [<ffffffffa03ac50a>] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx]
      [1469877.814013]  [<ffffffff813b6d01>] ? __pm_runtime_resume+0x51/0xa0
      [1469877.820265]  [<ffffffff8157c1f5>] ? _raw_spin_lock_irqsave+0x25/0x90
      [1469877.826776]  [<ffffffff8157cd2d>] ? _raw_spin_unlock_irqrestore+0x6d/0x80
      [1469877.833720]  [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100
      [1469877.839885]  [<ffffffff8157cd0c>] ? _raw_spin_unlock_irqrestore+0x4c/0x80
      [1469877.846830]  [<ffffffff81319b9c>] local_pci_probe+0x4c/0xb0
      [1469877.852562]  [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100
      [1469877.858727]  [<ffffffff81319c89>] pci_call_probe+0x89/0xb0
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarQuinn Tran <quinn.tran@cavium.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      [ bvanassche: Fixed spelling in patch description ]
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      de99814c
    • Richard Weinberger's avatar
      ubifs: Fix journal replay wrt. xattr nodes · a01621bb
      Richard Weinberger authored
      [ Upstream commit 1cb51a15 ]
      
      When replaying the journal it can happen that a journal entry points to
      a garbage collected node.
      This is the case when a power-cut occurred between a garbage collect run
      and a commit. In such a case nodes have to be read using the failable
      read functions to detect whether the found node matches what we expect.
      
      One corner case was forgotten, when the journal contains an entry to
      remove an inode all xattrs have to be removed too. UBIFS models xattr
      like directory entries, so the TNC code iterates over
      all xattrs of the inode and removes them too. This code re-uses the
      functions for walking directories and calls ubifs_tnc_next_ent().
      ubifs_tnc_next_ent() expects to be used only after the journal and
      aborts when a node does not match the expected result. This behavior can
      render an UBIFS volume unmountable after a power-cut when xattrs are
      used.
      
      Fix this issue by using failable read functions in ubifs_tnc_next_ent()
      too when replaying the journal.
      Cc: stable@vger.kernel.org
      Fixes: 1e51764a ("UBIFS: add new flash file system")
      Reported-by: default avatarRock Lee <rockdotlee@gmail.com>
      Reviewed-by: default avatarDavid Gstir <david@sigma-star.at>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a01621bb
    • J. Bruce Fields's avatar
      svcrpc: don't leak contexts on PROC_DESTROY · f24447e6
      J. Bruce Fields authored
      [ Upstream commit 78794d18 ]
      
      Context expiry times are in units of seconds since boot, not unix time.
      
      The use of get_seconds() here therefore sets the expiry time decades in
      the future.  This prevents timely freeing of contexts destroyed by
      client RPC_GSS_PROC_DESTROY requests.  We'd still free them eventually
      (when the module is unloaded or the container shut down), but a lot of
      contexts could pile up before then.
      
      Cc: stable@vger.kernel.org
      Fixes: c5b29f88 "sunrpc: use seconds since boot in expiry cache"
      Reported-by: default avatarAndy Adamson <andros@netapp.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f24447e6
    • David Matlack's avatar
      KVM: x86: flush pending lapic jump label updates on module unload · 73dc8655
      David Matlack authored
      [ Upstream commit cef84c30 ]
      
      KVM's lapic emulation uses static_key_deferred (apic_{hw,sw}_disabled).
      These are implemented with delayed_work structs which can still be
      pending when the KVM module is unloaded. We've seen this cause kernel
      panics when the kvm_intel module is quickly reloaded.
      
      Use the new static_key_deferred_flush() API to flush pending updates on
      module unload.
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      73dc8655
    • David Matlack's avatar
      jump_labels: API for flushing deferred jump label updates · 577c9c60
      David Matlack authored
      [ Upstream commit b6416e61 ]
      
      Modules that use static_key_deferred need a way to synchronize with
      any delayed work that is still pending when the module is unloaded.
      Introduce static_key_deferred_flush() which flushes any pending
      jump label updates.
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      577c9c60
    • Stefan Wahren's avatar
      mmc: mxs-mmc: Fix additional cycles after transmission stop · d51217ab
      Stefan Wahren authored
      [ Upstream commit 01167c7b ]
      
      According to the code the intention is to append 8 SCK cycles
      instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this
      will never happened because it's an AC command not an ADTC command.
      So fix this by moving the statement into the right function.
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Fixes: e4243f13 (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d51217ab
    • Takashi Iwai's avatar
      drm: Fix broken VT switch with video=1366x768 option · d4fa088d
      Takashi Iwai authored
      [ Upstream commit fdf35a6b ]
      
      I noticed that the VT switch doesn't work any longer with a Dell
      laptop with 1366x768 eDP when the machine is connected with a DP
      monitor.  It behaves as if VT were switched, but the graphics remain
      frozen.  Actually the keyboard works, so I could switch back to VT7
      again.
      
      I tried to track down the problem, and encountered a long story until
      we reach to this error:
      
      - The machine is booted with video=1366x768 option (the distro
        installer seems to add it as default).
      - Recently, drm_helper_probe_single_connector_modes() deals with
        cmdline modes, and it tries to create a new mode when no
        matching mode is found.
      - The drm_mode_create_from_cmdline_mode() creates a mode based on
        either CVT of GFT according to the given cmdline mode; in our case,
        it's 1366x768.
      - Since both CVT and GFT can't express the width 1366 due to
        alignment, the resultant mode becomes 1368x768, slightly larger than
        the given size.
      - Later on, the atomic commit is performed, and in
        drm_atomic_check_only(), the size of each plane is checked.
      - The size check of 1366x768 fails due to the above, and eventually
        the whole VT switch fails.
      
      Back in the history, we've had a manual fix-up of 1368x768 in various
      places via c09dedb7 ("drm/edid: Add a workaround for 1366x768 HD
      panel"), but they have been all in drm_edid.c at probing the modes
      from EDID.  For addressing the problem above, we need a similar hack
      to the mode newly created from cmdline, manually adjusting the width
      when the expected size is 1366 while we get 1368 instead.
      
      Fixes: eaf99c74 ("drm: Perform cmdline mode parsing during...")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170109145614.29454-1-tiwai@suse.deReviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d4fa088d
    • Mathias Nyman's avatar
      xhci: fix deadlock at host remove by running watchdog correctly · c068da47
      Mathias Nyman authored
      [ Upstream commit d6169d04 ]
      
      If a URB is killed while the host is removed we can end up in a situation
      where the hub thread takes the roothub device lock, and waits for
      the URB to be given back by xhci-hcd, blocking the host remove code.
      
      xhci-hcd tries to stop the endpoint and give back the urb, but can't
      as the host is removed from PCI bus at the same time, preventing the normal
      way of giving back urb.
      
      Instead we need to rely on the stop command timeout function to give back
      the urb. This xhci_stop_endpoint_command_watchdog() timeout function
      used a XHCI_STATE_DYING flag to indicate if the timeout function is already
      running, but later this flag has been taking into use in other places to
      mark that xhci is dying.
      
      Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still
      checking that reading from pci state does not return 0xffffffff or that
      host is not halted before trying to stop the endpoint.
      
      This whole area of stopping endpoints, giving back URBs, and the wathdog
      timeout need rework, this fix focuses on solving a specific deadlock
      issue that we can then send to stable before any major rework.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c068da47
    • Bjorn Helgaas's avatar
      PCI: Enumerate switches below PCI-to-PCIe bridges · ee21da30
      Bjorn Helgaas authored
      [ Upstream commit 51ebfc92 ]
      
      A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary
      interface and a PCI Express secondary interface.  The PCIe interface is a
      Downstream Port that originates a Link.  See the "PCI Express to PCI/PCI-X
      Bridge Specification", rev 1.0, sections 1.2 and A.6.
      
      The bug report below involves a PCI-to-PCIe bridge and a PCIe switch below
      the bridge:
      
        00:1e.0 Intel 82801 PCI Bridge to [bus 01-0a]
        01:00.0 Pericom PI7C9X111SL PCIe-to-PCI Reversible Bridge to [bus 02-0a]
        02:00.0 Pericom Device 8608 [PCIe Upstream Port] to [bus 03-0a]
        03:01.0 Pericom Device 8608 [PCIe Downstream Port] to [bus 0a]
      
      01:00.0 is configured as a PCI-to-PCIe bridge (despite the name printed by
      lspci).  As we traverse a PCIe hierarchy, device connections alternate
      between PCIe Links and internal Switch logic.  Previously we did not
      recognize that 01:00.0 had a secondary link, so we thought the 02:00.0
      Upstream Port *did* have a secondary link.  In fact, it's the other way
      around: 01:00.0 has a secondary link, and 02:00.0 has internal Switch logic
      on its secondary side.
      
      When we thought 02:00.0 had a secondary link, the pci_scan_slot() ->
      only_one_child() path assumed 02:00.0 could have only one child, so 03:00.0
      was the only possible downstream device.  But 03:00.0 doesn't exist, so we
      didn't look for any other devices on bus 03.
      
      Booting with "pci=pcie_scan_all" is a workaround, but we don't want users
      to have to do that.
      
      Recognize that PCI-to-PCIe bridges originate links on their secondary
      interfaces.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=189361
      Fixes: d0751b98 ("PCI: Add dev->has_secondary_link to track downstream PCIe links")
      Tested-by: default avatarBlake Moore <blake.moore@men.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v4.2+
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ee21da30
    • Bjorn Helgaas's avatar
      x86/PCI: Ignore _CRS on Supermicro X8DTH-i/6/iF/6F · 61a16adb
      Bjorn Helgaas authored
      [ Upstream commit 89e9f7bc ]
      
      Martin reported that the Supermicro X8DTH-i/6/iF/6F advertises incorrect
      host bridge windows via _CRS:
      
        pci_root PNP0A08:00: host bridge window [io  0xf000-0xffff]
        pci_root PNP0A08:01: host bridge window [io  0xf000-0xffff]
      
      Both bridges advertise the 0xf000-0xffff window, which cannot be correct.
      
      Work around this by ignoring _CRS on this system.  The downside is that we
      may not assign resources correctly to hot-added PCI devices (if they are
      possible on this system).
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=42606Reported-by: default avatarMartin Burnicki <martin.burnicki@meinberg.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      61a16adb
    • Johan Hovold's avatar
      USB: serial: ch341: fix control-message error handling · a457dcb7
      Johan Hovold authored
      [ Upstream commit 2d5a9c72 ]
      
      A short control transfer would currently fail to be detected, something
      which could lead to stale buffer data being used as valid input.
      
      Check for short transfers, and make sure to log any transfer errors.
      
      Note that this also avoids leaking heap data to user space (TIOCMGET)
      and the remote device (break control).
      
      Fixes: 6ce76104 ("USB: Driver for CH341 USB-serial adaptor")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a457dcb7
    • Augusto Mecking Caringi's avatar
      vme: Fix wrong pointer utilization in ca91cx42_slave_get · 1fe63899
      Augusto Mecking Caringi authored
      [ Upstream commit c8a6a09c ]
      
      In ca91cx42_slave_get function, the value pointed by vme_base pointer is
      set through:
      
      *vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]);
      
      So it must be dereferenced to be used in calculation of pci_base:
      
      *pci_base = (dma_addr_t)*vme_base + pci_offset;
      
      This bug was caught thanks to the following gcc warning:
      
      drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’:
      drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
      *pci_base = (dma_addr_t)vme_base + pci_offset;
      Signed-off-by: default avatarAugusto Mecking Caringi <augustocaringi@gmail.com>
      Acked-By: default avatarMartyn Welch <martyn@welchs.me.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1fe63899
    • Akinobu Mita's avatar
      sysrq: attach sysrq handler correctly for 32-bit kernel · dad7228d
      Akinobu Mita authored
      [ Upstream commit 802c0388 ]
      
      The sysrq input handler should be attached to the input device which has
      a left alt key.
      
      On 32-bit kernels, some input devices which has a left alt key cannot
      attach sysrq handler.  Because the keybit bitmap in struct input_device_id
      for sysrq is not correctly initialized.  KEY_LEFTALT is 56 which is
      greater than BITS_PER_LONG on 32-bit kernels.
      
      I found this problem when using a matrix keypad device which defines
      a KEY_LEFTALT (56) but doesn't have a KEY_O (24 == 56%32).
      
      Cc: Jiri Slaby <jslaby@suse.com>
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      dad7228d
    • Mike Kravetz's avatar
      mm/hugetlb.c: fix reservation race when freeing surplus pages · 31126310
      Mike Kravetz authored
      [ Upstream commit e5bbc8a6 ]
      
      return_unused_surplus_pages() decrements the global reservation count,
      and frees any unused surplus pages that were backing the reservation.
      
      Commit 7848a4bf ("mm/hugetlb.c: add cond_resched_lock() in
      return_unused_surplus_pages()") added a call to cond_resched_lock in the
      loop freeing the pages.
      
      As a result, the hugetlb_lock could be dropped, and someone else could
      use the pages that will be freed in subsequent iterations of the loop.
      This could result in inconsistent global hugetlb page state, application
      api failures (such as mmap) failures or application crashes.
      
      When dropping the lock in return_unused_surplus_pages, make sure that
      the global reservation count (resv_huge_pages) remains sufficiently
      large to prevent someone else from claiming pages about to be freed.
      
      Analyzed by Paul Cassella.
      
      Fixes: 7848a4bf ("mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()")
      Link: http://lkml.kernel.org/r/1483991767-6879-1-git-send-email-mike.kravetz@oracle.comSigned-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reported-by: default avatarPaul Cassella <cassella@cray.com>
      Suggested-by: default avatarMichal Hocko <mhocko@kernel.org>
      Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
      Cc: <stable@vger.kernel.org>	[3.15+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      31126310
    • Eric Ren's avatar
      ocfs2: fix crash caused by stale lvb with fsdlm plugin · 257e62ac
      Eric Ren authored
      [ Upstream commit e7ee2c08 ]
      
      The crash happens rather often when we reset some cluster nodes while
      nodes contend fiercely to do truncate and append.
      
      The crash backtrace is below:
      
         dlm: C21CBDA5E0774F4BA5A9D4F317717495: dlm_recover_grant 1 locks on 971 resources
         dlm: C21CBDA5E0774F4BA5A9D4F317717495: dlm_recover 9 generation 5 done: 4 ms
         ocfs2: Begin replay journal (node 318952601, slot 2) on device (253,18)
         ocfs2: End replay journal (node 318952601, slot 2) on device (253,18)
         ocfs2: Beginning quota recovery on device (253,18) for slot 2
         ocfs2: Finishing quota recovery on device (253,18) for slot 2
         (truncate,30154,1):ocfs2_truncate_file:470 ERROR: bug expression: le64_to_cpu(fe->i_size) != i_size_read(inode)
         (truncate,30154,1):ocfs2_truncate_file:470 ERROR: Inode 290321, inode i_size = 732 != di i_size = 937, i_flags = 0x1
         ------------[ cut here ]------------
         kernel BUG at /usr/src/linux/fs/ocfs2/file.c:470!
         invalid opcode: 0000 [#1] SMP
         Modules linked in: ocfs2_stack_user(OEN) ocfs2(OEN) ocfs2_nodemanager ocfs2_stackglue(OEN) quota_tree dlm(OEN) configfs fuse sd_mod    iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi af_packet iscsi_ibft iscsi_boot_sysfs softdog xfs libcrc32c ppdev parport_pc pcspkr parport      joydev virtio_balloon virtio_net i2c_piix4 acpi_cpufreq button processor ext4 crc16 jbd2 mbcache ata_generic cirrus virtio_blk ata_piix               drm_kms_helper ahci syscopyarea libahci sysfillrect sysimgblt fb_sys_fops ttm floppy libata drm virtio_pci virtio_ring uhci_hcd virtio ehci_hcd       usbcore serio_raw usb_common sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4
         Supported: No, Unsupported modules are loaded
         CPU: 1 PID: 30154 Comm: truncate Tainted: G           OE   N  4.4.21-69-default #1
         Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
         task: ffff88004ff6d240 ti: ffff880074e68000 task.ti: ffff880074e68000
         RIP: 0010:[<ffffffffa05c8c30>]  [<ffffffffa05c8c30>] ocfs2_truncate_file+0x640/0x6c0 [ocfs2]
         RSP: 0018:ffff880074e6bd50  EFLAGS: 00010282
         RAX: 0000000000000074 RBX: 000000000000029e RCX: 0000000000000000
         RDX: 0000000000000001 RSI: 0000000000000246 RDI: 0000000000000246
         RBP: ffff880074e6bda8 R08: 000000003675dc7a R09: ffffffff82013414
         R10: 0000000000034c50 R11: 0000000000000000 R12: ffff88003aab3448
         R13: 00000000000002dc R14: 0000000000046e11 R15: 0000000000000020
         FS:  00007f839f965700(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
         CR2: 00007f839f97e000 CR3: 0000000036723000 CR4: 00000000000006e0
         Call Trace:
           ocfs2_setattr+0x698/0xa90 [ocfs2]
           notify_change+0x1ae/0x380
           do_truncate+0x5e/0x90
           do_sys_ftruncate.constprop.11+0x108/0x160
           entry_SYSCALL_64_fastpath+0x12/0x6d
         Code: 24 28 ba d6 01 00 00 48 c7 c6 30 43 62 a0 8b 41 2c 89 44 24 08 48 8b 41 20 48 c7 c1 78 a3 62 a0 48 89 04 24 31 c0 e8 a0 97 f9 ff <0f> 0b 3d 00 fe ff ff 0f 84 ab fd ff ff 83 f8 fc 0f 84 a2 fd ff
         RIP  [<ffffffffa05c8c30>] ocfs2_truncate_file+0x640/0x6c0 [ocfs2]
      
      It's because ocfs2_inode_lock() get us stale LVB in which the i_size is
      not equal to the disk i_size.  We mistakenly trust the LVB because the
      underlaying fsdlm dlm_lock() doesn't set lkb_sbflags with
      DLM_SBF_VALNOTVALID properly for us.  But, why?
      
      The current code tries to downconvert lock without DLM_LKF_VALBLK flag
      to tell o2cb don't update RSB's LVB if it's a PR->NULL conversion, even
      if the lock resource type needs LVB.  This is not the right way for
      fsdlm.
      
      The fsdlm plugin behaves different on DLM_LKF_VALBLK, it depends on
      DLM_LKF_VALBLK to decide if we care about the LVB in the LKB.  If
      DLM_LKF_VALBLK is not set, fsdlm will skip recovering RSB's LVB from
      this lkb and set the right DLM_SBF_VALNOTVALID appropriately when node
      failure happens.
      
      The following diagram briefly illustrates how this crash happens:
      
      RSB1 is inode metadata lock resource with LOCK_TYPE_USES_LVB;
      
      The 1st round:
      
                   Node1                                    Node2
      RSB1: PR
                                                        RSB1(master): NULL->EX
      ocfs2_downconvert_lock(PR->NULL, set_lvb==0)
        ocfs2_dlm_lock(no DLM_LKF_VALBLK)
      
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      
      dlm_lock(no DLM_LKF_VALBLK)
        convert_lock(overwrite lkb->lkb_exflags
                     with no DLM_LKF_VALBLK)
      
      RSB1: NULL                                        RSB1: EX
                                                        reset Node2
      dlm_recover_rsbs()
        recover_lvb()
      
      /* The LVB is not trustable if the node with EX fails and
       * no lock >= PR is left. We should set RSB_VALNOTVALID for RSB1.
       */
      
       if(!(kb_exflags & DLM_LKF_VALBLK)) /* This means we miss the chance to
                 return;                   * to invalid the LVB here.
                                           */
      
      The 2nd round:
      
               Node 1                                Node2
      RSB1(become master from recovery)
      
      ocfs2_setattr()
        ocfs2_inode_lock(NULL->EX)
          /* dlm_lock() return the stale lvb without setting DLM_SBF_VALNOTVALID */
          ocfs2_meta_lvb_is_trustable() return 1 /* so we don't refresh inode from disk */
        ocfs2_truncate_file()
            mlog_bug_on_msg(disk isize != i_size_read(inode))  /* crash! */
      
      The fix is quite straightforward.  We keep to set DLM_LKF_VALBLK flag
      for dlm_lock() if the lock resource type needs LVB and the fsdlm plugin
      is uesed.
      
      Link: http://lkml.kernel.org/r/1481275846-6604-1-git-send-email-zren@suse.comSigned-off-by: default avatarEric Ren <zren@suse.com>
      Reviewed-by: default avatarJoseph Qi <jiangqi903@gmail.com>
      Cc: Mark Fasheh <mfasheh@versity.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      257e62ac
    • Mark Rutland's avatar
      ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs · d49de65c
      Mark Rutland authored
      [ Upstream commit ddc37832 ]
      
      On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an
      undefined instruction trap within write_wb_reg. This is because Scorpion
      CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if
      the core is not powered down. When DBGPRSR.SPD is set, breakpoint and
      watchpoint registers are treated as undefined.
      
      It's possible to trigger similar crashes later on from userspace, by
      requesting the kernel to install a breakpoint or watchpoint, as we can
      go idle at any point between the reset of the debug registers and their
      later use. This has always been the case.
      
      Given that this has always been broken, no-one has complained until now,
      and there is no clear workaround, disable hardware breakpoints and
      watchpoints on Scorpion to avoid these issues.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d49de65c
    • Johan Hovold's avatar
      USB: serial: kl5kusb105: fix line-state error handling · 301242e3
      Johan Hovold authored
      [ Upstream commit 146cc8a1 ]
      
      The current implementation failed to detect short transfers when
      attempting to read the line state, and also, to make things worse,
      logged the content of the uninitialised heap transfer buffer.
      
      Fixes: abf492e7 ("USB: kl5kusb105: fix DMA buffers on stack")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      301242e3
    • Dennis Kadioglu's avatar
      ALSA: usb-audio: Add a quirk for Plantronics BT600 · 9b1f2ea4
      Dennis Kadioglu authored
      [ Upstream commit 2e40795c ]
      
      Plantronics BT600 does not support reading the sample rate which leads
      to many lines of "cannot get freq at ep 0x1" and "cannot get freq at
      ep 0x82". This patch adds the USB ID of the BT600 to quirks.c and
      avoids those error messages.
      Signed-off-by: default avatarDennis Kadioglu <denk@post.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9b1f2ea4
    • Zhou Chengming's avatar
      sysctl: Drop reference added by grab_header in proc_sys_readdir · 13d7adf6
      Zhou Chengming authored
      [ Upstream commit 93362fa4 ]
      
      Fixes CVE-2016-9191, proc_sys_readdir doesn't drop reference
      added by grab_header when return from !dir_emit_dots path.
      It can cause any path called unregister_sysctl_table will
      wait forever.
      
      The calltrace of CVE-2016-9191:
      
      [ 5535.960522] Call Trace:
      [ 5535.963265]  [<ffffffff817cdaaf>] schedule+0x3f/0xa0
      [ 5535.968817]  [<ffffffff817d33fb>] schedule_timeout+0x3db/0x6f0
      [ 5535.975346]  [<ffffffff817cf055>] ? wait_for_completion+0x45/0x130
      [ 5535.982256]  [<ffffffff817cf0d3>] wait_for_completion+0xc3/0x130
      [ 5535.988972]  [<ffffffff810d1fd0>] ? wake_up_q+0x80/0x80
      [ 5535.994804]  [<ffffffff8130de64>] drop_sysctl_table+0xc4/0xe0
      [ 5536.001227]  [<ffffffff8130de17>] drop_sysctl_table+0x77/0xe0
      [ 5536.007648]  [<ffffffff8130decd>] unregister_sysctl_table+0x4d/0xa0
      [ 5536.014654]  [<ffffffff8130deff>] unregister_sysctl_table+0x7f/0xa0
      [ 5536.021657]  [<ffffffff810f57f5>] unregister_sched_domain_sysctl+0x15/0x40
      [ 5536.029344]  [<ffffffff810d7704>] partition_sched_domains+0x44/0x450
      [ 5536.036447]  [<ffffffff817d0761>] ? __mutex_unlock_slowpath+0x111/0x1f0
      [ 5536.043844]  [<ffffffff81167684>] rebuild_sched_domains_locked+0x64/0xb0
      [ 5536.051336]  [<ffffffff8116789d>] update_flag+0x11d/0x210
      [ 5536.057373]  [<ffffffff817cf61f>] ? mutex_lock_nested+0x2df/0x450
      [ 5536.064186]  [<ffffffff81167acb>] ? cpuset_css_offline+0x1b/0x60
      [ 5536.070899]  [<ffffffff810fce3d>] ? trace_hardirqs_on+0xd/0x10
      [ 5536.077420]  [<ffffffff817cf61f>] ? mutex_lock_nested+0x2df/0x450
      [ 5536.084234]  [<ffffffff8115a9f5>] ? css_killed_work_fn+0x25/0x220
      [ 5536.091049]  [<ffffffff81167ae5>] cpuset_css_offline+0x35/0x60
      [ 5536.097571]  [<ffffffff8115aa2c>] css_killed_work_fn+0x5c/0x220
      [ 5536.104207]  [<ffffffff810bc83f>] process_one_work+0x1df/0x710
      [ 5536.110736]  [<ffffffff810bc7c0>] ? process_one_work+0x160/0x710
      [ 5536.117461]  [<ffffffff810bce9b>] worker_thread+0x12b/0x4a0
      [ 5536.123697]  [<ffffffff810bcd70>] ? process_one_work+0x710/0x710
      [ 5536.130426]  [<ffffffff810c3f7e>] kthread+0xfe/0x120
      [ 5536.135991]  [<ffffffff817d4baf>] ret_from_fork+0x1f/0x40
      [ 5536.142041]  [<ffffffff810c3e80>] ? kthread_create_on_node+0x230/0x230
      
      One cgroup maintainer mentioned that "cgroup is trying to offline
      a cpuset css, which takes place under cgroup_mutex.  The offlining
      ends up trying to drain active usages of a sysctl table which apprently
      is not happening."
      The real reason is that proc_sys_readdir doesn't drop reference added
      by grab_header when return from !dir_emit_dots path. So this cpuset
      offline path will wait here forever.
      
      See here for details: http://www.openwall.com/lists/oss-security/2016/11/04/13
      
      Fixes: f0c3b509 ("[readdir] convert procfs")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarCAI Qian <caiqian@redhat.com>
      Tested-by: default avatarYang Shukui <yangshukui@huawei.com>
      Signed-off-by: default avatarZhou Chengming <zhouchengming1@huawei.com>
      Acked-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      13d7adf6
    • Eric W. Biederman's avatar
      mnt: Protect the mountpoint hashtable with mount_lock · 89aca6c9
      Eric W. Biederman authored
      [ Upstream commit 3895dbf8 ]
      
      Protecting the mountpoint hashtable with namespace_sem was sufficient
      until a call to umount_mnt was added to mntput_no_expire.  At which
      point it became possible for multiple calls of put_mountpoint on
      the same hash chain to happen on the same time.
      
      Kristen Johansen <kjlx@templeofstupid.com> reported:
      > This can cause a panic when simultaneous callers of put_mountpoint
      > attempt to free the same mountpoint.  This occurs because some callers
      > hold the mount_hash_lock, while others hold the namespace lock.  Some
      > even hold both.
      >
      > In this submitter's case, the panic manifested itself as a GP fault in
      > put_mountpoint() when it called hlist_del() and attempted to dereference
      > a m_hash.pprev that had been poisioned by another thread.
      
      Al Viro observed that the simple fix is to switch from using the namespace_sem
      to the mount_lock to protect the mountpoint hash table.
      
      I have taken Al's suggested patch moved put_mountpoint in pivot_root
      (instead of taking mount_lock an additional time), and have replaced
      new_mountpoint with get_mountpoint a function that does the hash table
      lookup and addition under the mount_lock.   The introduction of get_mounptoint
      ensures that only the mount_lock is needed to manipulate the mountpoint
      hashtable.
      
      d_set_mounted is modified to only set DCACHE_MOUNTED if it is not
      already set.  This allows get_mountpoint to use the setting of
      DCACHE_MOUNTED to ensure adding a struct mountpoint for a dentry
      happens exactly once.
      
      Cc: stable@vger.kernel.org
      Fixes: ce07d891 ("mnt: Honor MNT_LOCKED when detaching mounts")
      Reported-by: default avatarKrister Johansen <kjlx@templeofstupid.com>
      Suggested-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Acked-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      89aca6c9
    • Johan Hovold's avatar
      USB: serial: ch341: fix open error handling · f8969b94
      Johan Hovold authored
      [ Upstream commit f2950b78 ]
      
      Make sure to stop the interrupt URB before returning on errors during
      open.
      
      Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f8969b94
    • Johan Hovold's avatar
      USB: serial: ch341: fix modem-control and B0 handling · c72629ab
      Johan Hovold authored
      [ Upstream commit 030ee7ae ]
      
      The modem-control signals are managed by the tty-layer during open and
      should not be asserted prematurely when set_termios is called from
      driver open.
      
      Also make sure that the signals are asserted only when changing speed
      from B0.
      
      Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c72629ab
    • Johan Hovold's avatar
      USB: serial: ch341: fix open and resume after B0 · f7ee5552
      Johan Hovold authored
      [ Upstream commit a20047f3 ]
      
      The private baud_rate variable is used to configure the port at open and
      reset-resume and must never be set to (and left at) zero or reset-resume
      and all further open attempts will fail.
      
      Fixes: aa91def4 ("USB: ch341: set tty baud speed according to tty
      struct")
      Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f7ee5552
    • Johan Hovold's avatar
      USB: serial: ch341: fix initial modem-control state · 022104d5
      Johan Hovold authored
      [ Upstream commit 4e2da446 ]
      
      DTR and RTS will be asserted by the tty-layer when the port is opened
      and deasserted on close (if HUPCL is set). Make sure the initial state
      is not-asserted before the port is first opened as well.
      
      Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      022104d5
    • Alex Deucher's avatar
      drm/radeon: drop verde dpm quirks · 49d412ae
      Alex Deucher authored
      [ Upstream commit 8a08403b ]
      
      fixes:
      https://bugs.freedesktop.org/show_bug.cgi?id=98897
      https://bugs.launchpad.net/bugs/1651981Acked-by: default avatarEdward O'Callaghan <funfunctor@folklore1984.net>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Cc: Adrian Fiergolski <A.Fiergolski@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      49d412ae