Linux Kernel 4.19.70 Release

This post summarizes new features, bugfixes and changes in Linux kernel release 4.19.70. Linux 4.19.70 Release contains 95 changes, patches or new features.

In total, there are 101,521 lines of Linux source code changed/added in Linux 4.19.70 release compared to Linux 4.19 release. To view the source code of Linux 4.19.70 kernel release online, please check the linux-stable tree for Linux 4.19.70. If you would like to download the release package for Linux 4.19.70, please click: Linux 4.19.70. To download the patchset for Linux 4.19.70 release, please click: Linux 4.19.70 patch.

All changes in this Linux release are as follows.

Linux 4.19.70

This change “Linux 4.19.70” (commit 0fed55c) in Linux kernel is authored by Greg Kroah-Hartman <gregkh [at] linuxfoundation.org> on Fri Sep 6 10:22:24 2019 +0200.

The change “Linux 4.19.70” introduces changes as follows.

Linux 4.19.70

The commit for this change in Linux stable tree is 0fed55c (patch).

Revert “ASoC: Fail card instantiation if DAI format setup fails”

This change “Revert “ASoC: Fail card instantiation if DAI format setup fails”” (commit 9854d08) in Linux kernel is authored by Greg Kroah-Hartman <gregkh [at] linuxfoundation.org> on Thu Sep 5 20:48:46 2019 +0200.

The change “Revert “ASoC: Fail card instantiation if DAI format setup fails”” introduces changes as follows.

Revert "ASoC: Fail card instantiation if DAI format setup fails"

This reverts commit 714a8438fc8ae88aa22c25065e241bce0260db13 which is
commit 40aa5383e393d72f6aa3943a4e7b1aae25a1e43b upstream.

Mark Brown writes:
        I nacked this patch when Sasha posted it - it only improves
        diagnostics and might make systems that worked by accident break
        since it turns things into a hard failure, it won't make
        anything that didn't work previously work.

Reported-by: Mark Brown <broonie@kernel.org>
Cc: Ricard Wanderlof <ricardw@axis.com>
Cc: Sasha Levin <sashal@kernel.org>
Link: https://lore.kernel.org/lkml/20190904181027.GG4348@sirena.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 9854d08 (patch).

mt76: mt76x0u: do not reset radio on resume

This change “mt76: mt76x0u: do not reset radio on resume” (commit e064466) in Linux kernel is authored by Stanislaw Gruszka <sgruszka [at] redhat.com> on Wed Sep 4 10:07:10 2019 +0200.

The change “mt76: mt76x0u: do not reset radio on resume” introduces changes as follows.

mt76: mt76x0u: do not reset radio on resume

commit 8f2d163cb26da87e7d8e1677368b8ba1ba4d30b3 upstream.

On some machines mt76x0u firmware can hung during resume,
what result on messages like below:

[  475.480062] mt76x0 1-8:1.0: Error: MCU response pre-completed!
[  475.990066] mt76x0 1-8:1.0: Error: send MCU cmd failed:-110
[  475.990075] mt76x0 1-8:1.0: Error: MCU response pre-completed!
[  476.500003] mt76x0 1-8:1.0: Error: send MCU cmd failed:-110
[  476.500012] mt76x0 1-8:1.0: Error: MCU response pre-completed!
[  477.010046] mt76x0 1-8:1.0: Error: send MCU cmd failed:-110
[  477.010055] mt76x0 1-8:1.0: Error: MCU response pre-completed!
[  477.529997] mt76x0 1-8:1.0: Error: send MCU cmd failed:-110
[  477.530006] mt76x0 1-8:1.0: Error: MCU response pre-completed!
[  477.824907] mt76x0 1-8:1.0: Error: send MCU cmd failed:-71
[  477.824916] mt76x0 1-8:1.0: Error: MCU response pre-completed!
[  477.825029] usb 1-8: USB disconnect, device number 6

and possible whole system freeze.

This can be avoided, if we do not perform mt76x0_chip_onoff() reset.

Cc: stable@vger.kernel.org
Fixes: 134b2d0d1fcf ("mt76x0: init files")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is e064466 (patch).

x86/ptrace: fix up botched merge of spectrev1 fix

This change “x86/ptrace: fix up botched merge of spectrev1 fix” (commit b307f99) in Linux kernel is authored by Greg Kroah-Hartman <gregkh [at] linuxfoundation.org> on Wed Sep 4 12:27:18 2019 +0200.

The change “x86/ptrace: fix up botched merge of spectrev1 fix” introduces changes as follows.

x86/ptrace: fix up botched merge of spectrev1 fix

I incorrectly merged commit 31a2fbb390fe ("x86/ptrace: Fix possible
spectre-v1 in ptrace_get_debugreg()") when backporting it, as was
graciously pointed out at
https://grsecurity.net/teardown_of_a_failed_linux_lts_spectre_fix.php

Resolve the upstream difference with the stable kernel merge to properly
protect things.

Reported-by: Brad Spengler <spender@grsecurity.net>
Cc: Dianzhang Chen <dianzhangchen0@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <bp@alien8.de>
Cc: <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is b307f99 (patch).

i2c: piix4: Fix port selection for AMD Family 16h Model 30h

This change “i2c: piix4: Fix port selection for AMD Family 16h Model 30h” (commit 3b26fa9) in Linux kernel is authored by Andrew Cooks <andrew.cooks [at] opengear.com> on Fri Aug 2 14:52:46 2019 +0200.

The change “i2c: piix4: Fix port selection for AMD Family 16h Model 30h” introduces changes as follows.

i2c: piix4: Fix port selection for AMD Family 16h Model 30h

[ Upstream commit c7c06a1532f3fe106687ac82a13492c6a619ff1c ]

Family 16h Model 30h SMBus controller needs the same port selection fix
as described and fixed in commit 0fe16195f891 ("i2c: piix4: Fix SMBus port
selection for AMD Family 17h chips")

commit 6befa3fde65f ("i2c: piix4: Support alternative port selection
register") also fixed the port selection for Hudson2, but unfortunately
this is not the exact same device and the AMD naming and PCI Device IDs
aren't particularly helpful here.

The SMBus port selection register is common to the following Families
and models, as documented in AMD's publicly available BIOS and Kernel
Developer Guides:

 50742 - Family 15h Model 60h-6Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)
 55072 - Family 15h Model 70h-7Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)
 52740 - Family 16h Model 30h-3Fh (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS)

The Hudson2 PCI Device ID (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) is shared
between Bolton FCH and Family 16h Model 30h, but the location of the
SmBus0Sel port selection bits are different:

 51192 - Bolton Register Reference Guide

We distinguish between Bolton and Family 16h Model 30h using the PCI
Revision ID:

  Bolton is device 0x780b, revision 0x15
  Family 16h Model 30h is device 0x780b, revision 0x1F
  Family 15h Model 60h and 70h are both device 0x790b, revision 0x4A.

The following additional public AMD BKDG documents were checked and do
not share the same port selection register:

 42301 - Family 15h Model 00h-0Fh doesn't mention any
 42300 - Family 15h Model 10h-1Fh doesn't mention any
 49125 - Family 15h Model 30h-3Fh doesn't mention any

 48751 - Family 16h Model 00h-0Fh uses the previously supported
         index register SB800_PIIX4_PORT_IDX_ALT at 0x2e

Signed-off-by: Andrew Cooks <andrew.cooks@opengear.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: stable@vger.kernel.org [v4.6+]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 3b26fa9 (patch).

NFS: Ensure O_DIRECT reports an error if the bytes read/written is 0

This change “NFS: Ensure O_DIRECT reports an error if the bytes read/written is 0” (commit 4f4be79) in Linux kernel is authored by Trond Myklebust <trond.myklebust [at] hammerspace.com> on Mon Aug 12 18:04:36 2019 -0400.

The change “NFS: Ensure O_DIRECT reports an error if the bytes read/written is 0” introduces changes as follows.

NFS: Ensure O_DIRECT reports an error if the bytes read/written is 0

[ Upstream commit eb2c50da9e256dbbb3ff27694440e4c1900cfef8 ]

If the attempt to resend the I/O results in no bytes being read/written,
we must ensure that we report the error.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Fixes: 0a00b77b331a ("nfs: mirroring support for direct io")
Cc: stable@vger.kernel.org # v3.20+
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 4f4be79 (patch).

NFS: Pass error information to the pgio error cleanup routine

This change “NFS: Pass error information to the pgio error cleanup routine” (commit b5891b6) in Linux kernel is authored by Trond Myklebust <trond.myklebust [at] hammerspace.com> on Wed Feb 13 10:39:39 2019 -0500.

The change “NFS: Pass error information to the pgio error cleanup routine” introduces changes as follows.

NFS: Pass error information to the pgio error cleanup routine

[ Upstream commit df3accb849607a86278a37c35e6b313635ccc48b ]

Allow the caller to pass error information when cleaning up a failed
I/O request so that we can conditionally take action to cancel the
request altogether if the error turned out to be fatal.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is b5891b6 (patch).

NFSv4/pnfs: Fix a page lock leak in nfs_pageio_resend()

This change “NFSv4/pnfs: Fix a page lock leak in nfs_pageio_resend()” (commit 812de6d) in Linux kernel is authored by Trond Myklebust <trond.myklebust [at] hammerspace.com> on Mon Aug 12 15:19:54 2019 -0400.

The change “NFSv4/pnfs: Fix a page lock leak in nfs_pageio_resend()” introduces changes as follows.

NFSv4/pnfs: Fix a page lock leak in nfs_pageio_resend()

[ Upstream commit f4340e9314dbfadc48758945f85fc3b16612d06f ]

If the attempt to resend the pages fails, we need to ensure that we
clean up those pages that were not transmitted.

Fixes: d600ad1f2bdb ("NFS41: pop some layoutget errors to application")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: stable@vger.kernel.org # v4.5+
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 812de6d (patch).

NFS: Clean up list moves of struct nfs_page

This change “NFS: Clean up list moves of struct nfs_page” (commit 57c491f) in Linux kernel is authored by Trond Myklebust <trond.myklebust [at] hammerspace.com> on Mon Feb 18 11:35:54 2019 -0500.

The change “NFS: Clean up list moves of struct nfs_page” introduces changes as follows.

NFS: Clean up list moves of struct nfs_page

[ Upstream commit 078b5fd92c4913dd367361db6c28568386077c89 ]

In several places we're just moving the struct nfs_page from one list to
another by first removing from the existing list, then adding to the new
one.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 57c491f (patch).

KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI

This change “KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI” (commit 79f1b33) in Linux kernel is authored by Marc Zyngier <maz [at] kernel.org> on Wed Aug 28 11:10:16 2019 +0100.

The change “KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI” introduces changes as follows.

KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI

[ Upstream commit 82e40f558de566fdee214bec68096bbd5e64a6a4 ]

A guest is not allowed to inject a SGI (or clear its pending state)
by writing to GICD_ISPENDR0 (resp. GICD_ICPENDR0), as these bits are
defined as WI (as per ARM IHI 0048B 4.3.7 and 4.3.8).

Make sure we correctly emulate the architecture.

Fixes: 96b298000db4 ("KVM: arm/arm64: vgic-new: Add PENDING registers handlers")
Cc: stable@vger.kernel.org # 4.7+
Reported-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 79f1b33 (patch).

KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long

This change “KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long” (commit ab8ecc2) in Linux kernel is authored by Heyi Guo <guoheyi [at] huawei.com> on Tue Aug 27 12:26:50 2019 +0100.

The change “KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long” introduces changes as follows.

KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long

[ Upstream commit d4a8061a7c5f7c27a2dc002ee4cb89b3e6637e44 ]

If the ap_list is longer than 256 entries, merge_final() in list_sort()
will call the comparison callback with the same element twice, causing
a deadlock in vgic_irq_cmp().

Fix it by returning early when irqa == irqb.

Cc: stable@vger.kernel.org # 4.7+
Fixes: 8e4447457965 ("KVM: arm/arm64: vgic-new: Add IRQ sorting")
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
[maz: massaged commit log and patch, added Fixes and Cc-stable]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is ab8ecc2 (patch).

KVM: PPC: Book3S: Fix incorrect guest-to-user-translation error handling

This change “KVM: PPC: Book3S: Fix incorrect guest-to-user-translation error handling” (commit db1841a) in Linux kernel is authored by Alexey Kardashevskiy <aik [at] ozlabs.ru> on Tue Sep 3 16:16:27 2019 -0400.

The change “KVM: PPC: Book3S: Fix incorrect guest-to-user-translation error handling” introduces changes as follows.

KVM: PPC: Book3S: Fix incorrect guest-to-user-translation error handling

[ Upstream commit ddfd151f3def9258397fcde7a372205a2d661903 ]

H_PUT_TCE_INDIRECT handlers receive a page with up to 512 TCEs from
a guest. Although we verify correctness of TCEs before we do anything
with the existing tables, there is a small window when a check in
kvmppc_tce_validate might pass and right after that the guest alters
the page of TCEs, causing an early exit from the handler and leaving
srcu_read_lock(&vcpu->kvm->srcu) (virtual mode) or lock_rmap(rmap)
(real mode) locked.

This fixes the bug by jumping to the common exit code with an appropriate
unlock.

Cc: stable@vger.kernel.org # v4.11+
Fixes: 121f80ba68f1 ("KVM: PPC: VFIO: Add in-kernel acceleration for VFIO")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is db1841a (patch).

mac80211: Correctly set noencrypt for PAE frames

This change “mac80211: Correctly set noencrypt for PAE frames” (commit 938e383) in Linux kernel is authored by Denis Kenzior <denkenz [at] gmail.com> on Tue Aug 27 17:41:20 2019 -0500.

The change “mac80211: Correctly set noencrypt for PAE frames” introduces changes as follows.

mac80211: Correctly set noencrypt for PAE frames

commit f8b43c5cf4b62a19f2210a0f5367b84e1eff1ab9 upstream.

The noencrypt flag was intended to be set if the "frame was received
unencrypted" according to include/uapi/linux/nl80211.h.  However, the
current behavior is opposite of this.

Cc: stable@vger.kernel.org
Fixes: 018f6fbf540d ("mac80211: Send control port frames over nl80211")
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
Link: https://lore.kernel.org/r/20190827224120.14545-3-denkenz@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 938e383 (patch).

mac80211: Don’t memset RXCB prior to PAE intercept

This change “mac80211: Don’t memset RXCB prior to PAE intercept” (commit 4f139c0) in Linux kernel is authored by Denis Kenzior <denkenz [at] gmail.com> on Tue Aug 27 17:41:19 2019 -0500.

The change “mac80211: Don’t memset RXCB prior to PAE intercept” introduces changes as follows.

mac80211: Don't memset RXCB prior to PAE intercept

commit c8a41c6afa27b8c3f61622dfd882b912da9d6721 upstream.

In ieee80211_deliver_skb_to_local_stack intercepts EAPoL frames if
mac80211 is configured to do so and forwards the contents over nl80211.
During this process some additional data is also forwarded, including
whether the frame was received encrypted or not.  Unfortunately just
prior to the call to ieee80211_deliver_skb_to_local_stack, skb->cb is
cleared, resulting in incorrect data being exposed over nl80211.

Fixes: 018f6fbf540d ("mac80211: Send control port frames over nl80211")
Cc: stable@vger.kernel.org
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
Link: https://lore.kernel.org/r/20190827224120.14545-2-denkenz@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 4f139c0 (patch).

mac80211: fix possible sta leak

This change “mac80211: fix possible sta leak” (commit 58f91aa) in Linux kernel is authored by Johannes Berg <johannes.berg [at] intel.com> on Thu Aug 1 09:30:33 2019 +0200.

The change “mac80211: fix possible sta leak” introduces changes as follows.

mac80211: fix possible sta leak

commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 upstream.

If TDLS station addition is rejected, the sta memory is leaked.
Avoid this by moving the check before the allocation.

Cc: stable@vger.kernel.org
Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 58f91aa (patch).

Revert “cfg80211: fix processing world regdomain when non modular”

This change “Revert “cfg80211: fix processing world regdomain when non modular”” (commit 945b359) in Linux kernel is authored by Hodaszi, Robert <Robert.Hodaszi [at] digi.com> on Fri Jun 14 13:16:01 2019 +0000.

The change “Revert “cfg80211: fix processing world regdomain when non modular”” introduces changes as follows.

Revert "cfg80211: fix processing world regdomain when non modular"

commit 0d31d4dbf38412f5b8b11b4511d07b840eebe8cb upstream.

This reverts commit 96cce12ff6e0 ("cfg80211: fix processing world
regdomain when non modular").

Re-triggering a reg_process_hint with the last request on all events,
can make the regulatory domain fail in case of multiple WiFi modules. On
slower boards (espacially with mdev), enumeration of the WiFi modules
can end up in an intersected regulatory domain, and user cannot set it
with 'iw reg set' anymore.

This is happening, because:
- 1st module enumerates, queues up a regulatory request
- request gets processed by __reg_process_hint_driver():
  - checks if previous was set by CORE -> yes
    - checks if regulator domain changed -> yes, from '00' to e.g. 'US'
      -> sends request to the 'crda'
- 2nd module enumerates, queues up a regulator request (which triggers
  the reg_todo() work)
- reg_todo() -> reg_process_pending_hints() sees, that the last request
  is not processed yet, so it tries to process it again.
  __reg_process_hint driver() will run again, and:
  - checks if the last request's initiator was the core -> no, it was
    the driver (1st WiFi module)
  - checks, if the previous initiator was the driver -> yes
    - checks if the regulator domain changed -> yes, it was '00' (set by
      core, and crda call did not return yet), and should be changed to 'US'

------> __reg_process_hint_driver calls an intersect

Besides, the reg_process_hint call with the last request is meaningless
since the crda call has a timeout work. If that timeout expires, the
first module's request will lost.

Cc: stable@vger.kernel.org
Fixes: 96cce12ff6e0 ("cfg80211: fix processing world regdomain when non modular")
Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com>
Link: https://lore.kernel.org/r/20190614131600.GA13897@a1-hr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 945b359 (patch).

crypto: ccp – Ignore unconfigured CCP device on suspend/resume

This change “crypto: ccp – Ignore unconfigured CCP device on suspend/resume” (commit 690a424) in Linux kernel is authored by Gary R Hook <gary.hook [at] amd.com> on Mon Aug 19 22:23:27 2019 +0000.

The change “crypto: ccp – Ignore unconfigured CCP device on suspend/resume” introduces changes as follows.

crypto: ccp - Ignore unconfigured CCP device on suspend/resume

commit 5871cd93692c8071fb9358daccb715b5081316ac upstream.

If a CCP is unconfigured (e.g. there are no available queues) then
there will be no data structures allocated for the device. Thus, we
must check for validity of a pointer before trying to access structure
members.

Fixes: 720419f01832f ("crypto: ccp - Introduce the AMD Secure Processor device")
Cc: <stable@vger.kernel.org>
Signed-off-by: Gary R Hook <gary.hook@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 690a424 (patch).

VMCI: Release resource if the work is already queued

This change “VMCI: Release resource if the work is already queued” (commit 4e77b2e) in Linux kernel is authored by Nadav Amit <namit [at] vmware.com> on Tue Aug 20 13:26:38 2019 -0700.

The change “VMCI: Release resource if the work is already queued” introduces changes as follows.

VMCI: Release resource if the work is already queued

commit ba03a9bbd17b149c373c0ea44017f35fc2cd0f28 upstream.

Francois reported that VMware balloon gets stuck after a balloon reset,
when the VMCI doorbell is removed. A similar error can occur when the
balloon driver is removed with the following splat:

[ 1088.622000] INFO: task modprobe:3565 blocked for more than 120 seconds.
[ 1088.622035]       Tainted: G        W         5.2.0 #4
[ 1088.622087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1088.622205] modprobe        D    0  3565   1450 0x00000000
[ 1088.622210] Call Trace:
[ 1088.622246]  __schedule+0x2a8/0x690
[ 1088.622248]  schedule+0x2d/0x90
[ 1088.622250]  schedule_timeout+0x1d3/0x2f0
[ 1088.622252]  wait_for_completion+0xba/0x140
[ 1088.622320]  ? wake_up_q+0x80/0x80
[ 1088.622370]  vmci_resource_remove+0xb9/0xc0 [vmw_vmci]
[ 1088.622373]  vmci_doorbell_destroy+0x9e/0xd0 [vmw_vmci]
[ 1088.622379]  vmballoon_vmci_cleanup+0x6e/0xf0 [vmw_balloon]
[ 1088.622381]  vmballoon_exit+0x18/0xcc8 [vmw_balloon]
[ 1088.622394]  __x64_sys_delete_module+0x146/0x280
[ 1088.622408]  do_syscall_64+0x5a/0x130
[ 1088.622410]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1088.622415] RIP: 0033:0x7f54f62791b7
[ 1088.622421] Code: Bad RIP value.
[ 1088.622421] RSP: 002b:00007fff2a949008 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[ 1088.622426] RAX: ffffffffffffffda RBX: 000055dff8b55d00 RCX: 00007f54f62791b7
[ 1088.622426] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055dff8b55d68
[ 1088.622427] RBP: 000055dff8b55d00 R08: 00007fff2a947fb1 R09: 0000000000000000
[ 1088.622427] R10: 00007f54f62f5cc0 R11: 0000000000000206 R12: 000055dff8b55d68
[ 1088.622428] R13: 0000000000000001 R14: 000055dff8b55d68 R15: 00007fff2a94a3f0

The cause for the bug is that when the "delayed" doorbell is invoked, it
takes a reference on the doorbell entry and schedules work that is
supposed to run the appropriate code and drop the doorbell entry
reference. The code ignores the fact that if the work is already queued,
it will not be scheduled to run one more time. As a result one of the
references would not be dropped. When the code waits for the reference
to get to zero, during balloon reset or module removal, it gets stuck.

Fix it. Drop the reference if schedule_work() indicates that the work is
already queued.

Note that this bug got more apparent (or apparent at all) due to
commit ce664331b248 ("vmw_balloon: VMCI_DOORBELL_SET does not check status").

Fixes: 83e2ec765be03 ("VMCI: doorbell implementation.")
Reported-by: Francois Rigault <rigault.francois@gmail.com>
Cc: Jorgen Hansen <jhansen@vmware.com>
Cc: Adit Ranadive <aditr@vmware.com>
Cc: Alexios Zavras <alexios.zavras@intel.com>
Cc: Vishnu DASA <vdasa@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Nadav Amit <namit@vmware.com>
Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
Link: https://lore.kernel.org/r/20190820202638.49003-1-namit@vmware.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 4e77b2e (patch).

bus: hisi_lpc: Add .remove method to avoid driver unbind crash

This change “bus: hisi_lpc: Add .remove method to avoid driver unbind crash” (commit 2a96487) in Linux kernel is authored by John Garry <john.garry [at] huawei.com> on Tue Jul 30 21:29:56 2019 +0800.

The change “bus: hisi_lpc: Add .remove method to avoid driver unbind crash” introduces changes as follows.

bus: hisi_lpc: Add .remove method to avoid driver unbind crash

commit 10e62b47973b0b0ceda076255bcb147b83e20517 upstream.

The original driver author seemed to be under the impression that a driver
cannot be removed if it does not have a .remove method. Or maybe if it is
a built-in platform driver.

This is not true. This crash can be created:

root@ubuntu:/sys/bus/platform/drivers/hisi-lpc# echo HISI0191\:00 > unbind
root@ubuntu:/sys/bus/platform/drivers/hisi-lpc# ipmitool raw 6 1
 Unable to handle kernel paging request at virtual address ffff000010035010
 Mem abort info:
   ESR = 0x96000047
   Exception class = DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
 Data abort info:
   ISV = 0, ISS = 0x00000047
   CM = 0, WnR = 1
 swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000118b000
 [ffff000010035010] pgd=0000041ffbfff003, pud=0000041ffbffe003, pmd=0000041ffbffd003, pte=0000000000000000
 Internal error: Oops: 96000047 [#1] PREEMPT SMP
 Modules linked in:
 CPU: 17 PID: 1473 Comm: ipmitool Not tainted 5.2.0-rc5-00003-gf68c53b414a3-dirty #198
 Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018
 pstate: 20000085 (nzCv daIf -PAN -UAO)
 pc : hisi_lpc_target_in+0x7c/0x120
 lr : hisi_lpc_target_in+0x70/0x120
 sp : ffff00001efe3930
 x29: ffff00001efe3930 x28: ffff841f9f599200
 x27: 0000000000000002 x26: 0000000000000000
 x25: 0000000000000080 x24: 00000000000000e4
 x23: 0000000000000000 x22: 0000000000000064
 x21: ffff801fb667d280 x20: 0000000000000001
 x19: ffff00001efe39ac x18: 0000000000000000
 x17: 0000000000000000 x16: 0000000000000000
 x15: 0000000000000000 x14: 0000000000000000
 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000000 x10: 0000000000000000
 x9 : 0000000000000000 x8 : ffff841febe60340
 x7 : ffff801fb55c52e8 x6 : 0000000000000000
 x5 : 0000000000ffc0e3 x4 : 0000000000000001
 x3 : ffff801fb667d280 x2 : 0000000000000001
 x1 : ffff000010035010 x0 : ffff000010035000
 Call trace:
  hisi_lpc_target_in+0x7c/0x120
  hisi_lpc_comm_in+0x88/0x98
  logic_inb+0x5c/0xb8
  port_inb+0x18/0x20
  bt_event+0x38/0x808
  smi_event_handler+0x4c/0x5a0
  check_start_timer_thread.part.4+0x40/0x58
  sender+0x78/0x88
  smi_send.isra.6+0x94/0x108
  i_ipmi_request+0x2c4/0x8f8
  ipmi_request_settime+0x124/0x160
  handle_send_req+0x19c/0x208
  ipmi_ioctl+0x2c0/0x990
  do_vfs_ioctl+0xb8/0x8f8
  ksys_ioctl+0x80/0xb8
  __arm64_sys_ioctl+0x1c/0x28
  el0_svc_common.constprop.0+0x64/0x160
  el0_svc_handler+0x28/0x78
  el0_svc+0x8/0xc
 Code: 941d1511 aa0003f9 f94006a0 91004001 (b9000034)
 ---[ end trace aa842b86af7069e4 ]---

The problem here is that the host goes away but the associated logical PIO
region remains registered, as do the children devices.

Fix by adding a .remove method to tidy-up by removing the child devices
and unregistering the logical PIO region.

Cc: stable@vger.kernel.org
Fixes: adf38bb0b595 ("HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings")
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 2a96487 (patch).

bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after-free

This change “bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after-free” (commit 649532e) in Linux kernel is authored by John Garry <john.garry [at] huawei.com> on Tue Jul 30 21:29:55 2019 +0800.

The change “bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after-free” introduces changes as follows.

bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after-free

commit 1b15a5632a809ab57d403fd972ca68785363b654 upstream.

If, after registering a logical PIO range, the driver probe later fails,
the logical PIO range memory will be released automatically.

This causes an issue, in that the logical PIO range is not unregistered
and the released range memory may be later referenced.

Fix by unregistering the logical PIO range.

And since we now unregister the logical PIO range for probe failure, avoid
the special ordering of setting logical PIO range ops, which was the
previous (poor) attempt at a safeguard against this.

Cc: stable@vger.kernel.org
Fixes: adf38bb0b595 ("HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings")
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 649532e (patch).

drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe()

This change “drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe()” (commit 68b58d3) in Linux kernel is authored by Lyude Paul <lyude [at] redhat.com> on Fri Aug 23 16:52:51 2019 -0400.

The change “drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe()” introduces changes as follows.

drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe()

commit 32f0a982650b123bdab36865617d3e03ebcacf3b upstream.

Currently, we don't call dma_set_max_seg_size() for i915 because we
intentionally do not limit the segment length that the device supports.
However, this results in a warning being emitted if we try to map
anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
enabled:

[    7.751926] DMA-API: i915 0000:00:02.0: mapping sg segment longer
than device claims to support [len=98304] [max=65536]
[    7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220
debug_dma_map_sg+0x20f/0x340

This was originally brought up on
https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus
there was it wasn't really useful to set a limit (and that dma-debug
isn't really all that useful for i915 in the first place). Unfortunately
though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for
various distro kernels. Since a WARN_ON() will disable automatic problem
reporting (and cause any CI with said option enabled to start
complaining), we really should just fix the problem.

Note that as me and Chris Wilson discussed, the other solution for this
would be to make DMA-API not make such assumptions when a driver hasn't
explicitly set a maximum segment size. But, taking a look at the commit
which originally introduced this behavior, commit 78c47830a5cb
("dma-debug: check scatterlist segments"), there is an explicit mention
of this assumption and how it applies to devices with no segment size:

        Conversely, devices which are less limited than the rather
        conservative defaults, or indeed have no limitations at all
        (e.g. GPUs with their own internal MMU), should be encouraged to
        set appropriate dma_parms, as they may get more efficient DMA
        mapping performance out of it.

So unless there's any concerns (I'm open to discussion!), let's just
follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit
to silence any warnings.

Changes since v3:
* Drop patch for enabling CONFIG_DMA_API_DEBUG_SG in CI. It looks like
  just turning it on causes the kernel to spit out bogus WARN_ONs()
  during some igt tests which would otherwise require teaching igt to
  disable the various DMA-API debugging options causing this. This is
  too much work to be worth it, since DMA-API debugging is useless for
  us. So, we'll just settle with this single patch to squelch WARN_ONs()
  during driver load for users that have CONFIG_DMA_API_DEBUG_SG turned
  on for some reason.
* Move dma_set_max_seg_size() call into i915_driver_hw_probe() - Chris
  Wilson

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://patchwork.freedesktop.org/patch/msgid/20190823205251.14298-1-lyude@redhat.com
(cherry picked from commit acd674af95d3f627062007429b9c195c6b32361d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 68b58d3 (patch).

drm/i915: Don’t deballoon unused ggtt drm_mm_node in linux guest

This change “drm/i915: Don’t deballoon unused ggtt drm_mm_node in linux guest” (commit c761533) in Linux kernel is authored by Xiong Zhang <xiong.y.zhang [at] intel.com> on Tue Aug 20 13:46:17 2019 +0800.

The change “drm/i915: Don’t deballoon unused ggtt drm_mm_node in linux guest” introduces changes as follows.

drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

commit 0a3dfbb5cd9033752639ef33e319c2f2863c713a upstream.

The following call trace may exist in linux guest dmesg when guest i915
driver is unloaded.
[   90.776610] [drm:vgt_deballoon_space.isra.0 [i915]] deballoon space: range [0x0 - 0x0] 0 KiB.
[   90.776621] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c0
[   90.776691] IP: drm_mm_remove_node+0x4d/0x320 [drm]
[   90.776718] PGD 800000012c7d0067 P4D 800000012c7d0067 PUD 138e4c067 PMD 0
[   90.777091] task: ffff9adab60f2f00 task.stack: ffffaf39c0fe0000
[   90.777142] RIP: 0010:drm_mm_remove_node+0x4d/0x320 [drm]
[   90.777573] Call Trace:
[   90.777653]  intel_vgt_deballoon+0x4c/0x60 [i915]
[   90.777729]  i915_ggtt_cleanup_hw+0x121/0x190 [i915]
[   90.777792]  i915_driver_unload+0x145/0x180 [i915]
[   90.777856]  i915_pci_remove+0x15/0x20 [i915]
[   90.777890]  pci_device_remove+0x3b/0xc0
[   90.777916]  device_release_driver_internal+0x157/0x220
[   90.777945]  driver_detach+0x39/0x70
[   90.777967]  bus_remove_driver+0x51/0xd0
[   90.777990]  pci_unregister_driver+0x23/0x90
[   90.778019]  SyS_delete_module+0x1da/0x240
[   90.778045]  entry_SYSCALL_64_fastpath+0x24/0x87
[   90.778072] RIP: 0033:0x7f34312af067
[   90.778092] RSP: 002b:00007ffdea3da0d8 EFLAGS: 00000206
[   90.778297] RIP: drm_mm_remove_node+0x4d/0x320 [drm] RSP: ffffaf39c0fe3dc0
[   90.778344] ---[ end trace f4b1bc8305fc59dd ]---

Four drm_mm_node are used to reserve guest ggtt space, but some of them
may be skipped and not initialised due to space constraints in
intel_vgt_balloon(). If drm_mm_remove_node() is called with
uninitialized drm_mm_node, the above call trace occurs.

This patch check drm_mm_node's validity before calling
drm_mm_remove_node().

Fixes: ff8f797557c7("drm/i915: return the correct usable aperture size under gvt environment")
Cc: stable@vger.kernel.org
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1566279978-9659-1-git-send-email-xiong.y.zhang@intel.com
(cherry picked from commit 4776f3529d6b1e47f02904ad1d264d25ea22b27b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is c761533 (patch).

drm/amdgpu: Add APTX quirk for Dell Latitude 5495

This change “drm/amdgpu: Add APTX quirk for Dell Latitude 5495” (commit 6d3003f) in Linux kernel is authored by Kai-Heng Feng <kai.heng.feng [at] canonical.com> on Tue Aug 27 17:33:32 2019 +0800.

The change “drm/amdgpu: Add APTX quirk for Dell Latitude 5495” introduces changes as follows.

drm/amdgpu: Add APTX quirk for Dell Latitude 5495

commit 317a3aaef94d73ba6be88aea11b41bb631b2d581 upstream.

Needs ATPX rather than _PR3 to really turn off the dGPU. This can save
~5W when dGPU is runtime-suspended.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 6d3003f (patch).

lib: logic_pio: Add logic_pio_unregister_range()

This change “lib: logic_pio: Add logic_pio_unregister_range()” (commit c4616a9) in Linux kernel is authored by John Garry <john.garry [at] huawei.com> on Tue Jul 30 21:29:54 2019 +0800.

The change “lib: logic_pio: Add logic_pio_unregister_range()” introduces changes as follows.

lib: logic_pio: Add logic_pio_unregister_range()

commit b884e2de2afc68ce30f7093747378ef972dde253 upstream.

Add a function to unregister a logical PIO range.

Logical PIO space can still be leaked when unregistering certain
LOGIC_PIO_CPU_MMIO regions, but this acceptable for now since there are no
callers to unregister LOGIC_PIO_CPU_MMIO regions, and the logical PIO
region allocation scheme would need significant work to improve this.

Cc: stable@vger.kernel.org
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is c4616a9 (patch).

lib: logic_pio: Avoid possible overlap for unregistering regions

This change “lib: logic_pio: Avoid possible overlap for unregistering regions” (commit 7faef13) in Linux kernel is authored by John Garry <john.garry [at] huawei.com> on Tue Jul 30 21:29:53 2019 +0800.

The change “lib: logic_pio: Avoid possible overlap for unregistering regions” introduces changes as follows.

lib: logic_pio: Avoid possible overlap for unregistering regions

commit 0a27142bd1ee259e24a0be2b0133e5ca5df8da91 upstream.

The code was originally written to not support unregistering logical PIO
regions.

To accommodate supporting unregistering logical PIO regions, subtly modify
LOGIC_PIO_CPU_MMIO region registration code, such that the "end" of the
registered regions is the "end" of the last region, and not the sum of
the sizes of all the registered regions.

Cc: stable@vger.kernel.org
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 7faef13 (patch).

lib: logic_pio: Fix RCU usage

This change “lib: logic_pio: Fix RCU usage” (commit b865c2c) in Linux kernel is authored by John Garry <john.garry [at] huawei.com> on Tue Jul 30 21:29:52 2019 +0800.

The change “lib: logic_pio: Fix RCU usage” introduces changes as follows.

lib: logic_pio: Fix RCU usage

commit 06709e81c668f5f56c65b806895b278517bd44e0 upstream.

The traversing of io_range_list with list_for_each_entry_rcu()
is not properly protected by rcu_read_lock() and rcu_read_unlock(),
so add them.

These functions mark the critical section scope where the list is
protected for the reader, it cannot be  "reclaimed". Any updater - in
this case, the logical PIO registration functions - cannot update the
list until the reader exits this critical section.

In addition, the list traversing used in logic_pio_register_range()
does not need to use the rcu variant.

This is because we are already using io_range_mutex to guarantee mutual
exclusion from mutating the list.

Cc: stable@vger.kernel.org
Fixes: 031e3601869c ("lib: Add generic PIO mapping method")
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is b865c2c (patch).

fsi: scom: Don’t abort operations for minor errors

This change “fsi: scom: Don’t abort operations for minor errors” (commit 79829fc) in Linux kernel is authored by Eddie James <eajames [at] linux.ibm.com> on Tue Aug 27 12:12:49 2019 +0800.

The change “fsi: scom: Don’t abort operations for minor errors” introduces changes as follows.

fsi: scom: Don't abort operations for minor errors

commit 8919dfcb31161fae7d607bbef5247e5e82fd6457 upstream.

The scom driver currently fails out of operations if certain system
errors are flagged in the status register; system checkstop, special
attention, or recoverable error. These errors won't impact the ability
of the scom engine to perform operations, so the driver should continue
under these conditions.
Also, don't do a PIB reset for these conditions, since it won't help.

Fixes: 6b293258cded ("fsi: scom: Major overhaul")
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20190827041249.13381-1-jk@ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 79829fc (patch).

typec: tcpm: fix a typo in the comparison of pdo_max_voltage

This change “typec: tcpm: fix a typo in the comparison of pdo_max_voltage” (commit e44840b) in Linux kernel is authored by Colin Ian King <colin.king [at] canonical.com> on Thu Aug 22 14:52:12 2019 +0100.

The change “typec: tcpm: fix a typo in the comparison of pdo_max_voltage” introduces changes as follows.

typec: tcpm: fix a typo in the comparison of pdo_max_voltage

commit a684d8fd87182090ee96e34519ecdf009cef093a upstream.

There appears to be a typo in the comparison of pdo_max_voltage[i]
with the previous value, currently it is checking against the
array pdo_min_voltage rather than pdo_max_voltage. I believe this
is a typo. Fix this.

Addresses-Coverity: ("Copy-paste error")
Fixes: 5007e1b5db73 ("typec: tcpm: Validate source and sink caps")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20190822135212.10195-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is e44840b (patch).

intel_th: pci: Add Tiger Lake support

This change “intel_th: pci: Add Tiger Lake support” (commit e91c9c1) in Linux kernel is authored by Alexander Shishkin <alexander.shishkin [at] linux.intel.com> on Wed Aug 21 10:49:55 2019 +0300.

The change “intel_th: pci: Add Tiger Lake support” introduces changes as follows.

intel_th: pci: Add Tiger Lake support

commit 9c78255fdde45c6b9a1ee30f652f7b34c727f5c7 upstream.

This adds support for the Trace Hub in Tiger Lake PCH.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: stable@vger.kernel.org # v4.14+
Link: https://lore.kernel.org/r/20190821074955.3925-5-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is e91c9c1 (patch).

intel_th: pci: Add support for another Lewisburg PCH

This change “intel_th: pci: Add support for another Lewisburg PCH” (commit ce1c894) in Linux kernel is authored by Alexander Shishkin <alexander.shishkin [at] linux.intel.com> on Wed Aug 21 10:49:54 2019 +0300.

The change “intel_th: pci: Add support for another Lewisburg PCH” introduces changes as follows.

intel_th: pci: Add support for another Lewisburg PCH

commit 164eb56e3b64f3a816238d410c9efec7567a82ef upstream.

Add support for the Trace Hub in another Lewisburg PCH.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: stable@vger.kernel.org # v4.14+
Link: https://lore.kernel.org/r/20190821074955.3925-4-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is ce1c894 (patch).

stm class: Fix a double free of stm_source_device

This change “stm class: Fix a double free of stm_source_device” (commit cad1d3b) in Linux kernel is authored by Ding Xiang <dingxiang [at] cmss.chinamobile.com> on Wed Aug 21 10:49:52 2019 +0300.

The change “stm class: Fix a double free of stm_source_device” introduces changes as follows.

stm class: Fix a double free of stm_source_device

commit 961b6ffe0e2c403b09a8efe4a2e986b3c415391a upstream.

In the error path of stm_source_register_device(), the kfree is
unnecessary, as the put_device() before it ends up calling
stm_source_device_release() to free stm_source_device, leading to
a double free at the outer kfree() call. Remove it.

Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Fixes: 7bd1d4093c2fa ("stm class: Introduce an abstraction for System Trace Module devices")
Link: https://lore.kernel.org/linux-arm-kernel/1563354988-23826-1-git-send-email-dingxiang@cmss.chinamobile.com/
Cc: stable@vger.kernel.org # v4.4+
Link: https://lore.kernel.org/r/20190821074955.3925-2-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is cad1d3b (patch).

mmc: core: Fix init of SD cards reporting an invalid VDD range

This change “mmc: core: Fix init of SD cards reporting an invalid VDD range” (commit abc4234) in Linux kernel is authored by Ulf Hansson <ulf.hansson [at] linaro.org> on Tue Aug 27 10:10:43 2019 +0200.

The change “mmc: core: Fix init of SD cards reporting an invalid VDD range” introduces changes as follows.

mmc: core: Fix init of SD cards reporting an invalid VDD range

commit 72741084d903e65e121c27bd29494d941729d4a1 upstream.

The OCR register defines the supported range of VDD voltages for SD cards.
However, it has turned out that some SD cards reports an invalid voltage
range, for example having bit7 set.

When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from
the invalid VDD range, this triggers the core to run a power cycle of the
card to try to initialize it at the lowest common supported voltage.
Obviously this fails, since the card can't support it.

Let's fix this problem, by clearing invalid bits from the read OCR register
for SD cards, before proceeding with the VDD voltage negotiation.

Cc: stable@vger.kernel.org
Reported-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Philip Langdale <philipl@overt.org>
Tested-by: Philip Langdale <philipl@overt.org>
Tested-by: Manuel Presnitz <mail@mpy.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is abc4234 (patch).

mmc: sdhci-of-at91: add quirk for broken HS200

This change “mmc: sdhci-of-at91: add quirk for broken HS200” (commit 1ecc65e) in Linux kernel is authored by Eugen Hristev <eugen.hristev [at] microchip.com> on Thu Aug 8 08:35:40 2019 +0000.

The change “mmc: sdhci-of-at91: add quirk for broken HS200” introduces changes as follows.

mmc: sdhci-of-at91: add quirk for broken HS200

commit 7871aa60ae0086fe4626abdf5ed13eeddf306c61 upstream.

HS200 is not implemented in the driver, but the controller claims it
through caps. Remove it via a quirk, to make sure the mmc core do not try
to enable HS200, as it causes the eMMC initialization to fail.

Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 1ecc65e (patch).

mei: me: add Tiger Lake point LP device ID

This change “mei: me: add Tiger Lake point LP device ID” (commit be8e9fa) in Linux kernel is authored by Tomas Winkler <tomas.winkler [at] intel.com> on Mon Aug 19 13:32:10 2019 +0300.

The change “mei: me: add Tiger Lake point LP device ID” introduces changes as follows.

mei: me: add Tiger Lake point LP device ID

commit 587f17407741a5be07f8a2d1809ec946c8120962 upstream.

Add Tiger Lake Point device ID for TGP LP.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190819103210.32748-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is be8e9fa (patch).

USB: storage: ums-realtek: Whitelist auto-delink support

This change “USB: storage: ums-realtek: Whitelist auto-delink support” (commit 5ed3642) in Linux kernel is authored by Kai-Heng Feng <kai.heng.feng [at] canonical.com> on Wed Aug 28 01:34:50 2019 +0800.

The change “USB: storage: ums-realtek: Whitelist auto-delink support” introduces changes as follows.

USB: storage: ums-realtek: Whitelist auto-delink support

commit 1902a01e2bcc3abd7c9a18dc05e78c7ab4a53c54 upstream.

Auto-delink requires writing special registers to ums-realtek devices.
Unconditionally enable auto-delink may break newer devices.

So only enable auto-delink by default for the original three IDs,
0x0138, 0x0158 and 0x0159.

Realtek is working on a patch to properly support auto-delink for other
IDs.

BugLink: https://bugs.launchpad.net/bugs/1838886
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827173450.13572-2-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 5ed3642 (patch).

USB: storage: ums-realtek: Update module parameter description for auto_delink_en

This change “USB: storage: ums-realtek: Update module parameter description for auto_delink_en” (commit f79d159) in Linux kernel is authored by Kai-Heng Feng <kai.heng.feng [at] canonical.com> on Wed Aug 28 01:34:49 2019 +0800.

The change “USB: storage: ums-realtek: Update module parameter description for auto_delink_en” introduces changes as follows.

USB: storage: ums-realtek: Update module parameter description for auto_delink_en

commit f6445b6b2f2bb1745080af4a0926049e8bca2617 upstream.

The option named "auto_delink_en" is a bit misleading, as setting it to
false doesn't really disable auto-delink but let auto-delink be firmware
controlled.

Update the description to reflect the real usage of this parameter.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827173450.13572-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is f79d159 (patch).

usb: host: xhci: rcar: Fix typo in compatible string matching

This change “usb: host: xhci: rcar: Fix typo in compatible string matching” (commit f46fd68) in Linux kernel is authored by Geert Uytterhoeven <geert+renesas [at] glider.be> on Tue Aug 27 14:51:12 2019 +0200.

The change “usb: host: xhci: rcar: Fix typo in compatible string matching” introduces changes as follows.

usb: host: xhci: rcar: Fix typo in compatible string matching

commit 636bd02a7ba9025ff851d0cfb92768c8fa865859 upstream.

It's spelled "renesas", not "renensas".

Due to this typo, RZ/G1M and RZ/G1N were not covered by the check.

Fixes: 2dc240a3308b ("usb: host: xhci: rcar: retire use of xhci_plat_type_is()")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20190827125112.12192-1-geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is f46fd68 (patch).

usb: host: ohci: fix a race condition between shutdown and irq

This change “usb: host: ohci: fix a race condition between shutdown and irq” (commit 7af7737) in Linux kernel is authored by Yoshihiro Shimoda <yoshihiro.shimoda.uh [at] renesas.com> on Tue Aug 27 12:51:50 2019 +0900.

The change “usb: host: ohci: fix a race condition between shutdown and irq” introduces changes as follows.

usb: host: ohci: fix a race condition between shutdown and irq

commit a349b95d7ca0cea71be4a7dac29830703de7eb62 upstream.

This patch fixes an issue that the following error is
possible to happen when ohci hardware causes an interruption
and the system is shutting down at the same time.

[   34.851754] usb 2-1: USB disconnect, device number 2
[   35.166658] irq 156: nobody cared (try booting with the "irqpoll" option)
[   35.173445] CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 5.3.0-rc5 #85
[   35.179964] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
[   35.187886] Workqueue: usb_hub_wq hub_event
[   35.192063] Call trace:
[   35.194509]  dump_backtrace+0x0/0x150
[   35.198165]  show_stack+0x14/0x20
[   35.201475]  dump_stack+0xa0/0xc4
[   35.204785]  __report_bad_irq+0x34/0xe8
[   35.208614]  note_interrupt+0x2cc/0x318
[   35.212446]  handle_irq_event_percpu+0x5c/0x88
[   35.216883]  handle_irq_event+0x48/0x78
[   35.220712]  handle_fasteoi_irq+0xb4/0x188
[   35.224802]  generic_handle_irq+0x24/0x38
[   35.228804]  __handle_domain_irq+0x5c/0xb0
[   35.232893]  gic_handle_irq+0x58/0xa8
[   35.236548]  el1_irq+0xb8/0x180
[   35.239681]  __do_softirq+0x94/0x23c
[   35.243253]  irq_exit+0xd0/0xd8
[   35.246387]  __handle_domain_irq+0x60/0xb0
[   35.250475]  gic_handle_irq+0x58/0xa8
[   35.254130]  el1_irq+0xb8/0x180
[   35.257268]  kernfs_find_ns+0x5c/0x120
[   35.261010]  kernfs_find_and_get_ns+0x3c/0x60
[   35.265361]  sysfs_unmerge_group+0x20/0x68
[   35.269454]  dpm_sysfs_remove+0x2c/0x68
[   35.273284]  device_del+0x80/0x370
[   35.276683]  hid_destroy_device+0x28/0x60
[   35.280686]  usbhid_disconnect+0x4c/0x80
[   35.284602]  usb_unbind_interface+0x6c/0x268
[   35.288867]  device_release_driver_internal+0xe4/0x1b0
[   35.293998]  device_release_driver+0x14/0x20
[   35.298261]  bus_remove_device+0x110/0x128
[   35.302350]  device_del+0x148/0x370
[   35.305832]  usb_disable_device+0x8c/0x1d0
[   35.309921]  usb_disconnect+0xc8/0x2d0
[   35.313663]  hub_event+0x6e0/0x1128
[   35.317146]  process_one_work+0x1e0/0x320
[   35.321148]  worker_thread+0x40/0x450
[   35.324805]  kthread+0x124/0x128
[   35.328027]  ret_from_fork+0x10/0x18
[   35.331594] handlers:
[   35.333862] [<0000000079300c1d>] usb_hcd_irq
[   35.338126] [<0000000079300c1d>] usb_hcd_irq
[   35.342389] Disabling IRQ #156

ohci_shutdown() disables all the interrupt and rh_state is set to
OHCI_RH_HALTED. In other hand, ohci_irq() is possible to enable
OHCI_INTR_SF and OHCI_INTR_MIE on ohci_irq(). Note that OHCI_INTR_SF
is possible to be set by start_ed_unlink() which is called:
 ohci_irq()
  -> process_done_list()
   -> takeback_td()
    -> start_ed_unlink()

So, ohci_irq() has the following condition, the issue happens by
&ohci->regs->intrenable = OHCI_INTR_MIE | OHCI_INTR_SF and
ohci->rh_state = OHCI_RH_HALTED:

        /* interrupt for some other device? */
        if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED))
                return IRQ_NOTMINE;

To fix the issue, ohci_shutdown() holds the spin lock while disabling
the interruption and changing the rh_state flag to prevent reenable
the OHCI_INTR_MIE unexpectedly. Note that io_watchdog_func() also
calls the ohci_shutdown() and it already held the spin lock, so that
the patch makes a new function as _ohci_shutdown().

This patch is inspired by a Renesas R-Car Gen3 BSP patch
from Tho Vu.

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/1566877910-6020-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 7af7737 (patch).

usb: chipidea: udc: don’t do hardware access if gadget has stopped

This change “usb: chipidea: udc: don’t do hardware access if gadget has stopped” (commit a209827) in Linux kernel is authored by Peter Chen <peter.chen [at] nxp.com> on Tue Aug 20 02:07:58 2019 +0000.

The change “usb: chipidea: udc: don’t do hardware access if gadget has stopped” introduces changes as follows.

usb: chipidea: udc: don't do hardware access if gadget has stopped

commit cbe85c88ce80fb92956a0793518d415864dcead8 upstream.

After _gadget_stop_activity is executed, we can consider the hardware
operation for gadget has finished, and the udc can be stopped and enter
low power mode. So, any later hardware operations (from usb_ep_ops APIs
or usb_gadget_ops APIs) should be considered invalid, any deinitializatons
has been covered at _gadget_stop_activity.

I meet this problem when I plug out usb cable from PC using mass_storage
gadget, my callstack like: vbus interrupt->.vbus_session->
composite_disconnect ->pm_runtime_put_sync(&_gadget->dev),
the composite_disconnect will call fsg_disable, but fsg_disable calls
usb_ep_disable using async way, there are register accesses for
usb_ep_disable. So sometimes, I get system hang due to visit register
without clock, sometimes not.

The Linux Kernel USB maintainer Alan Stern suggests this kinds of solution.
See: http://marc.info/?l=linux-usb&m=138541769810983&w=2.

Cc: <stable@vger.kernel.org> #v4.9+
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20190820020503.27080-2-peter.chen@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is a209827 (patch).

usb: hcd: use managed device resources

This change “usb: hcd: use managed device resources” (commit 97bec7a) in Linux kernel is authored by Schmid, Carsten <Carsten_Schmid [at] mentor.com> on Fri Aug 23 14:11:28 2019 +0000.

The change “usb: hcd: use managed device resources” introduces changes as follows.

usb: hcd: use managed device resources

commit 76da906ad727048a74bb8067031ee99fc070c7da upstream.

Using managed device resources in usb_hcd_pci_probe() allows devm usage for
resource subranges, such as the mmio resource for the platform device
created to control host/device mode mux, which is a xhci extended
capability, and sits inside the xhci mmio region.

If managed device resources are not used then "parent" resource
is released before subrange at driver removal as .remove callback is
called before the devres list of resources for this device is walked
and released.

This has been observed with the xhci extended capability driver causing a
use-after-free which is now fixed.

An additional nice benefit is that error handling on driver initialisation
is simplified much.

Signed-off-by: Carsten Schmid <carsten_schmid@mentor.com>
Tested-by: Carsten Schmid <carsten_schmid@mentor.com>
Reviewed-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Fixes: fa31b3cb2ae1 ("xhci: Add Intel extended cap / otg phy mux handling")
Cc: <stable@vger.kernel.org> # v4.19+
Link: https://lore.kernel.org/r/1566569488679.31808@mentor.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 97bec7a (patch).

USB: cdc-wdm: fix race between write and disconnect due to flag abuse

This change “USB: cdc-wdm: fix race between write and disconnect due to flag abuse” (commit ebad9fd) in Linux kernel is authored by Oliver Neukum <oneukum [at] suse.com> on Tue Aug 27 12:34:36 2019 +0200.

The change “USB: cdc-wdm: fix race between write and disconnect due to flag abuse” introduces changes as follows.

USB: cdc-wdm: fix race between write and disconnect due to flag abuse

commit 1426bd2c9f7e3126e2678e7469dca9fd9fc6dd3e upstream.

In case of a disconnect an ongoing flush() has to be made fail.
Nevertheless we cannot be sure that any pending URB has already
finished, so although they will never succeed, they still must
not be touched.
The clean solution for this is to check for WDM_IN_USE
and WDM_DISCONNECTED in flush(). There is no point in ever
clearing WDM_IN_USE, as no further writes make sense.

The issue is as old as the driver.

Fixes: afba937e540c9 ("USB: CDC WDM driver")
Reported-by: syzbot+d232cca6ec42c2edb3fc@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827103436.21143-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is ebad9fd (patch).

usb-storage: Add new JMS567 revision to unusual_devs

This change “usb-storage: Add new JMS567 revision to unusual_devs” (commit cbf5a27) in Linux kernel is authored by Henk van der Laan <opensource [at] henkvdlaan.com> on Fri Aug 16 22:08:47 2019 +0200.

The change “usb-storage: Add new JMS567 revision to unusual_devs” introduces changes as follows.

usb-storage: Add new JMS567 revision to unusual_devs

commit 08d676d1685c2a29e4d0e1b0242324e564d4589e upstream.

Revision 0x0117 suffers from an identical issue to earlier revisions,
therefore it should be added to the quirks list.

Signed-off-by: Henk van der Laan <opensource@henkvdlaan.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190816200847.21366-1-opensource@henkvdlaan.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is cbf5a27 (patch).

ftrace: Check for empty hash and comment the race with registering probes

This change “ftrace: Check for empty hash and comment the race with registering probes” (commit 8ea6395) in Linux kernel is authored by Steven Rostedt (VMware) <rostedt [at] goodmis.org> on Fri Aug 30 16:30:01 2019 -0400.

The change “ftrace: Check for empty hash and comment the race with registering probes” introduces changes as follows.

ftrace: Check for empty hash and comment the race with registering probes

commit 372e0d01da71c84dcecf7028598a33813b0d5256 upstream.

The race between adding a function probe and reading the probes that exist
is very subtle. It needs a comment. Also, the issue can also happen if the
probe has has the EMPTY_HASH as its func_hash.

Cc: stable@vger.kernel.org
Fixes: 7b60f3d876156 ("ftrace: Dynamically create the probe ftrace_ops for the trace_array")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 8ea6395 (patch).

ftrace: Check for successful allocation of hash

This change “ftrace: Check for successful allocation of hash” (commit 9d98e0f) in Linux kernel is authored by Naveen N. Rao <naveen.n.rao [at] linux.vnet.ibm.com> on Thu Jul 4 20:04:42 2019 +0530.

The change “ftrace: Check for successful allocation of hash” introduces changes as follows.

ftrace: Check for successful allocation of hash

commit 5b0022dd32b7c2e15edf1827ba80aa1407edf9ff upstream.

In register_ftrace_function_probe(), we are not checking the return
value of alloc_and_copy_ftrace_hash(). The subsequent call to
ftrace_match_records() may end up dereferencing the same. Add a check to
ensure this doesn't happen.

Link: http://lkml.kernel.org/r/26e92574f25ad23e7cafa3cf5f7a819de1832cbe.1562249521.git.naveen.n.rao@linux.vnet.ibm.com

Cc: stable@vger.kernel.org
Fixes: 1ec3a81a0cf42 ("ftrace: Have each function probe use its own ftrace_ops")
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 9d98e0f (patch).

ftrace: Fix NULL pointer dereference in t_probe_next()

This change “ftrace: Fix NULL pointer dereference in t_probe_next()” (commit f184b16) in Linux kernel is authored by Naveen N. Rao <naveen.n.rao [at] linux.vnet.ibm.com> on Thu Jul 4 20:04:41 2019 +0530.

The change “ftrace: Fix NULL pointer dereference in t_probe_next()” introduces changes as follows.

ftrace: Fix NULL pointer dereference in t_probe_next()

commit 7bd46644ea0f6021dc396a39a8bfd3a58f6f1f9f upstream.

LTP testsuite on powerpc results in the below crash:

  Unable to handle kernel paging request for data at address 0x00000000
  Faulting instruction address: 0xc00000000029d800
  Oops: Kernel access of bad area, sig: 11 [#1]
  LE SMP NR_CPUS=2048 NUMA PowerNV
  ...
  CPU: 68 PID: 96584 Comm: cat Kdump: loaded Tainted: G        W
  NIP:  c00000000029d800 LR: c00000000029dac4 CTR: c0000000001e6ad0
  REGS: c0002017fae8ba10 TRAP: 0300   Tainted: G        W
  MSR:  9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 28022422  XER: 20040000
  CFAR: c00000000029d90c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
  ...
  NIP [c00000000029d800] t_probe_next+0x60/0x180
  LR [c00000000029dac4] t_mod_start+0x1a4/0x1f0
  Call Trace:
  [c0002017fae8bc90] [c000000000cdbc40] _cond_resched+0x10/0xb0 (unreliable)
  [c0002017fae8bce0] [c0000000002a15b0] t_start+0xf0/0x1c0
  [c0002017fae8bd30] [c0000000004ec2b4] seq_read+0x184/0x640
  [c0002017fae8bdd0] [c0000000004a57bc] sys_read+0x10c/0x300
  [c0002017fae8be30] [c00000000000b388] system_call+0x5c/0x70

The test (ftrace_set_ftrace_filter.sh) is part of ftrace stress tests
and the crash happens when the test does 'cat
$TRACING_PATH/set_ftrace_filter'.

The address points to the second line below, in t_probe_next(), where
filter_hash is dereferenced:
  hash = iter->probe->ops.func_hash->filter_hash;
  size = 1 << hash->size_bits;

This happens due to a race with register_ftrace_function_probe(). A new
ftrace_func_probe is created and added into the func_probes list in
trace_array under ftrace_lock. However, before initializing the filter,
we drop ftrace_lock, and re-acquire it after acquiring regex_lock. If
another process is trying to read set_ftrace_filter, it will be able to
acquire ftrace_lock during this window and it will end up seeing a NULL
filter_hash.

Fix this by just checking for a NULL filter_hash in t_probe_next(). If
the filter_hash is NULL, then this probe is just being added and we can
simply return from here.

Link: http://lkml.kernel.org/r/05e021f757625cbbb006fad41380323dbe4e3b43.1562249521.git.naveen.n.rao@linux.vnet.ibm.com

Cc: stable@vger.kernel.org
Fixes: 7b60f3d876156 ("ftrace: Dynamically create the probe ftrace_ops for the trace_array")
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is f184b16 (patch).

x86/apic: Include the LDR when clearing out APIC registers

This change “x86/apic: Include the LDR when clearing out APIC registers” (commit edc454c) in Linux kernel is authored by Bandan Das <bsd [at] redhat.com> on Mon Aug 26 06:15:13 2019 -0400.

The change “x86/apic: Include the LDR when clearing out APIC registers” introduces changes as follows.

x86/apic: Include the LDR when clearing out APIC registers

commit 558682b5291937a70748d36fd9ba757fb25b99ae upstream.

Although APIC initialization will typically clear out the LDR before
setting it, the APIC cleanup code should reset the LDR.

This was discovered with a 32-bit KVM guest jumping into a kdump
kernel. The stale bits in the LDR triggered a bug in the KVM APIC
implementation which caused the destination mapping for VCPUs to be
corrupted.

Note that this isn't intended to paper over the KVM APIC bug. The kernel
has to clear the LDR when resetting the APIC registers except when X2APIC
is enabled.

This lacks a Fixes tag because missing to clear LDR goes way back into pre
git history.

[ tglx: Made x2apic_enabled a function call as required ]

Signed-off-by: Bandan Das <bsd@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190826101513.5080-3-bsd@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is edc454c (patch).

x86/apic: Do not initialize LDR and DFR for bigsmp

This change “x86/apic: Do not initialize LDR and DFR for bigsmp” (commit 9598326) in Linux kernel is authored by Bandan Das <bsd [at] redhat.com> on Mon Aug 26 06:15:12 2019 -0400.

The change “x86/apic: Do not initialize LDR and DFR for bigsmp” introduces changes as follows.

x86/apic: Do not initialize LDR and DFR for bigsmp

commit bae3a8d3308ee69a7dbdf145911b18dfda8ade0d upstream.

Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The
bigsmp APIC implementation uses physical destination mode, but it
nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with
multiple bit being set.

This does not cause a functional problem because LDR and DFR are ignored
when physical destination mode is active, but it triggered a problem on a
32-bit KVM guest which jumps into a kdump kernel.

The multiple bits set unearthed a bug in the KVM APIC implementation. The
code which creates the logical destination map for VCPUs ignores the
disabled state of the APIC and ends up overwriting an existing valid entry
and as a result, APIC calibration hangs in the guest during kdump
initialization.

Remove the bogus LDR/DFR initialization.

This is not intended to work around the KVM APIC bug. The LDR/DFR
ininitalization is wrong on its own.

The issue goes back into the pre git history. The fixes tag is the commit
in the bitkeeper import which introduced bigsmp support in 2003.

  git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

Fixes: db7b9e9f26b8 ("[PATCH] Clustered APIC setup for >8 CPU systems")
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Bandan Das <bsd@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190826101513.5080-2-bsd@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 9598326 (patch).

uprobes/x86: Fix detection of 32-bit user mode

This change “uprobes/x86: Fix detection of 32-bit user mode” (commit 941d875) in Linux kernel is authored by Sebastian Mayr <me [at] sam.st> on Sun Jul 28 17:26:17 2019 +0200.

The change “uprobes/x86: Fix detection of 32-bit user mode” introduces changes as follows.

uprobes/x86: Fix detection of 32-bit user mode

commit 9212ec7d8357ea630031e89d0d399c761421c83b upstream.

32-bit processes running on a 64-bit kernel are not always detected
correctly, causing the process to crash when uretprobes are installed.

The reason for the crash is that in_ia32_syscall() is used to determine the
process's mode, which only works correctly when called from a syscall.

In the case of uretprobes, however, the function is called from a exception
and always returns 'false' on a 64-bit kernel. In consequence this leads to
corruption of the process's return address.

Fix this by using user_64bit_mode() instead of in_ia32_syscall(), which
is correct in any situation.

[ tglx: Add a comment and the following historical info ]

This should have been detected by the rename which happened in commit

  abfb9498ee13 ("x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()")

which states in the changelog:

    The is_ia32_task()/is_x32_task() function names are a big misnomer: they
    suggests that the compat-ness of a system call is a task property, which
    is not true, the compatness of a system call purely depends on how it
    was invoked through the system call layer.
    .....

and then it went and blindly renamed every call site.

Sadly enough this was already mentioned here:

   8faaed1b9f50 ("uprobes/x86: Introduce sizeof_long(), cleanup adjust_ret_addr() and
arch_uretprobe_hijack_return_addr()")

where the changelog says:

    TODO: is_ia32_task() is not what we actually want, TS_COMPAT does
    not necessarily mean 32bit. Fortunately syscall-like insns can't be
    probed so it actually works, but it would be better to rename and
    use is_ia32_frame().

and goes all the way back to:

    0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")

Oh well. 7+ years until someone actually tried a uretprobe on a 32bit
process on a 64bit kernel....

Fixes: 0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
Signed-off-by: Sebastian Mayr <me@sam.st>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190728152617.7308-1-me@sam.st
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 941d875 (patch).

KVM: x86: Don’t update RIP or do single-step on faulting emulation

This change “KVM: x86: Don’t update RIP or do single-step on faulting emulation” (commit 3c2b482) in Linux kernel is authored by Sean Christopherson <sean.j.christopherson [at] intel.com> on Fri Aug 23 13:55:44 2019 -0700.

The change “KVM: x86: Don’t update RIP or do single-step on faulting emulation” introduces changes as follows.

KVM: x86: Don't update RIP or do single-step on faulting emulation

commit 75ee23b30dc712d80d2421a9a547e7ab6e379b44 upstream.

Don't advance RIP or inject a single-step #DB if emulation signals a
fault.  This logic applies to all state updates that are conditional on
clean retirement of the emulation instruction, e.g. updating RFLAGS was
previously handled by commit 38827dbd3fb85 ("KVM: x86: Do not update
EFLAGS on faulting emulation").

Not advancing RIP is likely a nop, i.e. ctxt->eip isn't updated with
ctxt->_eip until emulation "retires" anyways.  Skipping #DB injection
fixes a bug reported by Andy Lutomirski where a #UD on SYSCALL due to
invalid state with EFLAGS.TF=1 would loop indefinitely due to emulation
overwriting the #UD with #DB and thus restarting the bad SYSCALL over
and over.

Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: stable@vger.kernel.org
Reported-by: Andy Lutomirski <luto@kernel.org>
Fixes: 663f4c61b803 ("KVM: x86: handle singlestep during emulation")
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 3c2b482 (patch).

kvm: x86: skip populating logical dest map if apic is not sw enabled

This change “kvm: x86: skip populating logical dest map if apic is not sw enabled” (commit 3ec3510) in Linux kernel is authored by Radim Krcmar <rkrcmar [at] redhat.com> on Tue Aug 13 23:37:37 2019 -0400.

The change “kvm: x86: skip populating logical dest map if apic is not sw enabled” introduces changes as follows.

kvm: x86: skip populating logical dest map if apic is not sw enabled

commit b14c876b994f208b6b95c222056e1deb0a45de0e upstream.

recalculate_apic_map does not santize ldr and it's possible that
multiple bits are set. In that case, a previous valid entry
can potentially be overwritten by an invalid one.

This condition is hit when booting a 32 bit, >8 CPU, RHEL6 guest and then
triggering a crash to boot a kdump kernel. This is the sequence of
events:
1. Linux boots in bigsmp mode and enables PhysFlat, however, it still
writes to the LDR which probably will never be used.
2. However, when booting into kdump, the stale LDR values remain as
they are not cleared by the guest and there isn't a apic reset.
3. kdump boots with 1 cpu, and uses Logical Destination Mode but the
logical map has been overwritten and points to an inactive vcpu.

Signed-off-by: Radim Krcmar <rkrcmar@redhat.com>
Signed-off-by: Bandan Das <bsd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 3ec3510 (patch).

ALSA: usb-audio: Add implicit fb quirk for Behringer UFX1604

This change “ALSA: usb-audio: Add implicit fb quirk for Behringer UFX1604” (commit cbd905d) in Linux kernel is authored by Takashi Iwai <tiwai [at] suse.de> on Tue Aug 20 08:58:12 2019 +0200.

The change “ALSA: usb-audio: Add implicit fb quirk for Behringer UFX1604” introduces changes as follows.

ALSA: usb-audio: Add implicit fb quirk for Behringer UFX1604

commit 1a15718b41df026cffd0e42cfdc38a1384ce19f9 upstream.

Behringer UFX1604 requires the similar quirk to apply implicit fb like
another Behringer model UFX1204 in order to fix the noisy playback.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204631
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is cbd905d (patch).

ALSA: usb-audio: Fix invalid NULL check in snd_emuusb_set_samplerate()

This change “ALSA: usb-audio: Fix invalid NULL check in snd_emuusb_set_samplerate()” (commit b5d1f31) in Linux kernel is authored by Takashi Iwai <tiwai [at] suse.de> on Thu Aug 15 11:41:06 2019 +0200.

The change “ALSA: usb-audio: Fix invalid NULL check in snd_emuusb_set_samplerate()” introduces changes as follows.

ALSA: usb-audio: Fix invalid NULL check in snd_emuusb_set_samplerate()

commit 6de3c9e3f6b3eaf66859e1379b3f35dda781416b upstream.

The quirk function snd_emuusb_set_samplerate() has a NULL check for
the mixer element, but this is useless in the current code.  It used
to be a check against mixer->id_elems[unitid] but it was changed later
to the value after mixer_eleme_list_to_info() which is always non-NULL
due to the container_of() usage.

This patch fixes the check before the conversion.

While we're at it, correct a typo in the comment in the function,
too.

Fixes: 8c558076c740 ("ALSA: usb-audio: Clean up mixer element list traverse")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is b5d1f31 (patch).

ALSA: seq: Fix potential concurrent access to the deleted pool

This change “ALSA: seq: Fix potential concurrent access to the deleted pool” (commit 98a2017) in Linux kernel is authored by Takashi Iwai <tiwai [at] suse.de> on Sun Aug 25 09:21:44 2019 +0200.

The change “ALSA: seq: Fix potential concurrent access to the deleted pool” introduces changes as follows.

ALSA: seq: Fix potential concurrent access to the deleted pool

commit 75545304eba6a3d282f923b96a466dc25a81e359 upstream.

The input pool of a client might be deleted via the resize ioctl, the
the access to it should be covered by the proper locks.  Currently the
only missing place is the call in snd_seq_ioctl_get_client_pool(), and
this patch papers over it.

Reported-by: syzbot+4a75454b9ca2777f35c7@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 98a2017 (patch).

ALSA: hda – Fixes inverted Conexant GPIO mic mute led

This change “ALSA: hda – Fixes inverted Conexant GPIO mic mute led” (commit 842317d) in Linux kernel is authored by Jeronimo Borque <jeronimo [at] borque.com.ar> on Sun Aug 18 22:35:38 2019 -0300.

The change “ALSA: hda – Fixes inverted Conexant GPIO mic mute led” introduces changes as follows.

ALSA: hda - Fixes inverted Conexant GPIO mic mute led

commit f9ef724d4896763479f3921afd1ee61552fc9836 upstream.

"enabled" parameter historically referred to the device input or
output, not to the led indicator. After the changes added with the led
helper functions the mic mute led logic refers to the led and not to
the mic input which caused led indicator to be negated.
Fixing logic in cxt_update_gpio_led and updated
cxt_fixup_gpio_mute_hook
Also updated debug messages to ease further debugging if necessary.

Fixes: 184e302b46c9 ("ALSA: hda/conexant - Use the mic-mute LED helper")
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jeronimo Borque <jeronimo@borque.com.ar>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 842317d (patch).

ALSA: line6: Fix memory leak at line6_init_pcm() error path

This change “ALSA: line6: Fix memory leak at line6_init_pcm() error path” (commit 5ef43bd) in Linux kernel is authored by Takashi Iwai <tiwai [at] suse.de> on Wed Aug 21 20:00:02 2019 +0200.

The change “ALSA: line6: Fix memory leak at line6_init_pcm() error path” introduces changes as follows.

ALSA: line6: Fix memory leak at line6_init_pcm() error path

commit 1bc8d18c75fef3b478dbdfef722aae09e2a9fde7 upstream.

I forgot to release the allocated object at the early error path in
line6_init_pcm().  For addressing it, slightly shuffle the code so
that the PCM destructor (pcm->private_free) is assigned properly
before all error paths.

Fixes: 3450121997ce ("ALSA: line6: Fix write on zero-sized buffer")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 5ef43bd (patch).

ALSA: usb-audio: Check mixer unit bitmap yet more strictly

This change “ALSA: usb-audio: Check mixer unit bitmap yet more strictly” (commit c94c0bf) in Linux kernel is authored by Takashi Iwai <tiwai [at] suse.de> on Tue Aug 20 21:43:42 2019 +0200.

The change “ALSA: usb-audio: Check mixer unit bitmap yet more strictly” introduces changes as follows.

ALSA: usb-audio: Check mixer unit bitmap yet more strictly

commit f9f0e9ed350e15d51ad07364b4cf910de50c472a upstream.

The bmControls (for UAC1) or bmMixerControls (for UAC2/3) bitmap has a
variable size depending on both input and output pins.  Its size is to
fit with input * output bits.  The problem is that the input size
can't be determined simply from the unit descriptor itself but it
needs to parse the whole connected sources.  Although the
uac_mixer_unit_get_channels() tries to check some possible overflow of
this bitmap, it's incomplete due to the lack of the  evaluation of
input pins.

For covering possible overflows, this patch adds the bitmap overflow
check in the loop of input pins in parse_audio_mixer_unit().

Fixes: 0bfe5e434e66 ("ALSA: usb-audio: Check mixer unit descriptors more strictly")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is c94c0bf (patch).

mm/zsmalloc.c: fix build when CONFIG_COMPACTION=n

This change “mm/zsmalloc.c: fix build when CONFIG_COMPACTION=n” (commit 5dd2db1) in Linux kernel is authored by Andrew Morton <akpm [at] linux-foundation.org> on Fri Aug 30 16:04:35 2019 -0700.

The change “mm/zsmalloc.c: fix build when CONFIG_COMPACTION=n” introduces changes as follows.

mm/zsmalloc.c: fix build when CONFIG_COMPACTION=n

commit 441e254cd40dc03beec3c650ce6ce6074bc6517f upstream.

Fixes: 701d678599d0c1 ("mm/zsmalloc.c: fix race condition in zs_destroy_pool")
Link: http://lkml.kernel.org/r/201908251039.5oSbEEUT%25lkp@intel.com
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Henry Burns <henrywolfeburns@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Jonathan Adams <jwadams@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 5dd2db1 (patch).

ipv4/icmp: fix rt dst dev null pointer dereference

This change “ipv4/icmp: fix rt dst dev null pointer dereference” (commit 9febfd3) in Linux kernel is authored by Hangbin Liu <liuhangbin [at] gmail.com> on Thu Aug 22 22:19:48 2019 +0800.

The change “ipv4/icmp: fix rt dst dev null pointer dereference” introduces changes as follows.

ipv4/icmp: fix rt dst dev null pointer dereference

[ Upstream commit e2c693934194fd3b4e795635934883354c06ebc9 ]

In __icmp_send() there is a possibility that the rt->dst.dev is NULL,
e,g, with tunnel collect_md mode, which will cause kernel crash.
Here is what the code path looks like, for GRE:

- ip6gre_tunnel_xmit
  - ip6gre_xmit_ipv4
    - __gre6_xmit
      - ip6_tnl_xmit
        - if skb->len - t->tun_hlen - eth_hlen > mtu; return -EMSGSIZE
    - icmp_send
      - net = dev_net(rt->dst.dev); <-- here

The reason is __metadata_dst_init() init dst->dev to NULL by default.
We could not fix it in __metadata_dst_init() as there is no dev supplied.
On the other hand, the reason we need rt->dst.dev is to get the net.
So we can just try get it from skb->dev when rt->dst.dev is NULL.

v4: Julian Anastasov remind skb->dev also could be NULL. We'd better
still use dst.dev and do a check to avoid crash.

v3: No changes.

v2: fix the issue in __icmp_send() instead of updating shared dst dev
in {ip_md, ip6}_tunnel_xmit.

Fixes: c8b34e680a09 ("ip_tunnel: Add tnl_update_pmtu in ip_md_tunnel_xmit")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 9febfd3 (patch).

tcp: make sure EPOLLOUT wont be missed

This change “tcp: make sure EPOLLOUT wont be missed” (commit 0a6a9c4) in Linux kernel is authored by Eric Dumazet <edumazet [at] google.com> on Fri Aug 16 21:26:22 2019 -0700.

The change “tcp: make sure EPOLLOUT wont be missed” introduces changes as follows.

tcp: make sure EPOLLOUT wont be missed

[ Upstream commit ef8d8ccdc216f797e66cb4a1372f5c4c285ce1e4 ]

As Jason Baron explained in commit 790ba4566c1a ("tcp: set SOCK_NOSPACE
under memory pressure"), it is crucial we properly set SOCK_NOSPACE
when needed.

However, Jason patch had a bug, because the 'nonblocking' status
as far as sk_stream_wait_memory() is concerned is governed
by MSG_DONTWAIT flag passed at sendmsg() time :

    long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);

So it is very possible that tcp sendmsg() calls sk_stream_wait_memory(),
and that sk_stream_wait_memory() returns -EAGAIN with SOCK_NOSPACE
cleared, if sk->sk_sndtimeo has been set to a small (but not zero)
value.

This patch removes the 'noblock' variable since we must always
set SOCK_NOSPACE if -EAGAIN is returned.

It also renames the do_nonblock label since we might reach this
code path even if we were in blocking mode.

Fixes: 790ba4566c1a ("tcp: set SOCK_NOSPACE under memory pressure")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jason Baron <jbaron@akamai.com>
Reported-by: Vladimir Rutsky  <rutsky@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 0a6a9c4 (patch).

net/smc: make sure EPOLLOUT is raised

This change “net/smc: make sure EPOLLOUT is raised” (commit 3e79bd1) in Linux kernel is authored by Jason Baron <jbaron [at] akamai.com> on Mon Aug 19 14:36:01 2019 -0400.

The change “net/smc: make sure EPOLLOUT is raised” introduces changes as follows.

net/smc: make sure EPOLLOUT is raised

[ Upstream commit 4651d1802f7063e4d8c0bcad957f46ece0c04024 ]

Currently, we are only explicitly setting SOCK_NOSPACE on a write timeout
for non-blocking sockets. Epoll() edge-trigger mode relies on SOCK_NOSPACE
being set when -EAGAIN is returned to ensure that EPOLLOUT is raised.
Expand the setting of SOCK_NOSPACE to non-blocking sockets as well that can
use SO_SNDTIMEO to adjust their write timeout. This mirrors the behavior
that Eric Dumazet introduced for tcp sockets.

Signed-off-by: Jason Baron <jbaron@akamai.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Ursula Braun <ubraun@linux.ibm.com>
Cc: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 3e79bd1 (patch).

ipv6: Default fib6_type to RTN_UNICAST when not set

This change “ipv6: Default fib6_type to RTN_UNICAST when not set” (commit ff12983) in Linux kernel is authored by David Ahern <dsahern [at] gmail.com> on Wed Jun 19 10:50:24 2019 -0700.

The change “ipv6: Default fib6_type to RTN_UNICAST when not set” introduces changes as follows.

ipv6: Default fib6_type to RTN_UNICAST when not set

[ Upstream commit c7036d97acd2527cef145b5ef9ad1a37ed21bbe6 ]

A user reported that routes are getting installed with type 0 (RTN_UNSPEC)
where before the routes were RTN_UNICAST. One example is from accel-ppp
which apparently still uses the ioctl interface and does not set
rtmsg_type. Another is the netlink interface where ipv6 does not require
rtm_type to be set (v4 does). Prior to the commit in the Fixes tag the
ipv6 stack converted type 0 to RTN_UNICAST, so restore that behavior.

Fixes: e8478e80e5a7 ("net/ipv6: Save route type in rt6_info")
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is ff12983 (patch).

ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set

This change “ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set” (commit 02127bd) in Linux kernel is authored by Hangbin Liu <liuhangbin [at] gmail.com> on Tue Aug 20 10:19:47 2019 +0800.

The change “ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set” introduces changes as follows.

ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set

[ Upstream commit f17f7648a49aa6728649ddf79bdbcac4f1970ce4 ]

In commit 93a714d6b53d ("multicast: Extend ip address command to enable
multicast group join/leave on") we added a new flag IFA_F_MCAUTOJOIN
to make user able to add multicast address on ethernet interface.

This works for IPv4, but not for IPv6. See the inet6_addr_add code.

static int inet6_addr_add()
{
        ...
        if (cfg->ifa_flags & IFA_F_MCAUTOJOIN) {
                ipv6_mc_config(net->ipv6.mc_autojoin_sk, true...)
        }

        ifp = ipv6_add_addr(idev, cfg, true, extack); <- always fail with maddr
        if (!IS_ERR(ifp)) {
                ...
        } else if (cfg->ifa_flags & IFA_F_MCAUTOJOIN) {
                ipv6_mc_config(net->ipv6.mc_autojoin_sk, false...)
        }
}

But in ipv6_add_addr() it will check the address type and reject multicast
address directly. So this feature is never worked for IPv6.

We should not remove the multicast address check totally in ipv6_add_addr(),
but could accept multicast address only when IFA_F_MCAUTOJOIN flag supplied.

v2: update commit description

Fixes: 93a714d6b53d ("multicast: Extend ip address command to enable multicast group join/leave on")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is 02127bd (patch).

net: tls, fix sk_write_space NULL write when tx disabled

This change “net: tls, fix sk_write_space NULL write when tx disabled” (commit a1407b2) in Linux kernel is authored by John Fastabend <john.fastabend [at] gmail.com> on Wed Aug 14 05:31:54 2019 +0000.

The change “net: tls, fix sk_write_space NULL write when tx disabled” introduces changes as follows.

net: tls, fix sk_write_space NULL write when tx disabled

[ Upstream commit d85f01775850a35eae47a0090839baf510c1ef12 ]

The ctx->sk_write_space pointer is only set when TLS tx mode is enabled.
When running without TX mode its a null pointer but we still set the
sk sk_write_space pointer on close().

Fix the close path to only overwrite sk->sk_write_space when the current
pointer is to the tls_write_space function indicating the tls module should
clean it up properly as well.

Reported-by: Hillf Danton <hdanton@sina.com>
Cc: Ying Xue <ying.xue@windriver.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Fixes: 57c722e932cfb ("net/tls: swap sk_write_space on close")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is a1407b2 (patch).

net/tls: swap sk_write_space on close

This change “net/tls: swap sk_write_space on close” (commit fdc4400) in Linux kernel is authored by Jakub Kicinski <jakub.kicinski [at] netronome.com> on Fri Aug 9 18:36:23 2019 -0700.

The change “net/tls: swap sk_write_space on close” introduces changes as follows.

net/tls: swap sk_write_space on close

[ Upstream commit 57c722e932cfb82e9820bbaae1b1f7222ea97b52 ]

Now that we swap the original proto and clear the ULP pointer
on close we have to make sure no callback will try to access
the freed state. sk_write_space is not part of sk_prot, remember
to swap it.

Reported-by: syzbot+dcdc9deefaec44785f32@syzkaller.appspotmail.com
Fixes: 95fa145479fb ("bpf: sockmap/tls, close can race with map free")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is fdc4400 (patch).

net/tls: Fixed return value when tls_complete_pending_work() fails

This change “net/tls: Fixed return value when tls_complete_pending_work() fails” (commit f7009bb) in Linux kernel is authored by Vakul Garg <vakul.garg [at] nxp.com> on Mon Sep 10 22:53:46 2018 +0530.

The change “net/tls: Fixed return value when tls_complete_pending_work() fails” introduces changes as follows.

net/tls: Fixed return value when tls_complete_pending_work() fails

[ Upstream commit 150085791afb8054e11d2e080d4b9cd755dd7f69 ]

In tls_sw_sendmsg() and tls_sw_sendpage(), the variable 'ret' has
been set to return value of tls_complete_pending_work(). This allows
return of proper error code if tls_complete_pending_work() fails.

Fixes: 3c4d7559159b ("tls: kernel TLS support")
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit for this change in Linux stable tree is f7009bb (patch).

drm/tilcdc: Register cpufreq notifier after we have initialized crtc

This change “drm/tilcdc: Register cpufreq notifier after we have initialized crtc” (commit dc066fd) in Linux kernel is authored by Jyri Sarha <jsarha [at] ti.com> on Wed Dec 12 19:26:32 2018 +0200.

The change “drm/tilcdc: Register cpufreq notifier after we have initialized crtc” introduces changes as follows.

drm/tilcdc: Register cpufreq notifier after we have initialized crtc

[ Upstream commit 432973fd3a20102840d5f7e61af9f1a03c217a4c ]

Register cpufreq notifier after we have initialized the crtc and
unregister it before we remove the ctrc. Receiving a cpufreq notify
without crtc causes a crash.

Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is dc066fd (patch).

scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value

This change “scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value” (commit eba86f0) in Linux kernel is authored by Pedro Sousa <sousa [at] synopsys.com> on Thu Apr 18 21:13:34 2019 +0200.

The change “scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value” introduces changes as follows.

scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value

[ Upstream commit ebcb8f8508c5edf428f52525cec74d28edea7bcb ]

Fix RX_TERMINATION_FORCE_ENABLE define value from 0x0089 to 0x00A9
according to MIPI Alliance MPHY specification.

Fixes: e785060ea3a1 ("ufs: definitions for phy interface")
Signed-off-by: Pedro Sousa <sousa@synopsys.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is eba86f0 (patch).

drm/bridge: tfp410: fix memleak in get_modes()

This change “drm/bridge: tfp410: fix memleak in get_modes()” (commit edd40f5) in Linux kernel is authored by Tomi Valkeinen <tomi.valkeinen [at] ti.com> on Mon Jun 10 16:57:38 2019 +0300.

The change “drm/bridge: tfp410: fix memleak in get_modes()” introduces changes as follows.

drm/bridge: tfp410: fix memleak in get_modes()

[ Upstream commit c08f99c39083ab55a9c93b3e93cef48711294dad ]

We don't free the edid blob allocated by the call to drm_get_edid(),
causing a memleak. Fix this by calling kfree(edid) at the end of the
get_modes().

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190610135739.6077-1-tomi.valkeinen@ti.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is edd40f5 (patch).

watchdog: bcm2835_wdt: Fix module autoload

This change “watchdog: bcm2835_wdt: Fix module autoload” (commit 2fa7c94) in Linux kernel is authored by Stefan Wahren <wahrenst [at] gmx.net> on Wed May 15 19:14:18 2019 +0200.

The change “watchdog: bcm2835_wdt: Fix module autoload” introduces changes as follows.

watchdog: bcm2835_wdt: Fix module autoload

[ Upstream commit 215e06f0d18d5d653d6ea269e4dfc684854d48bf ]

The commit 5e6acc3e678e ("bcm2835-pm: Move bcm2835-watchdog's DT probe
to an MFD.") broke module autoloading on Raspberry Pi. So add a
module alias this fix this.

Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 2fa7c94 (patch).

drm/i915: fix broadwell EU computation

This change “drm/i915: fix broadwell EU computation” (commit a3eb2eb) in Linux kernel is authored by Lionel Landwerlin <lionel.g.landwerlin [at] intel.com> on Mon Nov 12 12:39:31 2018 +0000.

The change “drm/i915: fix broadwell EU computation” introduces changes as follows.

drm/i915: fix broadwell EU computation

[ Upstream commit 63ac3328f0d1d37f286e397b14d9596ed09d7ca5 ]

subslice_mask is an array indexed by slice, not subslice.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 8cc7669355136f ("drm/i915: store all subslice masks")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108712
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112123931.2815-1-lionel.g.landwerlin@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is a3eb2eb (patch).

tools: hv: fix KVP and VSS daemons exit code

This change “tools: hv: fix KVP and VSS daemons exit code” (commit c61c724) in Linux kernel is authored by Adrian Vladu <avladu [at] cloudbasesolutions.com> on Mon May 6 16:50:58 2019 +0000.

The change “tools: hv: fix KVP and VSS daemons exit code” introduces changes as follows.

tools: hv: fix KVP and VSS daemons exit code

[ Upstream commit b0995156071b0ff29a5902964a9dc8cfad6f81c0 ]

HyperV KVP and VSS daemons should exit with 0 when the '--help'
or '-h' flags are used.

Signed-off-by: Adrian Vladu <avladu@cloudbasesolutions.com>

Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Alessandro Pilotti <apilotti@cloudbasesolutions.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is c61c724 (patch).

tools: hv: fixed Python pep8/flake8 warnings for lsvmbus

This change “tools: hv: fixed Python pep8/flake8 warnings for lsvmbus” (commit 0c39d81) in Linux kernel is authored by Adrian Vladu <avladu [at] cloudbasesolutions.com> on Mon May 6 17:27:37 2019 +0000.

The change “tools: hv: fixed Python pep8/flake8 warnings for lsvmbus” introduces changes as follows.

tools: hv: fixed Python pep8/flake8 warnings for lsvmbus

[ Upstream commit 5912e791f3018de0a007c8cfa9cb38c97d3e5f5c ]

Fixed pep8/flake8 python style code for lsvmbus tool.

The TAB indentation was on purpose ignored (pep8 rule W191) to make
sure the code is complying with the Linux code guideline.
The following command doe not show any warnings now:
pep8 --ignore=W191 lsvmbus
flake8 --ignore=W191 lsvmbus

Signed-off-by: Adrian Vladu <avladu@cloudbasesolutions.com>

Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Alessandro Pilotti <apilotti@cloudbasesolutions.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 0c39d81 (patch).

usb: host: fotg2: restart hcd after port reset

This change “usb: host: fotg2: restart hcd after port reset” (commit 39ad18a) in Linux kernel is authored by Hans Ulli Kroll <ulli.kroll [at] googlemail.com> on Sat Aug 10 17:04:58 2019 +0200.

The change “usb: host: fotg2: restart hcd after port reset” introduces changes as follows.

usb: host: fotg2: restart hcd after port reset

[ Upstream commit 777758888ffe59ef754cc39ab2f275dc277732f4 ]

On the Gemini SoC the FOTG2 stalls after port reset
so restart the HCD after each port reset.

Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190810150458.817-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 39ad18a (patch).

drm/ast: Fixed reboot test may cause system hanged

This change “drm/ast: Fixed reboot test may cause system hanged” (commit 37654ab) in Linux kernel is authored by Y.C. Chen <yc_chen [at] aspeedtech.com> on Wed Apr 11 09:27:39 2018 +0800.

The change “drm/ast: Fixed reboot test may cause system hanged” introduces changes as follows.

drm/ast: Fixed reboot test may cause system hanged

[ Upstream commit 05b439711f6ff8700e8660f97a1179650778b9cb ]

There is another thread still access standard VGA I/O while loading drm driver.
Disable standard VGA I/O decode to avoid this issue.

Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523410059-18415-1-git-send-email-yc_chen@aspeedtech.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 37654ab (patch).

i2c: emev2: avoid race when unregistering slave client

This change “i2c: emev2: avoid race when unregistering slave client” (commit 1cc2ef1) in Linux kernel is authored by Wolfram Sang <wsa+renesas [at] sang-engineering.com> on Thu Aug 8 21:54:17 2019 +0200.

The change “i2c: emev2: avoid race when unregistering slave client” introduces changes as follows.

i2c: emev2: avoid race when unregistering slave client

[ Upstream commit d7437fc0d8291181debe032671a289b6bd93f46f ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: c31d0a00021d ("i2c: emev2: add slave support")
Reported-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 1cc2ef1 (patch).

i2c: rcar: avoid race when unregistering slave client

This change “i2c: rcar: avoid race when unregistering slave client” (commit 7048cd8) in Linux kernel is authored by Wolfram Sang <wsa+renesas [at] sang-engineering.com> on Thu Aug 8 21:39:10 2019 +0200.

The change “i2c: rcar: avoid race when unregistering slave client” introduces changes as follows.

i2c: rcar: avoid race when unregistering slave client

[ Upstream commit 7b814d852af6944657c2961039f404c4490771c0 ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
Reported-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 7048cd8 (patch).

arm64: cpufeature: Don’t treat granule sizes as strict

This change “arm64: cpufeature: Don’t treat granule sizes as strict” (commit 8bd5426) in Linux kernel is authored by Will Deacon <will [at] kernel.org> on Mon Aug 12 16:02:25 2019 +0100.

The change “arm64: cpufeature: Don’t treat granule sizes as strict” introduces changes as follows.

arm64: cpufeature: Don't treat granule sizes as strict

[ Upstream commit 5717fe5ab38f9ccb32718bcb03bea68409c9cce4 ]

If a CPU doesn't support the page size for which the kernel is
configured, then we will complain and refuse to bring it online. For
secondary CPUs (and the boot CPU on a system booting with EFI), we will
also print an error identifying the mismatch.

Consequently, the only time that the cpufeature code can detect a
granule size mismatch is for a granule other than the one that is
currently being used. Although we would rather such systems didn't
exist, we've unfortunately lost that battle and Kevin reports that
on his amlogic S922X (odroid-n2 board) we end up warning and taining
with defconfig because 16k pages are not supported by all of the CPUs.

In such a situation, we don't actually care about the feature mismatch,
particularly now that KVM only exposes the sanitised view of the CPU
registers (commit 93390c0a1b20 - "arm64: KVM: Hide unsupported AArch64
CPU features from guests"). Treat the granule fields as non-strict and
let Kevin run without a tainted kernel.

Cc: Marc Zyngier <maz@kernel.org>
Reported-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
[catalin.marinas@arm.com: changelog updated with KVM sanitised regs commit]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 8bd5426 (patch).

xen/blkback: fix memory leaks

This change “xen/blkback: fix memory leaks” (commit eb535aa) in Linux kernel is authored by Wenwen Wang <wenwen [at] cs.uga.edu> on Sun Aug 11 12:23:22 2019 -0500.

The change “xen/blkback: fix memory leaks” introduces changes as follows.

xen/blkback: fix memory leaks

[ Upstream commit ae78ca3cf3d9e9f914bfcd0bc5c389ff18b9c2e0 ]

In read_per_ring_refs(), after 'req' and related memory regions are
allocated, xen_blkif_map() is invoked to map the shared frame, irq, and
etc. However, if this mapping process fails, no cleanup is performed,
leading to memory leaks. To fix this issue, invoke the cleanup before
returning the error.

Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is eb535aa (patch).

usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt

This change “usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt” (commit 339c157) in Linux kernel is authored by Benjamin Herrenschmidt <benh [at] kernel.crashing.org> on Fri Jul 26 14:59:04 2019 +1000.

The change “usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt” introduces changes as follows.

usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt

[ Upstream commit 4a56a478a525d6427be90753451c40e1327caa1a ]

If fsg_disable() and fsg_set_alt() are called too closely to each
other (for example due to a quick reset/reconnect), what can happen
is that fsg_set_alt sets common->new_fsg from an interrupt while
handle_exception is trying to process the config change caused by
fsg_disable():

        fsg_disable()
        ...
        handle_exception()
                sets state back to FSG_STATE_NORMAL
                hasn't yet called do_set_interface()
                or is inside it.

 ---> interrupt
        fsg_set_alt
                sets common->new_fsg
                queues a new FSG_STATE_CONFIG_CHANGE
 <---

Now, the first handle_exception can "see" the updated
new_fsg, treats it as if it was a fsg_set_alt() response,
call usb_composite_setup_continue() etc...

But then, the thread sees the second FSG_STATE_CONFIG_CHANGE,
and goes back down the same path, wipes and reattaches a now
active fsg, and .. calls usb_composite_setup_continue() which
at this point is wrong.

Not only we get a backtrace, but I suspect the second set_interface
wrecks some state causing the host to get upset in my case.

This fixes it by replacing "new_fsg" by a "state argument" (same
principle) which is set in the same lock section as the state
update, and retrieved similarly.

That way, there is never any discrepancy between the dequeued
state and the observed value of it. We keep the ability to have
the latest reconfig operation take precedence, but we guarantee
that once "dequeued" the argument (new_fsg) will not be clobbered
by any new event.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 339c157 (patch).

usb: gadget: composite: Clear “suspended” on reset/disconnect

This change “usb: gadget: composite: Clear “suspended” on reset/disconnect” (commit 122ab8e) in Linux kernel is authored by Benjamin Herrenschmidt <benh [at] kernel.crashing.org> on Fri Jul 26 14:59:03 2019 +1000.

The change “usb: gadget: composite: Clear “suspended” on reset/disconnect” introduces changes as follows.

usb: gadget: composite: Clear "suspended" on reset/disconnect

[ Upstream commit 602fda17c7356bb7ae98467d93549057481d11dd ]

In some cases, one can get out of suspend with a reset or
a disconnect followed by a reconnect. Previously we would
leave a stale suspended flag set.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 122ab8e (patch).

iommu/dma: Handle SG length overflow better

This change “iommu/dma: Handle SG length overflow better” (commit 21ec20f) in Linux kernel is authored by Robin Murphy <robin.murphy [at] arm.com> on Mon Jul 29 17:46:00 2019 +0100.

The change “iommu/dma: Handle SG length overflow better” introduces changes as follows.

iommu/dma: Handle SG length overflow better

[ Upstream commit ab2cbeb0ed301a9f0460078e91b09f39958212ef ]

Since scatterlist dimensions are all unsigned ints, in the relatively
rare cases where a device's max_segment_size is set to UINT_MAX, then
the "cur_len + s_length <= max_len" check in __finalise_sg() will always
return true. As a result, the corner case of such a device mapping an
excessively large scatterlist which is mergeable to or beyond a total
length of 4GB can lead to overflow and a bogus truncated dma_length in
the resulting segment.

As we already assume that any single segment must be no longer than
max_len to begin with, this can easily be addressed by reshuffling the
comparison.

Fixes: 809eac54cdd6 ("iommu/dma: Implement scatterlist segment merging")
Reported-by: Nicolin Chen <nicoleotsuka@gmail.com>
Tested-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 21ec20f (patch).

omap-dma/omap_vout_vrfb: fix off-by-one fi value

This change “omap-dma/omap_vout_vrfb: fix off-by-one fi value” (commit 7f4b813) in Linux kernel is authored by Hans Verkuil <hverkuil [at] xs4all.nl> on Fri Aug 9 10:32:40 2019 +0200.

The change “omap-dma/omap_vout_vrfb: fix off-by-one fi value” introduces changes as follows.

omap-dma/omap_vout_vrfb: fix off-by-one fi value

[ Upstream commit d555c34338cae844b207564c482e5a3fb089d25e ]

The OMAP 4 TRM specifies that when using double-index addressing
the address increases by the ES plus the EI value minus 1 within
a frame. When a full frame is transferred, the address increases
by the ES plus the frame index (FI) value minus 1.

The omap-dma code didn't account for the 'minus 1' in the FI register.
To get correct addressing, add 1 to the src_icg value.

This was found when testing a hacked version of the media m2m-deinterlace.c
driver on a Pandaboard.

The only other source that uses this feature is omap_vout_vrfb.c,
and that adds a + 1 when setting the dst_icg. This is a workaround
for the broken omap-dma.c behavior. So remove the workaround at the
same time that we fix omap-dma.c.

I tested the omap_vout driver with a Beagle XM board to check that
the '+ 1' in omap_vout_vrfb.c was indeed a workaround for the omap-dma
bug.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Link: https://lore.kernel.org/r/952e7f51-f208-9333-6f58-b7ed20d2ea0b@xs4all.nl
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 7f4b813 (patch).

dmaengine: stm32-mdma: Fix a possible null-pointer dereference in stm32_mdma_irq_handler()

This change “dmaengine: stm32-mdma: Fix a possible null-pointer dereference in stm32_mdma_irq_handler()” (commit 71d24f4) in Linux kernel is authored by Jia-Ju Bai <baijiaju1990 [at] gmail.com> on Mon Jul 29 10:08:49 2019 +0800.

The change “dmaengine: stm32-mdma: Fix a possible null-pointer dereference in stm32_mdma_irq_handler()” introduces changes as follows.

dmaengine: stm32-mdma: Fix a possible null-pointer dereference in stm32_mdma_irq_handler()

[ Upstream commit 39c71a5b8212f4b502d9a630c6706ac723abd422 ]

In stm32_mdma_irq_handler(), chan is checked on line 1368.
When chan is NULL, it is still used on line 1369:
    dev_err(chan2dev(chan), "MDMA channel not initialized\n");

Thus, a possible null-pointer dereference may occur.

To fix this bug, "dev_dbg(mdma2dev(dmadev), ...)" is used instead.

Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver")
Link: https://lore.kernel.org/r/20190729020849.17971-1-baijiaju1990@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 71d24f4 (patch).

auxdisplay: panel: need to delete scan_timer when misc_register fails in panel_attach

This change “auxdisplay: panel: need to delete scan_timer when misc_register fails in panel_attach” (commit 377ebe6) in Linux kernel is authored by zhengbin <zhengbin13 [at] huawei.com> on Mon Jul 8 20:42:18 2019 +0800.

The change “auxdisplay: panel: need to delete scan_timer when misc_register fails in panel_attach” introduces changes as follows.

auxdisplay: panel: need to delete scan_timer when misc_register fails in panel_attach

[ Upstream commit b33d567560c1aadf3033290d74d4fd67af47aa61 ]

In panel_attach, if misc_register fails, we need to delete scan_timer,
which was setup in keypad_init->init_scan_timer.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 377ebe6 (patch).

soundwire: cadence_master: fix definitions for INTSTAT0/1

This change “soundwire: cadence_master: fix definitions for INTSTAT0/1” (commit 2f87eb8) in Linux kernel is authored by Pierre-Louis Bossart <pierre-louis.bossart [at] linux.intel.com> on Thu Jul 25 18:40:06 2019 -0500.

The change “soundwire: cadence_master: fix definitions for INTSTAT0/1” introduces changes as follows.

soundwire: cadence_master: fix definitions for INTSTAT0/1

[ Upstream commit 664b16589f882202b8fa8149d0074f3159bade76 ]

Two off-by-one errors: INTSTAT0 missed BIT(31) and INTSTAT1 is only
defined on first 16 bits.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190725234032.21152-15-pierre-louis.bossart@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 2f87eb8 (patch).

soundwire: cadence_master: fix register definition for SLAVE_STATE

This change “soundwire: cadence_master: fix register definition for SLAVE_STATE” (commit 29b064d) in Linux kernel is authored by Pierre-Louis Bossart <pierre-louis.bossart [at] linux.intel.com> on Thu Jul 25 18:40:05 2019 -0500.

The change “soundwire: cadence_master: fix register definition for SLAVE_STATE” introduces changes as follows.

soundwire: cadence_master: fix register definition for SLAVE_STATE

[ Upstream commit b07dd9b400981f487940a4d84292d3a0e7cd9362 ]

wrong prefix and wrong macro.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190725234032.21152-14-pierre-louis.bossart@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 29b064d (patch).

nvme-pci: Fix async probe remove race

This change “nvme-pci: Fix async probe remove race” (commit 4a98291) in Linux kernel is authored by Keith Busch <kbusch [at] kernel.org> on Mon Jul 29 16:34:52 2019 -0600.

The change “nvme-pci: Fix async probe remove race” introduces changes as follows.

nvme-pci: Fix async probe remove race

[ Upstream commit bd46a90634302bfe791e93ad5496f98f165f7ae0 ]

Ensure the controller is not in the NEW state when nvme_probe() exits.
This will always allow a subsequent nvme_remove() to set the state to
DELETING, fixing a potential race between the initial asynchronous probe
and device removal.

Reported-by: Li Zhong <lizhongfs@gmail.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 4a98291 (patch).

nvme: fix a possible deadlock when passthru commands sent to a multipath device

This change “nvme: fix a possible deadlock when passthru commands sent to a multipath device” (commit 431f579) in Linux kernel is authored by Sagi Grimberg <sagi [at] grimberg.me> on Wed Jul 31 11:00:26 2019 -0700.

The change “nvme: fix a possible deadlock when passthru commands sent to a multipath device” introduces changes as follows.

nvme: fix a possible deadlock when passthru commands sent to a multipath device

[ Upstream commit b9156daeb1601d69007b7e50efcf89d69d72ec1d ]

When the user issues a command with side effects, we will end up freezing
the namespace request queue when updating disk info (and the same for
the corresponding mpath disk node).

However, we are not freezing the mpath node request queue,
which means that mpath I/O can still come in and block on blk_queue_enter
(called from nvme_ns_head_make_request -> direct_make_request).

This is a deadlock, because blk_queue_enter will block until the inner
namespace request queue is unfroze, but that process is blocked because
the namespace revalidation is trying to update the mpath disk info
and freeze its request queue (which will never complete because
of the I/O that is blocked on blk_queue_enter).

Fix this by freezing all the subsystem nsheads request queues before
executing the passthru command. Given that these commands are infrequent
we should not worry about this temporary I/O freeze to keep things sane.

Here is the matching hang traces:
--
[ 374.465002] INFO: task systemd-udevd:17994 blocked for more than 122 seconds.
[ 374.472975] Not tainted 5.2.0-rc3-mpdebug+ #42
[ 374.478522] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 374.487274] systemd-udevd D 0 17994 1 0x00000000
[ 374.493407] Call Trace:
[ 374.496145] __schedule+0x2ef/0x620
[ 374.500047] schedule+0x38/0xa0
[ 374.503569] blk_queue_enter+0x139/0x220
[ 374.507959] ? remove_wait_queue+0x60/0x60
[ 374.512540] direct_make_request+0x60/0x130
[ 374.517219] nvme_ns_head_make_request+0x11d/0x420 [nvme_core]
[ 374.523740] ? generic_make_request_checks+0x307/0x6f0
[ 374.529484] generic_make_request+0x10d/0x2e0
[ 374.534356] submit_bio+0x75/0x140
[ 374.538163] ? guard_bio_eod+0x32/0xe0
[ 374.542361] submit_bh_wbc+0x171/0x1b0
[ 374.546553] block_read_full_page+0x1ed/0x330
[ 374.551426] ? check_disk_change+0x70/0x70
[ 374.556008] ? scan_shadow_nodes+0x30/0x30
[ 374.560588] blkdev_readpage+0x18/0x20
[ 374.564783] do_read_cache_page+0x301/0x860
[ 374.569463] ? blkdev_writepages+0x10/0x10
[ 374.574037] ? prep_new_page+0x88/0x130
[ 374.578329] ? get_page_from_freelist+0xa2f/0x1280
[ 374.583688] ? __alloc_pages_nodemask+0x179/0x320
[ 374.588947] read_cache_page+0x12/0x20
[ 374.593142] read_dev_sector+0x2d/0xd0
[ 374.597337] read_lba+0x104/0x1f0
[ 374.601046] find_valid_gpt+0xfa/0x720
[ 374.605243] ? string_nocheck+0x58/0x70
[ 374.609534] ? find_valid_gpt+0x720/0x720
[ 374.614016] efi_partition+0x89/0x430
[ 374.618113] ? string+0x48/0x60
[ 374.621632] ? snprintf+0x49/0x70
[ 374.625339] ? find_valid_gpt+0x720/0x720
[ 374.629828] check_partition+0x116/0x210
[ 374.634214] rescan_partitions+0xb6/0x360
[ 374.638699] __blkdev_reread_part+0x64/0x70
[ 374.643377] blkdev_reread_part+0x23/0x40
[ 374.647860] blkdev_ioctl+0x48c/0x990
[ 374.651956] block_ioctl+0x41/0x50
[ 374.655766] do_vfs_ioctl+0xa7/0x600
[ 374.659766] ? locks_lock_inode_wait+0xb1/0x150
[ 374.664832] ksys_ioctl+0x67/0x90
[ 374.668539] __x64_sys_ioctl+0x1a/0x20
[ 374.672732] do_syscall_64+0x5a/0x1c0
[ 374.676828] entry_SYSCALL_64_after_hwframe+0x44/0xa9

[ 374.738474] INFO: task nvmeadm:49141 blocked for more than 123 seconds.
[ 374.745871] Not tainted 5.2.0-rc3-mpdebug+ #42
[ 374.751419] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 374.760170] nvmeadm D 0 49141 36333 0x00004080
[ 374.766301] Call Trace:
[ 374.769038] __schedule+0x2ef/0x620
[ 374.772939] schedule+0x38/0xa0
[ 374.776452] blk_mq_freeze_queue_wait+0x59/0x100
[ 374.781614] ? remove_wait_queue+0x60/0x60
[ 374.786192] blk_mq_freeze_queue+0x1a/0x20
[ 374.790773] nvme_update_disk_info.isra.57+0x5f/0x350 [nvme_core]
[ 374.797582] ? nvme_identify_ns.isra.50+0x71/0xc0 [nvme_core]
[ 374.804006] __nvme_revalidate_disk+0xe5/0x110 [nvme_core]
[ 374.810139] nvme_revalidate_disk+0xa6/0x120 [nvme_core]
[ 374.816078] ? nvme_submit_user_cmd+0x11e/0x320 [nvme_core]
[ 374.822299] nvme_user_cmd+0x264/0x370 [nvme_core]
[ 374.827661] nvme_dev_ioctl+0x112/0x1d0 [nvme_core]
[ 374.833114] do_vfs_ioctl+0xa7/0x600
[ 374.837117] ? __audit_syscall_entry+0xdd/0x130
[ 374.842184] ksys_ioctl+0x67/0x90
[ 374.845891] __x64_sys_ioctl+0x1a/0x20
[ 374.850082] do_syscall_64+0x5a/0x1c0
[ 374.854178] entry_SYSCALL_64_after_hwframe+0x44/0xa9
--

Reported-by: James Puthukattukaran <james.puthukattukaran@oracle.com>
Tested-by: James Puthukattukaran <james.puthukattukaran@oracle.com>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 431f579 (patch).

nvmet-loop: Flush nvme_delete_wq when removing the port

This change “nvmet-loop: Flush nvme_delete_wq when removing the port” (commit 32c0b8f) in Linux kernel is authored by Logan Gunthorpe <logang [at] deltatee.com> on Wed Jul 31 17:35:32 2019 -0600.

The change “nvmet-loop: Flush nvme_delete_wq when removing the port” introduces changes as follows.

nvmet-loop: Flush nvme_delete_wq when removing the port

[ Upstream commit 86b9a63e595ff03f9d0a7b92b6acc231fecefc29 ]

After calling nvme_loop_delete_ctrl(), the controllers will not
yet be deleted because nvme_delete_ctrl() only schedules work
to do the delete.

This means a race can occur if a port is removed but there
are still active controllers trying to access that memory.

To fix this, flush the nvme_delete_wq before returning from
nvme_loop_remove_port() so that any controllers that might
be in the process of being deleted won't access a freed port.

Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
Reviewed-by : Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 32c0b8f (patch).

afs: Only update d_fsdata if different in afs_d_revalidate()

This change “afs: Only update d_fsdata if different in afs_d_revalidate()” (commit 9c55dc8) in Linux kernel is authored by David Howells <dhowells [at] redhat.com> on Tue Jul 30 14:38:51 2019 +0100.

The change “afs: Only update d_fsdata if different in afs_d_revalidate()” introduces changes as follows.

afs: Only update d_fsdata if different in afs_d_revalidate()

[ Upstream commit 5dc84855b0fc7e1db182b55c5564fd539d6eff92 ]

In the in-kernel afs filesystem, d_fsdata is set with the data version of
the parent directory.  afs_d_revalidate() will update this to the current
directory version, but it shouldn't do this if it the value it read from
d_fsdata is the same as no lock is held and cmpxchg() is not used.

Fix the code to only change the value if it is different from the current
directory version.

Fixes: 260a980317da ("[AFS]: Add "directory write" support.")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 9c55dc8 (patch).

fs: afs: Fix a possible null-pointer dereference in afs_put_read()

This change “fs: afs: Fix a possible null-pointer dereference in afs_put_read()” (commit 24e093b) in Linux kernel is authored by Jia-Ju Bai <baijiaju1990 [at] gmail.com> on Tue Jul 30 14:38:51 2019 +0100.

The change “fs: afs: Fix a possible null-pointer dereference in afs_put_read()” introduces changes as follows.

fs: afs: Fix a possible null-pointer dereference in afs_put_read()

[ Upstream commit a6eed4ab5dd4bfb696c1a3f49742b8d1846a66a0 ]

In afs_read_dir(), there is an if statement on line 255 to check whether
req->pages is NULL:
        if (!req->pages)
                goto error;

If req->pages is NULL, afs_put_read() on line 337 is executed.
In afs_put_read(), req->pages[i] is used on line 195.
Thus, a possible null-pointer dereference may occur in this case.

To fix this possible bug, an if statement is added in afs_put_read() to
check req->pages.

This bug is found by a static analysis tool STCheck written by us.

Fixes: f3ddee8dc4e2 ("afs: Fix directory handling")
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 24e093b (patch).

afs: Fix loop index mixup in afs_deliver_vl_get_entry_by_name_u()

This change “afs: Fix loop index mixup in afs_deliver_vl_get_entry_by_name_u()” (commit 8e5179f) in Linux kernel is authored by Marc Dionne <marc.dionne [at] auristor.com> on Tue Jul 30 14:38:51 2019 +0100.

The change “afs: Fix loop index mixup in afs_deliver_vl_get_entry_by_name_u()” introduces changes as follows.

afs: Fix loop index mixup in afs_deliver_vl_get_entry_by_name_u()

[ Upstream commit 4a46fdba449a5cd890271df5a9e23927d519ed00 ]

afs_deliver_vl_get_entry_by_name_u() scans through the vl entry
received from the volume location server and builds a return list
containing the sites that are currently valid.  When assigning
values for the return list, the index into the vl entry (i) is used
rather than the one for the new list (entry->nr_server).  If all
sites are usable, this works out fine as the indices will match.
If some sites are not valid, for example if AFS_VLSF_DONTUSE is
set, fs_mask and the uuid will be set for the wrong return site.

Fix this by using entry->nr_server as the index into the arrays
being filled in rather than i.

This can lead to EDESTADDRREQ errors if none of the returned sites
have a valid fs_mask.

Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 8e5179f (patch).

afs: Fix the CB.ProbeUuid service handler to reply correctly

This change “afs: Fix the CB.ProbeUuid service handler to reply correctly” (commit dfc438c) in Linux kernel is authored by David Howells <dhowells [at] redhat.com> on Tue Jul 30 14:38:51 2019 +0100.

The change “afs: Fix the CB.ProbeUuid service handler to reply correctly” introduces changes as follows.

afs: Fix the CB.ProbeUuid service handler to reply correctly

[ Upstream commit 2067b2b3f4846402a040286135f98f46f8919939 ]

Fix the service handler function for the CB.ProbeUuid RPC call so that it
replies in the correct manner - that is an empty reply for success and an
abort of 1 for failure.

Putting 0 or 1 in an integer in the body of the reply should result in the
fileserver throwing an RX_PROTOCOL_ERROR abort and discarding its record of
the client; older servers, however, don't necessarily check that all the
data got consumed, and so might incorrectly think that they got a positive
response and associate the client with the wrong host record.

If the client is incorrectly associated, this will result in callbacks
intended for a different client being delivered to this one and then, when
the other client connects and responds positively, all of the callback
promises meant for the client that issued the improper response will be
lost and it won't receive any further change notifications.

Fixes: 9396d496d745 ("afs: support the CB.ProbeUuid RPC op")
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is dfc438c (patch).

nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns

This change “nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns” (commit 7436dc2) in Linux kernel is authored by Anthony Iliopoulos <ailiopoulos [at] suse.com> on Mon Jul 29 14:40:40 2019 +0200.

The change “nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns” introduces changes as follows.

nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns

[ Upstream commit fab7772bfbcfe8fb8e3e352a6a8fcaf044cded17 ]

When CONFIG_NVME_MULTIPATH is set, only the hidden gendisk associated
with the per-controller ns is run through revalidate_disk when a
rescan is triggered, while the visible blockdev never gets its size
(bdev->bd_inode->i_size) updated to reflect any capacity changes that
may have occurred.

This prevents online resizing of nvme block devices and in extension of
any filesystems atop that will are unable to expand while mounted, as
userspace relies on the blockdev size for obtaining the disk capacity
(via BLKGETSIZE/64 ioctls).

Fix this by explicitly revalidating the actual namespace gendisk in
addition to the per-controller gendisk, when multipath is enabled.

Signed-off-by: Anthony Iliopoulos <ailiopoulos@suse.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 7436dc2 (patch).

dmaengine: ste_dma40: fix unneeded variable warning

This change “dmaengine: ste_dma40: fix unneeded variable warning” (commit 2013d6e) in Linux kernel is authored by Arnd Bergmann <arnd [at] arndb.de> on Fri Jul 12 11:13:30 2019 +0200.

The change “dmaengine: ste_dma40: fix unneeded variable warning” introduces changes as follows.

dmaengine: ste_dma40: fix unneeded variable warning

[ Upstream commit 5d6fb560729a5d5554e23db8d00eb57cd0021083 ]

clang-9 points out that there are two variables that depending on the
configuration may only be used in an ARRAY_SIZE() expression but not
referenced:

drivers/dma/ste_dma40.c:145:12: error: variable 'd40_backup_regs' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs[] = {
           ^
drivers/dma/ste_dma40.c:214:12: error: variable 'd40_backup_regs_chan' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs_chan[] = {

Mark these __maybe_unused to shut up the warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190712091357.744515-1-arnd@arndb.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The commit for this change in Linux stable tree is 2013d6e (patch).