--- /dev/null
+From 88f438a931419e399781650f4e19b11ad28ae3e2 Mon Sep 17 00:00:00 2001
+From: Sahitya Tummala <stummala@codeaurora.org>
+Date: Thu, 3 Jan 2019 16:48:15 +0530
+Subject: configfs: Fix use-after-free when accessing sd->s_dentry
+
+[ Upstream commit f6122ed2a4f9c9c1c073ddf6308d1b2ac10e0781 ]
+
+In the vfs_statx() context, during path lookup, the dentry gets
+added to sd->s_dentry via configfs_attach_attr(). In the end,
+vfs_statx() kills the dentry by calling path_put(), which invokes
+configfs_d_iput(). Ideally, this dentry must be removed from
+sd->s_dentry but it doesn't if the sd->s_count >= 3. As a result,
+sd->s_dentry is holding reference to a stale dentry pointer whose
+memory is already freed up. This results in use-after-free issue,
+when this stale sd->s_dentry is accessed later in
+configfs_readdir() path.
+
+This issue can be easily reproduced, by running the LTP test case -
+sh fs_racer_file_list.sh /config
+(https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh)
+
+Fixes: 76ae281f6307 ('configfs: fix race between dentry put and lookup')
+Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/configfs/dir.c | 14 ++++++--------
+ 1 file changed, 6 insertions(+), 8 deletions(-)
+
+diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
+index d7955dc56737..a1985a9ad2d6 100644
+--- a/fs/configfs/dir.c
++++ b/fs/configfs/dir.c
+@@ -58,15 +58,13 @@ static void configfs_d_iput(struct dentry * dentry,
+ if (sd) {
+ /* Coordinate with configfs_readdir */
+ spin_lock(&configfs_dirent_lock);
+- /* Coordinate with configfs_attach_attr where will increase
+- * sd->s_count and update sd->s_dentry to new allocated one.
+- * Only set sd->dentry to null when this dentry is the only
+- * sd owner.
+- * If not do so, configfs_d_iput may run just after
+- * configfs_attach_attr and set sd->s_dentry to null
+- * even it's still in use.
++ /*
++ * Set sd->s_dentry to null only when this dentry is the one
++ * that is going to be killed. Otherwise configfs_d_iput may
++ * run just after configfs_attach_attr and set sd->s_dentry to
++ * NULL even it's still in use.
+ */
+- if (atomic_read(&sd->s_count) <= 2)
++ if (sd->s_dentry == dentry)
+ sd->s_dentry = NULL;
+
+ spin_unlock(&configfs_dirent_lock);
+--
+2.20.1
+
--- /dev/null
+From 87ef0a8a0d520a7488fe91b0680f51fc9c4bd510 Mon Sep 17 00:00:00 2001
+From: Randy Dunlap <rdunlap@infradead.org>
+Date: Thu, 23 May 2019 15:00:41 -0700
+Subject: gpio: fix gpio-adp5588 build errors
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit e9646f0f5bb62b7d43f0968f39d536cfe7123b53 ]
+
+The gpio-adp5588 driver uses interfaces that are provided by
+GPIOLIB_IRQCHIP, so select that symbol in its Kconfig entry.
+
+Fixes these build errors:
+
+../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_handler’:
+../drivers/gpio/gpio-adp5588.c:266:26: error: ‘struct gpio_chip’ has no member named ‘irq’
+ dev->gpio_chip.irq.domain, gpio));
+ ^
+../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_setup’:
+../drivers/gpio/gpio-adp5588.c:298:2: error: implicit declaration of function ‘gpiochip_irqchip_add_nested’ [-Werror=implicit-function-declaration]
+ ret = gpiochip_irqchip_add_nested(&dev->gpio_chip,
+ ^
+../drivers/gpio/gpio-adp5588.c:307:2: error: implicit declaration of function ‘gpiochip_set_nested_irqchip’ [-Werror=implicit-function-declaration]
+ gpiochip_set_nested_irqchip(&dev->gpio_chip,
+ ^
+
+Fixes: 459773ae8dbb ("gpio: adp5588-gpio: support interrupt controller")
+Reported-by: kbuild test robot <lkp@intel.com>
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Cc: linux-gpio@vger.kernel.org
+Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Acked-by: Michael Hennerich <michael.hennerich@analog.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpio/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
+index 12d417a4d4a8..b992badb99dd 100644
+--- a/drivers/gpio/Kconfig
++++ b/drivers/gpio/Kconfig
+@@ -670,6 +670,7 @@ config GPIO_ADP5588
+ config GPIO_ADP5588_IRQ
+ bool "Interrupt controller support for ADP5588"
+ depends on GPIO_ADP5588=y
++ select GPIOLIB_IRQCHIP
+ help
+ Say yes here to enable the adp5588 to be used as an interrupt
+ controller. It requires the driver to be built in the kernel.
+--
+2.20.1
+
--- /dev/null
+From f9cc54436c2bb0a55b61c6ed4959ae5ec8a3ae09 Mon Sep 17 00:00:00 2001
+From: Yingjoe Chen <yingjoe.chen@mediatek.com>
+Date: Tue, 7 May 2019 22:20:32 +0800
+Subject: i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwr
+
+[ Upstream commit a0692f0eef91354b62c2b4c94954536536be5425 ]
+
+If I2C_M_RECV_LEN check failed, msgs[i].buf allocated by memdup_user
+will not be freed. Pump index up so it will be freed.
+
+Fixes: 838bfa6049fb ("i2c-dev: Add support for I2C_M_RECV_LEN")
+Signed-off-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/i2c-dev.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
+index 00e8e675cbeb..eaa312bc3a3c 100644
+--- a/drivers/i2c/i2c-dev.c
++++ b/drivers/i2c/i2c-dev.c
+@@ -297,6 +297,7 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client *client,
+ rdwr_pa[i].buf[0] < 1 ||
+ rdwr_pa[i].len < rdwr_pa[i].buf[0] +
+ I2C_SMBUS_BLOCK_MAX) {
++ i++;
+ res = -EINVAL;
+ break;
+ }
+--
+2.20.1
+
--- /dev/null
+From 0dc3548aec4a5f99fb42c5a45c33db6f45638a6d Mon Sep 17 00:00:00 2001
+From: Randy Dunlap <rdunlap@infradead.org>
+Date: Tue, 28 May 2019 09:14:30 -0700
+Subject: ia64: fix build errors by exporting paddr_to_nid()
+
+[ Upstream commit 9a626c4a6326da4433a0d4d4a8a7d1571caf1ed3 ]
+
+Fix build errors on ia64 when DISCONTIGMEM=y and NUMA=y by
+exporting paddr_to_nid().
+
+Fixes these build errors:
+
+ERROR: "paddr_to_nid" [sound/core/snd-pcm.ko] undefined!
+ERROR: "paddr_to_nid" [net/sunrpc/sunrpc.ko] undefined!
+ERROR: "paddr_to_nid" [fs/cifs/cifs.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/video/fbdev/core/fb.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/usb/mon/usbmon.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/usb/core/usbcore.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/md/raid1.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/md/dm-mod.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/md/dm-crypt.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/md/dm-bufio.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/ide/ide-core.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/ide/ide-cd_mod.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/gpu/drm/drm.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/char/agp/agpgart.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/block/nbd.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/block/loop.ko] undefined!
+ERROR: "paddr_to_nid" [drivers/block/brd.ko] undefined!
+ERROR: "paddr_to_nid" [crypto/ccm.ko] undefined!
+
+Reported-by: kbuild test robot <lkp@intel.com>
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Cc: Tony Luck <tony.luck@intel.com>
+Cc: Fenghua Yu <fenghua.yu@intel.com>
+Cc: linux-ia64@vger.kernel.org
+Signed-off-by: Tony Luck <tony.luck@intel.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/ia64/mm/numa.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/ia64/mm/numa.c b/arch/ia64/mm/numa.c
+index aa19b7ac8222..476c7b4be378 100644
+--- a/arch/ia64/mm/numa.c
++++ b/arch/ia64/mm/numa.c
+@@ -49,6 +49,7 @@ paddr_to_nid(unsigned long paddr)
+
+ return (i < num_node_memblks) ? node_memblk[i].nid : (num_node_memblks ? -1 : 0);
+ }
++EXPORT_SYMBOL(paddr_to_nid);
+
+ #if defined(CONFIG_SPARSEMEM) && defined(CONFIG_NUMA)
+ /*
+--
+2.20.1
+
--- /dev/null
+From f3b8a183016a959ba87033795ee72ae966407f01 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Thu, 23 May 2019 16:36:32 +1000
+Subject: KVM: PPC: Book3S HV: Don't take kvm->lock around kvm_for_each_vcpu
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 5a3f49364c3ffa1107bd88f8292406e98c5d206c ]
+
+Currently the HV KVM code takes the kvm->lock around calls to
+kvm_for_each_vcpu() and kvm_get_vcpu_by_id() (which can call
+kvm_for_each_vcpu() internally). However, that leads to a lock
+order inversion problem, because these are called in contexts where
+the vcpu mutex is held, but the vcpu mutexes nest within kvm->lock
+according to Documentation/virtual/kvm/locking.txt. Hence there
+is a possibility of deadlock.
+
+To fix this, we simply don't take the kvm->lock mutex around these
+calls. This is safe because the implementations of kvm_for_each_vcpu()
+and kvm_get_vcpu_by_id() have been designed to be able to be called
+locklessly.
+
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Reviewed-by: Cédric Le Goater <clg@kaod.org>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kvm/book3s_hv.c | 9 +--------
+ 1 file changed, 1 insertion(+), 8 deletions(-)
+
+diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
+index 0a2b247dbc6b..e840f943cd2c 100644
+--- a/arch/powerpc/kvm/book3s_hv.c
++++ b/arch/powerpc/kvm/book3s_hv.c
+@@ -374,12 +374,7 @@ static void kvmppc_dump_regs(struct kvm_vcpu *vcpu)
+
+ static struct kvm_vcpu *kvmppc_find_vcpu(struct kvm *kvm, int id)
+ {
+- struct kvm_vcpu *ret;
+-
+- mutex_lock(&kvm->lock);
+- ret = kvm_get_vcpu_by_id(kvm, id);
+- mutex_unlock(&kvm->lock);
+- return ret;
++ return kvm_get_vcpu_by_id(kvm, id);
+ }
+
+ static void init_vpa(struct kvm_vcpu *vcpu, struct lppaca *vpa)
+@@ -1098,7 +1093,6 @@ static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64 new_lpcr,
+ struct kvmppc_vcore *vc = vcpu->arch.vcore;
+ u64 mask;
+
+- mutex_lock(&kvm->lock);
+ spin_lock(&vc->lock);
+ /*
+ * If ILE (interrupt little-endian) has changed, update the
+@@ -1132,7 +1126,6 @@ static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64 new_lpcr,
+ mask &= 0xFFFFFFFF;
+ vc->lpcr = (vc->lpcr & ~mask) | (new_lpcr & mask);
+ spin_unlock(&vc->lock);
+- mutex_unlock(&kvm->lock);
+ }
+
+ static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
+--
+2.20.1
+
--- /dev/null
+From 3938c7e1190762599d77de05d4e3ab7aa7280b61 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Wed, 29 May 2019 11:54:00 +1000
+Subject: KVM: PPC: Book3S: Use new mutex to synchronize access to rtas token
+ list
+
+[ Upstream commit 1659e27d2bc1ef47b6d031abe01b467f18cb72d9 ]
+
+Currently the Book 3S KVM code uses kvm->lock to synchronize access
+to the kvm->arch.rtas_tokens list. Because this list is scanned
+inside kvmppc_rtas_hcall(), which is called with the vcpu mutex held,
+taking kvm->lock cause a lock inversion problem, which could lead to
+a deadlock.
+
+To fix this, we add a new mutex, kvm->arch.rtas_token_lock, which nests
+inside the vcpu mutexes, and use that instead of kvm->lock when
+accessing the rtas token list.
+
+This removes the lockdep_assert_held() in kvmppc_rtas_tokens_free().
+At this point we don't hold the new mutex, but that is OK because
+kvmppc_rtas_tokens_free() is only called when the whole VM is being
+destroyed, and at that point nothing can be looking up a token in
+the list.
+
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/include/asm/kvm_host.h | 1 +
+ arch/powerpc/kvm/book3s.c | 1 +
+ arch/powerpc/kvm/book3s_rtas.c | 14 ++++++--------
+ 3 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
+index 5e12e19940e2..defa553fe823 100644
+--- a/arch/powerpc/include/asm/kvm_host.h
++++ b/arch/powerpc/include/asm/kvm_host.h
+@@ -271,6 +271,7 @@ struct kvm_arch {
+ #ifdef CONFIG_PPC_BOOK3S_64
+ struct list_head spapr_tce_tables;
+ struct list_head rtas_tokens;
++ struct mutex rtas_token_lock;
+ DECLARE_BITMAP(enabled_hcalls, MAX_HCALL_OPCODE/4 + 1);
+ #endif
+ #ifdef CONFIG_KVM_MPIC
+diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
+index b6952dd23152..73c3c127d858 100644
+--- a/arch/powerpc/kvm/book3s.c
++++ b/arch/powerpc/kvm/book3s.c
+@@ -811,6 +811,7 @@ int kvmppc_core_init_vm(struct kvm *kvm)
+ #ifdef CONFIG_PPC64
+ INIT_LIST_HEAD_RCU(&kvm->arch.spapr_tce_tables);
+ INIT_LIST_HEAD(&kvm->arch.rtas_tokens);
++ mutex_init(&kvm->arch.rtas_token_lock);
+ #endif
+
+ return kvm->arch.kvm_ops->init_vm(kvm);
+diff --git a/arch/powerpc/kvm/book3s_rtas.c b/arch/powerpc/kvm/book3s_rtas.c
+index ef27fbd5d9c5..b1b2273d1f6d 100644
+--- a/arch/powerpc/kvm/book3s_rtas.c
++++ b/arch/powerpc/kvm/book3s_rtas.c
+@@ -133,7 +133,7 @@ static int rtas_token_undefine(struct kvm *kvm, char *name)
+ {
+ struct rtas_token_definition *d, *tmp;
+
+- lockdep_assert_held(&kvm->lock);
++ lockdep_assert_held(&kvm->arch.rtas_token_lock);
+
+ list_for_each_entry_safe(d, tmp, &kvm->arch.rtas_tokens, list) {
+ if (rtas_name_matches(d->handler->name, name)) {
+@@ -154,7 +154,7 @@ static int rtas_token_define(struct kvm *kvm, char *name, u64 token)
+ bool found;
+ int i;
+
+- lockdep_assert_held(&kvm->lock);
++ lockdep_assert_held(&kvm->arch.rtas_token_lock);
+
+ list_for_each_entry(d, &kvm->arch.rtas_tokens, list) {
+ if (d->token == token)
+@@ -193,14 +193,14 @@ int kvm_vm_ioctl_rtas_define_token(struct kvm *kvm, void __user *argp)
+ if (copy_from_user(&args, argp, sizeof(args)))
+ return -EFAULT;
+
+- mutex_lock(&kvm->lock);
++ mutex_lock(&kvm->arch.rtas_token_lock);
+
+ if (args.token)
+ rc = rtas_token_define(kvm, args.name, args.token);
+ else
+ rc = rtas_token_undefine(kvm, args.name);
+
+- mutex_unlock(&kvm->lock);
++ mutex_unlock(&kvm->arch.rtas_token_lock);
+
+ return rc;
+ }
+@@ -232,7 +232,7 @@ int kvmppc_rtas_hcall(struct kvm_vcpu *vcpu)
+ orig_rets = args.rets;
+ args.rets = &args.args[be32_to_cpu(args.nargs)];
+
+- mutex_lock(&vcpu->kvm->lock);
++ mutex_lock(&vcpu->kvm->arch.rtas_token_lock);
+
+ rc = -ENOENT;
+ list_for_each_entry(d, &vcpu->kvm->arch.rtas_tokens, list) {
+@@ -243,7 +243,7 @@ int kvmppc_rtas_hcall(struct kvm_vcpu *vcpu)
+ }
+ }
+
+- mutex_unlock(&vcpu->kvm->lock);
++ mutex_unlock(&vcpu->kvm->arch.rtas_token_lock);
+
+ if (rc == 0) {
+ args.rets = orig_rets;
+@@ -269,8 +269,6 @@ void kvmppc_rtas_tokens_free(struct kvm *kvm)
+ {
+ struct rtas_token_definition *d, *tmp;
+
+- lockdep_assert_held(&kvm->lock);
+-
+ list_for_each_entry_safe(d, tmp, &kvm->arch.rtas_tokens, list) {
+ list_del(&d->list);
+ kfree(d);
+--
+2.20.1
+
--- /dev/null
+From 92ce87952a9879a5a839f980bd544e51ee068c43 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Wed, 22 May 2019 11:45:13 +0300
+Subject: mISDN: make sure device name is NUL terminated
+
+[ Upstream commit ccfb62f27beb295103e9392462b20a6ed807d0ea ]
+
+The user can change the device_name with the IMSETDEVNAME ioctl, but we
+need to ensure that the user's name is NUL terminated. Otherwise it
+could result in a buffer overflow when we copy the name back to the user
+with IMGETDEVINFO ioctl.
+
+I also changed two strcpy() calls which handle the name to strscpy().
+Hopefully, there aren't any other ways to create a too long name, but
+it's nice to do this as a kernel hardening measure.
+
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/isdn/mISDN/socket.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/isdn/mISDN/socket.c b/drivers/isdn/mISDN/socket.c
+index f96b8f2bdf74..d7c986fb0b3b 100644
+--- a/drivers/isdn/mISDN/socket.c
++++ b/drivers/isdn/mISDN/socket.c
+@@ -394,7 +394,7 @@ data_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
+ memcpy(di.channelmap, dev->channelmap,
+ sizeof(di.channelmap));
+ di.nrbchan = dev->nrbchan;
+- strcpy(di.name, dev_name(&dev->dev));
++ strscpy(di.name, dev_name(&dev->dev), sizeof(di.name));
+ if (copy_to_user((void __user *)arg, &di, sizeof(di)))
+ err = -EFAULT;
+ } else
+@@ -678,7 +678,7 @@ base_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
+ memcpy(di.channelmap, dev->channelmap,
+ sizeof(di.channelmap));
+ di.nrbchan = dev->nrbchan;
+- strcpy(di.name, dev_name(&dev->dev));
++ strscpy(di.name, dev_name(&dev->dev), sizeof(di.name));
+ if (copy_to_user((void __user *)arg, &di, sizeof(di)))
+ err = -EFAULT;
+ } else
+@@ -692,6 +692,7 @@ base_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
+ err = -EFAULT;
+ break;
+ }
++ dn.name[sizeof(dn.name) - 1] = '\0';
+ dev = get_mdevice(dn.id);
+ if (dev)
+ err = device_rename(&dev->dev, dn.name);
+--
+2.20.1
+
--- /dev/null
+From 8367c5d34398936960a2f9732634d538ccd8788c Mon Sep 17 00:00:00 2001
+From: Amit Cohen <amitc@mellanox.com>
+Date: Wed, 29 May 2019 10:59:45 +0300
+Subject: mlxsw: spectrum: Prevent force of 56G
+
+[ Upstream commit 275e928f19117d22f6d26dee94548baf4041b773 ]
+
+Force of 56G is not supported by hardware in Ethernet devices. This
+configuration fails with a bad parameter error from firmware.
+
+Add check of this case. Instead of trying to set 56G with autoneg off,
+return a meaningful error.
+
+Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
+Signed-off-by: Amit Cohen <amitc@mellanox.com>
+Acked-by: Jiri Pirko <jiri@mellanox.com>
+Signed-off-by: Ido Schimmel <idosch@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+index e3ed70a24029..585a40cc6470 100644
+--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+@@ -2044,6 +2044,10 @@ mlxsw_sp_port_set_link_ksettings(struct net_device *dev,
+ mlxsw_reg_ptys_unpack(ptys_pl, ð_proto_cap, NULL, NULL);
+
+ autoneg = cmd->base.autoneg == AUTONEG_ENABLE;
++ if (!autoneg && cmd->base.speed == SPEED_56000) {
++ netdev_err(dev, "56G not supported with autoneg off\n");
++ return -EINVAL;
++ }
+ eth_proto_new = autoneg ?
+ mlxsw_sp_to_ptys_advert_link(cmd) :
+ mlxsw_sp_to_ptys_speed(cmd->base.speed);
+--
+2.20.1
+
--- /dev/null
+From 9c2fa28ecd5c7c86ef2ac44b55b4be68ceb83e5d Mon Sep 17 00:00:00 2001
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Date: Tue, 28 May 2019 13:10:46 +0900
+Subject: net: sh_eth: fix mdio access in sh_eth_close() for R-Car Gen2 and
+ RZ/A1 SoCs
+
+[ Upstream commit 315ca92dd863fecbffc0bb52ae0ac11e0398726a ]
+
+The sh_eth_close() resets the MAC and then calls phy_stop()
+so that mdio read access result is incorrect without any error
+according to kernel trace like below:
+
+ifconfig-216 [003] .n.. 109.133124: mdio_access: ee700000.ethernet-ffffffff read phy:0x01 reg:0x00 val:0xffff
+
+According to the hardware manual, the RMII mode should be set to 1
+before operation the Ethernet MAC. However, the previous code was not
+set to 1 after the driver issued the soft_reset in sh_eth_dev_exit()
+so that the mdio read access result seemed incorrect. To fix the issue,
+this patch adds a condition and set the RMII mode register in
+sh_eth_dev_exit() for R-Car Gen2 and RZ/A1 SoCs.
+
+Note that when I have tried to move the sh_eth_dev_exit() calling
+after phy_stop() on sh_eth_close(), but it gets worse (kernel panic
+happened and it seems that a register is accessed while the clock is
+off).
+
+Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/renesas/sh_eth.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
+index c59e8fe37069..49300194d3f9 100644
+--- a/drivers/net/ethernet/renesas/sh_eth.c
++++ b/drivers/net/ethernet/renesas/sh_eth.c
+@@ -1388,6 +1388,10 @@ static void sh_eth_dev_exit(struct net_device *ndev)
+ sh_eth_get_stats(ndev);
+ sh_eth_reset(ndev);
+
++ /* Set the RMII mode again if required */
++ if (mdp->cd->rmiimode)
++ sh_eth_write(ndev, 0x1, RMIIMODE);
++
+ /* Set MAC address again */
+ update_mac_address(ndev);
+ }
+--
+2.20.1
+
--- /dev/null
+From 36698c79978ba79f431ac93cce81b326b9292a71 Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Fri, 24 May 2019 13:20:19 -0700
+Subject: net: tulip: de4x5: Drop redundant MODULE_DEVICE_TABLE()
+
+[ Upstream commit 3e66b7cc50ef921121babc91487e1fb98af1ba6e ]
+
+Building with Clang reports the redundant use of MODULE_DEVICE_TABLE():
+
+drivers/net/ethernet/dec/tulip/de4x5.c:2110:1: error: redefinition of '__mod_eisa__de4x5_eisa_ids_device_table'
+MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
+^
+./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
+extern typeof(name) __mod_##type##__##name##_device_table \
+ ^
+<scratch space>:90:1: note: expanded from here
+__mod_eisa__de4x5_eisa_ids_device_table
+^
+drivers/net/ethernet/dec/tulip/de4x5.c:2100:1: note: previous definition is here
+MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
+^
+./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
+extern typeof(name) __mod_##type##__##name##_device_table \
+ ^
+<scratch space>:85:1: note: expanded from here
+__mod_eisa__de4x5_eisa_ids_device_table
+^
+
+This drops the one further from the table definition to match the common
+use of MODULE_DEVICE_TABLE().
+
+Fixes: 07563c711fbc ("EISA bus MODALIAS attributes support")
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/dec/tulip/de4x5.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c
+index 6620fc861c47..005c79b5b3f0 100644
+--- a/drivers/net/ethernet/dec/tulip/de4x5.c
++++ b/drivers/net/ethernet/dec/tulip/de4x5.c
+@@ -2109,7 +2109,6 @@ static struct eisa_driver de4x5_eisa_driver = {
+ .remove = de4x5_eisa_remove,
+ }
+ };
+-MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
+ #endif
+
+ #ifdef CONFIG_PCI
+--
+2.20.1
+
--- /dev/null
+From 81025d960d633d321e37e4500dc8da0a4c6d5a3b Mon Sep 17 00:00:00 2001
+From: Shawn Landden <shawn@git.icu>
+Date: Sat, 18 May 2019 15:32:38 -0300
+Subject: perf data: Fix 'strncat may truncate' build failure with recent gcc
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 97acec7df172cd1e450f81f5e293c0aa145a2797 ]
+
+This strncat() is safe because the buffer was allocated with zalloc(),
+however gcc doesn't know that. Since the string always has 4 non-null
+bytes, just use memcpy() here.
+
+ CC /home/shawn/linux/tools/perf/util/data-convert-bt.o
+ In file included from /usr/include/string.h:494,
+ from /home/shawn/linux/tools/lib/traceevent/event-parse.h:27,
+ from util/data-convert-bt.c:22:
+ In function ‘strncat’,
+ inlined from ‘string_set_value’ at util/data-convert-bt.c:274:4:
+ /usr/include/powerpc64le-linux-gnu/bits/string_fortified.h:136:10: error: ‘__builtin_strncat’ output may be truncated copying 4 bytes from a string of length 4 [-Werror=stringop-truncation]
+ 136 | return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Signed-off-by: Shawn Landden <shawn@git.icu>
+Cc: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Wang Nan <wangnan0@huawei.com>
+LPU-Reference: 20190518183238.10954-1-shawn@git.icu
+Link: https://lkml.kernel.org/n/tip-289f1jice17ta7tr3tstm9jm@git.kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/util/data-convert-bt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/perf/util/data-convert-bt.c b/tools/perf/util/data-convert-bt.c
+index 7123f4de32cc..226f4312b8f3 100644
+--- a/tools/perf/util/data-convert-bt.c
++++ b/tools/perf/util/data-convert-bt.c
+@@ -265,7 +265,7 @@ static int string_set_value(struct bt_ctf_field *field, const char *string)
+ if (i > 0)
+ strncpy(buffer, string, i);
+ }
+- strncat(buffer + p, numstr, 4);
++ memcpy(buffer + p, numstr, 4);
+ p += 3;
+ }
+ }
+--
+2.20.1
+
--- /dev/null
+From 0a9583d73080ae66041548932a30aab31a275b16 Mon Sep 17 00:00:00 2001
+From: Thomas Richter <tmricht@linux.ibm.com>
+Date: Wed, 22 May 2019 16:46:01 +0200
+Subject: perf record: Fix s390 missing module symbol and warning for non-root
+ users
+
+[ Upstream commit 6738028dd57df064b969d8392c943ef3b3ae705d ]
+
+Command 'perf record' and 'perf report' on a system without kernel
+debuginfo packages uses /proc/kallsyms and /proc/modules to find
+addresses for kernel and module symbols. On x86 this works for root and
+non-root users.
+
+On s390, when invoked as non-root user, many of the following warnings
+are shown and module symbols are missing:
+
+ proc/{kallsyms,modules} inconsistency while looking for
+ "[sha1_s390]" module!
+
+Command 'perf record' creates a list of module start addresses by
+parsing the output of /proc/modules and creates a PERF_RECORD_MMAP
+record for the kernel and each module. The following function call
+sequence is executed:
+
+ machine__create_kernel_maps
+ machine__create_module
+ modules__parse
+ machine__create_module --> for each line in /proc/modules
+ arch__fix_module_text_start
+
+Function arch__fix_module_text_start() is s390 specific. It opens
+file /sys/module/<name>/sections/.text to extract the module's .text
+section start address. On s390 the module loader prepends a header
+before the first section, whereas on x86 the module's text section
+address is identical the the module's load address.
+
+However module section files are root readable only. For non-root the
+read operation fails and machine__create_module() returns an error.
+Command perf record does not generate any PERF_RECORD_MMAP record
+for loaded modules. Later command perf report complains about missing
+module maps.
+
+To fix this function arch__fix_module_text_start() always returns
+success. For root users there is no change, for non-root users
+the module's load address is used as module's text start address
+(the prepended header then counts as part of the text section).
+
+This enable non-root users to use module symbols and avoid the
+warning when perf report is executed.
+
+Output before:
+
+ [tmricht@m83lp54 perf]$ ./perf report -D | fgrep MMAP
+ 0 0x168 [0x50]: PERF_RECORD_MMAP ... x [kernel.kallsyms]_text
+
+Output after:
+
+ [tmricht@m83lp54 perf]$ ./perf report -D | fgrep MMAP
+ 0 0x168 [0x50]: PERF_RECORD_MMAP ... x [kernel.kallsyms]_text
+ 0 0x1b8 [0x98]: PERF_RECORD_MMAP ... x /lib/modules/.../autofs4.ko.xz
+ 0 0x250 [0xa8]: PERF_RECORD_MMAP ... x /lib/modules/.../sha_common.ko.xz
+ 0 0x2f8 [0x98]: PERF_RECORD_MMAP ... x /lib/modules/.../des_generic.ko.xz
+
+Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
+Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
+Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
+Link: http://lkml.kernel.org/r/20190522144601.50763-4-tmricht@linux.ibm.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/arch/s390/util/machine.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/tools/perf/arch/s390/util/machine.c b/tools/perf/arch/s390/util/machine.c
+index b9a95a1a8e69..d3d1452021d4 100644
+--- a/tools/perf/arch/s390/util/machine.c
++++ b/tools/perf/arch/s390/util/machine.c
+@@ -4,16 +4,19 @@
+ #include "util.h"
+ #include "machine.h"
+ #include "api/fs/fs.h"
++#include "debug.h"
+
+ int arch__fix_module_text_start(u64 *start, const char *name)
+ {
++ u64 m_start = *start;
+ char path[PATH_MAX];
+
+ snprintf(path, PATH_MAX, "module/%.*s/sections/.text",
+ (int)strlen(name) - 2, name + 1);
+-
+- if (sysfs__read_ull(path, (unsigned long long *)start) < 0)
+- return -1;
++ if (sysfs__read_ull(path, (unsigned long long *)start) < 0) {
++ pr_debug2("Using module %s start:%#lx\n", path, m_start);
++ *start = m_start;
++ }
+
+ return 0;
+ }
+--
+2.20.1
+
--- /dev/null
+From c57054b5db2843195410631522420286cf5dcd39 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Fri, 17 May 2019 13:52:32 +0200
+Subject: perf/ring_buffer: Add ordering to rb->nest increment
+
+[ Upstream commit 3f9fbe9bd86c534eba2faf5d840fd44c6049f50e ]
+
+Similar to how decrementing rb->next too early can cause data_head to
+(temporarily) be observed to go backward, so too can this happen when
+we increment too late.
+
+This barrier() ensures the rb->head load happens after the increment,
+both the one in the 'goto again' path, as the one from
+perf_output_get_handle() -- albeit very unlikely to matter for the
+latter.
+
+Suggested-by: Yabin Cui <yabinc@google.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@google.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vince Weaver <vincent.weaver@maine.edu>
+Cc: acme@kernel.org
+Cc: mark.rutland@arm.com
+Cc: namhyung@kernel.org
+Fixes: ef60777c9abd ("perf: Optimize the perf_output() path by removing IRQ-disables")
+Link: http://lkml.kernel.org/r/20190517115418.309516009@infradead.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/events/ring_buffer.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
+index 524744a38d61..8e8b903b7613 100644
+--- a/kernel/events/ring_buffer.c
++++ b/kernel/events/ring_buffer.c
+@@ -49,6 +49,15 @@ static void perf_output_put_handle(struct perf_output_handle *handle)
+ unsigned long head;
+
+ again:
++ /*
++ * In order to avoid publishing a head value that goes backwards,
++ * we must ensure the load of @rb->head happens after we've
++ * incremented @rb->nest.
++ *
++ * Otherwise we can observe a @rb->head value before one published
++ * by an IRQ/NMI happening between the load and the increment.
++ */
++ barrier();
+ head = local_read(&rb->head);
+
+ /*
+--
+2.20.1
+
--- /dev/null
+From 9518318a09cc7d48a91f2001f41199a7963a35fa Mon Sep 17 00:00:00 2001
+From: Yabin Cui <yabinc@google.com>
+Date: Fri, 17 May 2019 13:52:31 +0200
+Subject: perf/ring_buffer: Fix exposing a temporarily decreased data_head
+
+[ Upstream commit 1b038c6e05ff70a1e66e3e571c2e6106bdb75f53 ]
+
+In perf_output_put_handle(), an IRQ/NMI can happen in below location and
+write records to the same ring buffer:
+
+ ...
+ local_dec_and_test(&rb->nest)
+ ... <-- an IRQ/NMI can happen here
+ rb->user_page->data_head = head;
+ ...
+
+In this case, a value A is written to data_head in the IRQ, then a value
+B is written to data_head after the IRQ. And A > B. As a result,
+data_head is temporarily decreased from A to B. And a reader may see
+data_head < data_tail if it read the buffer frequently enough, which
+creates unexpected behaviors.
+
+This can be fixed by moving dec(&rb->nest) to after updating data_head,
+which prevents the IRQ/NMI above from updating data_head.
+
+[ Split up by peterz. ]
+
+Signed-off-by: Yabin Cui <yabinc@google.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@google.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vince Weaver <vincent.weaver@maine.edu>
+Cc: mark.rutland@arm.com
+Fixes: ef60777c9abd ("perf: Optimize the perf_output() path by removing IRQ-disables")
+Link: http://lkml.kernel.org/r/20190517115418.224478157@infradead.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/events/ring_buffer.c | 24 ++++++++++++++++++++----
+ 1 file changed, 20 insertions(+), 4 deletions(-)
+
+diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
+index 99becab2c1ce..524744a38d61 100644
+--- a/kernel/events/ring_buffer.c
++++ b/kernel/events/ring_buffer.c
+@@ -52,11 +52,18 @@ static void perf_output_put_handle(struct perf_output_handle *handle)
+ head = local_read(&rb->head);
+
+ /*
+- * IRQ/NMI can happen here, which means we can miss a head update.
++ * IRQ/NMI can happen here and advance @rb->head, causing our
++ * load above to be stale.
+ */
+
+- if (!local_dec_and_test(&rb->nest))
++ /*
++ * If this isn't the outermost nesting, we don't have to update
++ * @rb->user_page->data_head.
++ */
++ if (local_read(&rb->nest) > 1) {
++ local_dec(&rb->nest);
+ goto out;
++ }
+
+ /*
+ * Since the mmap() consumer (userspace) can run on a different CPU:
+@@ -88,9 +95,18 @@ static void perf_output_put_handle(struct perf_output_handle *handle)
+ rb->user_page->data_head = head;
+
+ /*
+- * Now check if we missed an update -- rely on previous implied
+- * compiler barriers to force a re-read.
++ * We must publish the head before decrementing the nest count,
++ * otherwise an IRQ/NMI can publish a more recent head value and our
++ * write will (temporarily) publish a stale value.
++ */
++ barrier();
++ local_set(&rb->nest, 0);
++
++ /*
++ * Ensure we decrement @rb->nest before we validate the @rb->head.
++ * Otherwise we cannot be sure we caught the 'last' nested update.
+ */
++ barrier();
+ if (unlikely(head != local_read(&rb->head))) {
+ local_inc(&rb->nest);
+ goto again;
+--
+2.20.1
+
--- /dev/null
+From 15009fa2cdaf08ff36ee9d3727131178fb188ea4 Mon Sep 17 00:00:00 2001
+From: Stephane Eranian <eranian@google.com>
+Date: Mon, 20 May 2019 17:52:46 -0700
+Subject: perf/x86/intel/ds: Fix EVENT vs. UEVENT PEBS constraints
+
+[ Upstream commit 23e3983a466cd540ffdd2bbc6e0c51e31934f941 ]
+
+This patch fixes an bug revealed by the following commit:
+
+ 6b89d4c1ae85 ("perf/x86/intel: Fix INTEL_FLAGS_EVENT_CONSTRAINT* masking")
+
+That patch modified INTEL_FLAGS_EVENT_CONSTRAINT() to only look at the event code
+when matching a constraint. If code+umask were needed, then the
+INTEL_FLAGS_UEVENT_CONSTRAINT() macro was needed instead.
+This broke with some of the constraints for PEBS events.
+
+Several of them, including the one used for cycles:p, cycles:pp, cycles:ppp
+fell in that category and caused the event to be rejected in PEBS mode.
+In other words, on some platforms a cmdline such as:
+
+ $ perf top -e cycles:pp
+
+would fail with -EINVAL.
+
+This patch fixes this bug by properly using INTEL_FLAGS_UEVENT_CONSTRAINT()
+when needed in the PEBS constraint tables.
+
+Reported-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Stephane Eranian <eranian@google.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vince Weaver <vincent.weaver@maine.edu>
+Cc: kan.liang@intel.com
+Link: http://lkml.kernel.org/r/20190521005246.423-1-eranian@google.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/events/intel/ds.c | 28 ++++++++++++++--------------
+ 1 file changed, 14 insertions(+), 14 deletions(-)
+
+diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
+index f26e26e4d84f..ad31c01f810f 100644
+--- a/arch/x86/events/intel/ds.c
++++ b/arch/x86/events/intel/ds.c
+@@ -655,7 +655,7 @@ struct event_constraint intel_core2_pebs_event_constraints[] = {
+ INTEL_FLAGS_UEVENT_CONSTRAINT(0x1fc7, 0x1), /* SIMD_INST_RETURED.ANY */
+ INTEL_FLAGS_EVENT_CONSTRAINT(0xcb, 0x1), /* MEM_LOAD_RETIRED.* */
+ /* INST_RETIRED.ANY_P, inv=1, cmask=16 (cycles:p). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108000c0, 0x01),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108000c0, 0x01),
+ EVENT_CONSTRAINT_END
+ };
+
+@@ -664,7 +664,7 @@ struct event_constraint intel_atom_pebs_event_constraints[] = {
+ INTEL_FLAGS_UEVENT_CONSTRAINT(0x00c5, 0x1), /* MISPREDICTED_BRANCH_RETIRED */
+ INTEL_FLAGS_EVENT_CONSTRAINT(0xcb, 0x1), /* MEM_LOAD_RETIRED.* */
+ /* INST_RETIRED.ANY_P, inv=1, cmask=16 (cycles:p). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108000c0, 0x01),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108000c0, 0x01),
+ /* Allow all events as PEBS with no flags */
+ INTEL_ALL_EVENT_CONSTRAINT(0, 0x1),
+ EVENT_CONSTRAINT_END
+@@ -672,7 +672,7 @@ struct event_constraint intel_atom_pebs_event_constraints[] = {
+
+ struct event_constraint intel_slm_pebs_event_constraints[] = {
+ /* INST_RETIRED.ANY_P, inv=1, cmask=16 (cycles:p). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108000c0, 0x1),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108000c0, 0x1),
+ /* Allow all events as PEBS with no flags */
+ INTEL_ALL_EVENT_CONSTRAINT(0, 0x1),
+ EVENT_CONSTRAINT_END
+@@ -697,7 +697,7 @@ struct event_constraint intel_nehalem_pebs_event_constraints[] = {
+ INTEL_FLAGS_EVENT_CONSTRAINT(0xcb, 0xf), /* MEM_LOAD_RETIRED.* */
+ INTEL_FLAGS_EVENT_CONSTRAINT(0xf7, 0xf), /* FP_ASSIST.* */
+ /* INST_RETIRED.ANY_P, inv=1, cmask=16 (cycles:p). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108000c0, 0x0f),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108000c0, 0x0f),
+ EVENT_CONSTRAINT_END
+ };
+
+@@ -714,7 +714,7 @@ struct event_constraint intel_westmere_pebs_event_constraints[] = {
+ INTEL_FLAGS_EVENT_CONSTRAINT(0xcb, 0xf), /* MEM_LOAD_RETIRED.* */
+ INTEL_FLAGS_EVENT_CONSTRAINT(0xf7, 0xf), /* FP_ASSIST.* */
+ /* INST_RETIRED.ANY_P, inv=1, cmask=16 (cycles:p). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108000c0, 0x0f),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108000c0, 0x0f),
+ EVENT_CONSTRAINT_END
+ };
+
+@@ -723,7 +723,7 @@ struct event_constraint intel_snb_pebs_event_constraints[] = {
+ INTEL_PLD_CONSTRAINT(0x01cd, 0x8), /* MEM_TRANS_RETIRED.LAT_ABOVE_THR */
+ INTEL_PST_CONSTRAINT(0x02cd, 0x8), /* MEM_TRANS_RETIRED.PRECISE_STORES */
+ /* UOPS_RETIRED.ALL, inv=1, cmask=16 (cycles:p). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108001c2, 0xf),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108001c2, 0xf),
+ INTEL_EXCLEVT_CONSTRAINT(0xd0, 0xf), /* MEM_UOP_RETIRED.* */
+ INTEL_EXCLEVT_CONSTRAINT(0xd1, 0xf), /* MEM_LOAD_UOPS_RETIRED.* */
+ INTEL_EXCLEVT_CONSTRAINT(0xd2, 0xf), /* MEM_LOAD_UOPS_LLC_HIT_RETIRED.* */
+@@ -738,9 +738,9 @@ struct event_constraint intel_ivb_pebs_event_constraints[] = {
+ INTEL_PLD_CONSTRAINT(0x01cd, 0x8), /* MEM_TRANS_RETIRED.LAT_ABOVE_THR */
+ INTEL_PST_CONSTRAINT(0x02cd, 0x8), /* MEM_TRANS_RETIRED.PRECISE_STORES */
+ /* UOPS_RETIRED.ALL, inv=1, cmask=16 (cycles:p). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108001c2, 0xf),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108001c2, 0xf),
+ /* INST_RETIRED.PREC_DIST, inv=1, cmask=16 (cycles:ppp). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108001c0, 0x2),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108001c0, 0x2),
+ INTEL_EXCLEVT_CONSTRAINT(0xd0, 0xf), /* MEM_UOP_RETIRED.* */
+ INTEL_EXCLEVT_CONSTRAINT(0xd1, 0xf), /* MEM_LOAD_UOPS_RETIRED.* */
+ INTEL_EXCLEVT_CONSTRAINT(0xd2, 0xf), /* MEM_LOAD_UOPS_LLC_HIT_RETIRED.* */
+@@ -754,9 +754,9 @@ struct event_constraint intel_hsw_pebs_event_constraints[] = {
+ INTEL_FLAGS_UEVENT_CONSTRAINT(0x01c0, 0x2), /* INST_RETIRED.PRECDIST */
+ INTEL_PLD_CONSTRAINT(0x01cd, 0xf), /* MEM_TRANS_RETIRED.* */
+ /* UOPS_RETIRED.ALL, inv=1, cmask=16 (cycles:p). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108001c2, 0xf),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108001c2, 0xf),
+ /* INST_RETIRED.PREC_DIST, inv=1, cmask=16 (cycles:ppp). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108001c0, 0x2),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108001c0, 0x2),
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_NA(0x01c2, 0xf), /* UOPS_RETIRED.ALL */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_XLD(0x11d0, 0xf), /* MEM_UOPS_RETIRED.STLB_MISS_LOADS */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_XLD(0x21d0, 0xf), /* MEM_UOPS_RETIRED.LOCK_LOADS */
+@@ -777,9 +777,9 @@ struct event_constraint intel_bdw_pebs_event_constraints[] = {
+ INTEL_FLAGS_UEVENT_CONSTRAINT(0x01c0, 0x2), /* INST_RETIRED.PRECDIST */
+ INTEL_PLD_CONSTRAINT(0x01cd, 0xf), /* MEM_TRANS_RETIRED.* */
+ /* UOPS_RETIRED.ALL, inv=1, cmask=16 (cycles:p). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108001c2, 0xf),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108001c2, 0xf),
+ /* INST_RETIRED.PREC_DIST, inv=1, cmask=16 (cycles:ppp). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108001c0, 0x2),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108001c0, 0x2),
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_NA(0x01c2, 0xf), /* UOPS_RETIRED.ALL */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x11d0, 0xf), /* MEM_UOPS_RETIRED.STLB_MISS_LOADS */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x21d0, 0xf), /* MEM_UOPS_RETIRED.LOCK_LOADS */
+@@ -800,9 +800,9 @@ struct event_constraint intel_bdw_pebs_event_constraints[] = {
+ struct event_constraint intel_skl_pebs_event_constraints[] = {
+ INTEL_FLAGS_UEVENT_CONSTRAINT(0x1c0, 0x2), /* INST_RETIRED.PREC_DIST */
+ /* INST_RETIRED.PREC_DIST, inv=1, cmask=16 (cycles:ppp). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108001c0, 0x2),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108001c0, 0x2),
+ /* INST_RETIRED.TOTAL_CYCLES_PS (inv=1, cmask=16) (cycles:p). */
+- INTEL_FLAGS_EVENT_CONSTRAINT(0x108000c0, 0x0f),
++ INTEL_FLAGS_UEVENT_CONSTRAINT(0x108000c0, 0x0f),
+ INTEL_PLD_CONSTRAINT(0x1cd, 0xf), /* MEM_TRANS_RETIRED.* */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x11d0, 0xf), /* MEM_INST_RETIRED.STLB_MISS_LOADS */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x12d0, 0xf), /* MEM_INST_RETIRED.STLB_MISS_STORES */
+--
+2.20.1
+
--- /dev/null
+From 1eae201062ba92ba920ce7292d47644d64d7e73f Mon Sep 17 00:00:00 2001
+From: Varun Prakash <varun@chelsio.com>
+Date: Wed, 22 May 2019 20:10:55 +0530
+Subject: scsi: libcxgbi: add a check for NULL pointer in cxgbi_check_route()
+
+[ Upstream commit cc555759117e8349088e0c5d19f2f2a500bafdbd ]
+
+ip_dev_find() can return NULL so add a check for NULL pointer.
+
+Signed-off-by: Varun Prakash <varun@chelsio.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/cxgbi/libcxgbi.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
+index 2ffe029ff2b6..e974106f2bb5 100644
+--- a/drivers/scsi/cxgbi/libcxgbi.c
++++ b/drivers/scsi/cxgbi/libcxgbi.c
+@@ -637,6 +637,10 @@ static struct cxgbi_sock *cxgbi_check_route(struct sockaddr *dst_addr)
+
+ if (ndev->flags & IFF_LOOPBACK) {
+ ndev = ip_dev_find(&init_net, daddr->sin_addr.s_addr);
++ if (!ndev) {
++ err = -ENETUNREACH;
++ goto rel_neigh;
++ }
+ mtu = ndev->mtu;
+ pr_info("rt dev %s, loopback -> %s, mtu %u.\n",
+ n->dev->name, ndev->name, mtu);
+--
+2.20.1
+
--- /dev/null
+From db07072610dcc5870fe83794aefc47bc8c574352 Mon Sep 17 00:00:00 2001
+From: Jason Yan <yanaijie@huawei.com>
+Date: Tue, 14 May 2019 10:42:39 +0800
+Subject: scsi: libsas: delete sas port if expander discover failed
+
+[ Upstream commit 3b0541791453fbe7f42867e310e0c9eb6295364d ]
+
+The sas_port(phy->port) allocated in sas_ex_discover_expander() will not be
+deleted when the expander failed to discover. This will cause resource leak
+and a further issue of kernel BUG like below:
+
+[159785.843156] port-2:17:29: trying to add phy phy-2:17:29 fails: it's
+already part of another port
+[159785.852144] ------------[ cut here ]------------
+[159785.856833] kernel BUG at drivers/scsi/scsi_transport_sas.c:1086!
+[159785.863000] Internal error: Oops - BUG: 0 [#1] SMP
+[159785.867866] CPU: 39 PID: 16993 Comm: kworker/u96:2 Tainted: G
+W OE 4.19.25-vhulk1901.1.0.h111.aarch64 #1
+[159785.878458] Hardware name: Huawei Technologies Co., Ltd.
+Hi1620EVBCS/Hi1620EVBCS, BIOS Hi1620 CS B070 1P TA 03/21/2019
+[159785.889231] Workqueue: 0000:74:02.0_disco_q sas_discover_domain
+[159785.895224] pstate: 40c00009 (nZcv daif +PAN +UAO)
+[159785.900094] pc : sas_port_add_phy+0x188/0x1b8
+[159785.904524] lr : sas_port_add_phy+0x188/0x1b8
+[159785.908952] sp : ffff0001120e3b80
+[159785.912341] x29: ffff0001120e3b80 x28: 0000000000000000
+[159785.917727] x27: ffff802ade8f5400 x26: ffff0000681b7560
+[159785.923111] x25: ffff802adf11a800 x24: ffff0000680e8000
+[159785.928496] x23: ffff802ade8f5728 x22: ffff802ade8f5708
+[159785.933880] x21: ffff802adea2db40 x20: ffff802ade8f5400
+[159785.939264] x19: ffff802adea2d800 x18: 0000000000000010
+[159785.944649] x17: 00000000821bf734 x16: ffff00006714faa0
+[159785.950033] x15: ffff0000e8ab4ecf x14: 7261702079646165
+[159785.955417] x13: 726c612073277469 x12: ffff00006887b830
+[159785.960802] x11: ffff00006773eaa0 x10: 7968702079687020
+[159785.966186] x9 : 0000000000002453 x8 : 726f702072656874
+[159785.971570] x7 : 6f6e6120666f2074 x6 : ffff802bcfb21290
+[159785.976955] x5 : ffff802bcfb21290 x4 : 0000000000000000
+[159785.982339] x3 : ffff802bcfb298c8 x2 : 337752b234c2ab00
+[159785.987723] x1 : 337752b234c2ab00 x0 : 0000000000000000
+[159785.993108] Process kworker/u96:2 (pid: 16993, stack limit =
+0x0000000072dae094)
+[159786.000576] Call trace:
+[159786.003097] sas_port_add_phy+0x188/0x1b8
+[159786.007179] sas_ex_get_linkrate.isra.5+0x134/0x140
+[159786.012130] sas_ex_discover_expander+0x128/0x408
+[159786.016906] sas_ex_discover_dev+0x218/0x4c8
+[159786.021249] sas_ex_discover_devices+0x9c/0x1a8
+[159786.025852] sas_discover_root_expander+0x134/0x160
+[159786.030802] sas_discover_domain+0x1b8/0x1e8
+[159786.035148] process_one_work+0x1b4/0x3f8
+[159786.039230] worker_thread+0x54/0x470
+[159786.042967] kthread+0x134/0x138
+[159786.046269] ret_from_fork+0x10/0x18
+[159786.049918] Code: 91322300 f0004402 91178042 97fe4c9b (d4210000)
+[159786.056083] Modules linked in: hns3_enet_ut(OE) hclge(OE) hnae3(OE)
+hisi_sas_test_hw(OE) hisi_sas_test_main(OE) serdes(OE)
+[159786.067202] ---[ end trace 03622b9e2d99e196 ]---
+[159786.071893] Kernel panic - not syncing: Fatal exception
+[159786.077190] SMP: stopping secondary CPUs
+[159786.081192] Kernel Offset: disabled
+[159786.084753] CPU features: 0x2,a2a00a38
+
+Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
+Reported-by: Jian Luo <luojian5@huawei.com>
+Signed-off-by: Jason Yan <yanaijie@huawei.com>
+CC: John Garry <john.garry@huawei.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/libsas/sas_expander.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
+index ee1f9ee995e5..400eee9d7783 100644
+--- a/drivers/scsi/libsas/sas_expander.c
++++ b/drivers/scsi/libsas/sas_expander.c
+@@ -978,6 +978,8 @@ static struct domain_device *sas_ex_discover_expander(
+ list_del(&child->dev_list_node);
+ spin_unlock_irq(&parent->port->dev_list_lock);
+ sas_put_device(child);
++ sas_port_delete(phy->port);
++ phy->port = NULL;
+ return NULL;
+ }
+ list_add_tail(&child->siblings, &parent->ex_dev.children);
+--
+2.20.1
+
--- /dev/null
+From 8af4f278715a38581c2b2e9a360b150891da7f65 Mon Sep 17 00:00:00 2001
+From: Lianbo Jiang <lijiang@redhat.com>
+Date: Mon, 27 May 2019 08:59:34 +0800
+Subject: scsi: smartpqi: properly set both the DMA mask and the coherent DMA
+ mask
+
+[ Upstream commit 1d94f06e7f5df4064ef336b7b710f50143b64a53 ]
+
+When SME is enabled, the smartpqi driver won't work on the HP DL385 G10
+machine, which causes the failure of kernel boot because it fails to
+allocate pqi error buffer. Please refer to the kernel log:
+....
+[ 9.431749] usbcore: registered new interface driver uas
+[ 9.441524] Microsemi PQI Driver (v1.1.4-130)
+[ 9.442956] i40e 0000:04:00.0: fw 6.70.48768 api 1.7 nvm 10.2.5
+[ 9.447237] smartpqi 0000:23:00.0: Microsemi Smart Family Controller found
+ Starting dracut initqueue hook...
+[ OK ] Started Show Plymouth Boot Scre[ 9.471654] Broadcom NetXtreme-C/E driver bnxt_en v1.9.1
+en.
+[ OK ] Started Forward Password Requests to Plymouth Directory Watch.
+[[0;[ 9.487108] smartpqi 0000:23:00.0: failed to allocate PQI error buffer
+....
+[ 139.050544] dracut-initqueue[949]: Warning: dracut-initqueue timeout - starting timeout scripts
+[ 139.589779] dracut-initqueue[949]: Warning: dracut-initqueue timeout - starting timeout scripts
+
+Basically, the fact that the coherent DMA mask value wasn't set caused the
+driver to fall back to SWIOTLB when SME is active.
+
+For correct operation, lets call the dma_set_mask_and_coherent() to
+properly set the mask for both streaming and coherent, in order to inform
+the kernel about the devices DMA addressing capabilities.
+
+Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
+Acked-by: Don Brace <don.brace@microsemi.com>
+Tested-by: Don Brace <don.brace@microsemi.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/smartpqi/smartpqi_init.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c
+index 06a062455404..b12f7f952b70 100644
+--- a/drivers/scsi/smartpqi/smartpqi_init.c
++++ b/drivers/scsi/smartpqi/smartpqi_init.c
+@@ -5478,7 +5478,7 @@ static int pqi_pci_init(struct pqi_ctrl_info *ctrl_info)
+ else
+ mask = DMA_BIT_MASK(32);
+
+- rc = dma_set_mask(&ctrl_info->pci_dev->dev, mask);
++ rc = dma_set_mask_and_coherent(&ctrl_info->pci_dev->dev, mask);
+ if (rc) {
+ dev_err(&ctrl_info->pci_dev->dev, "failed to set DMA mask\n");
+ goto disable_device;
+--
+2.20.1
+
--- /dev/null
+From 4a26cb10864ea61698b4335d5ec8efbf950d2906 Mon Sep 17 00:00:00 2001
+From: Jeffrin Jose T <jeffrin@rajagiritech.edu.in>
+Date: Wed, 15 May 2019 12:14:04 +0530
+Subject: selftests: netfilter: missing error check when setting up veth
+ interface
+
+[ Upstream commit 82ce6eb1dd13fd12e449b2ee2c2ec051e6f52c43 ]
+
+A test for the basic NAT functionality uses ip command which needs veth
+device. There is a condition where the kernel support for veth is not
+compiled into the kernel and the test script breaks. This patch contains
+code for reasonable error display and correct code exit.
+
+Signed-off-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in>
+Acked-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/netfilter/nft_nat.sh | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/tools/testing/selftests/netfilter/nft_nat.sh b/tools/testing/selftests/netfilter/nft_nat.sh
+index 8ec76681605c..f25f72a75cf3 100755
+--- a/tools/testing/selftests/netfilter/nft_nat.sh
++++ b/tools/testing/selftests/netfilter/nft_nat.sh
+@@ -23,7 +23,11 @@ ip netns add ns0
+ ip netns add ns1
+ ip netns add ns2
+
+-ip link add veth0 netns ns0 type veth peer name eth0 netns ns1
++ip link add veth0 netns ns0 type veth peer name eth0 netns ns1 > /dev/null 2>&1
++if [ $? -ne 0 ];then
++ echo "SKIP: No virtual ethernet pair device support in kernel"
++ exit $ksft_skip
++fi
+ ip link add veth1 netns ns0 type veth peer name eth0 netns ns2
+
+ ip -net ns0 link set lo up
+--
+2.20.1
+
neigh-fix-use-after-free-read-in-pneigh_get_next.patch
sunhv-fix-device-naming-inconsistency-between-sunhv_console-and-sunhv_reg.patch
revert-staging-vc04_services-prevent-integer-overflow-in-create_pagelist.patch
+perf-x86-intel-ds-fix-event-vs.-uevent-pebs-constrai.patch
+selftests-netfilter-missing-error-check-when-setting.patch
+misdn-make-sure-device-name-is-nul-terminated.patch
+x86-cpu-amd-don-t-force-the-cpb-cap-when-running-und.patch
+perf-ring_buffer-fix-exposing-a-temporarily-decrease.patch
+perf-ring_buffer-add-ordering-to-rb-nest-increment.patch
+gpio-fix-gpio-adp5588-build-errors.patch
+net-tulip-de4x5-drop-redundant-module_device_table.patch
+i2c-dev-fix-potential-memory-leak-in-i2cdev_ioctl_rd.patch
+configfs-fix-use-after-free-when-accessing-sd-s_dent.patch
+perf-data-fix-strncat-may-truncate-build-failure-wit.patch
+perf-record-fix-s390-missing-module-symbol-and-warni.patch
+ia64-fix-build-errors-by-exporting-paddr_to_nid.patch
+kvm-ppc-book3s-use-new-mutex-to-synchronize-access-t.patch
+kvm-ppc-book3s-hv-don-t-take-kvm-lock-around-kvm_for.patch
+net-sh_eth-fix-mdio-access-in-sh_eth_close-for-r-car.patch
+scsi-libcxgbi-add-a-check-for-null-pointer-in-cxgbi_.patch
+scsi-smartpqi-properly-set-both-the-dma-mask-and-the.patch
+scsi-libsas-delete-sas-port-if-expander-discover-fai.patch
+mlxsw-spectrum-prevent-force-of-56g.patch
--- /dev/null
+From 049e9f718c9c61f6c56cc85ffe5283af9fa86e56 Mon Sep 17 00:00:00 2001
+From: Frank van der Linden <fllinden@amazon.com>
+Date: Wed, 22 May 2019 22:17:45 +0000
+Subject: x86/CPU/AMD: Don't force the CPB cap when running under a hypervisor
+
+[ Upstream commit 2ac44ab608705948564791ce1d15d43ba81a1e38 ]
+
+For F17h AMD CPUs, the CPB capability ('Core Performance Boost') is forcibly set,
+because some versions of that chip incorrectly report that they do not have it.
+
+However, a hypervisor may filter out the CPB capability, for good
+reasons. For example, KVM currently does not emulate setting the CPB
+bit in MSR_K7_HWCR, and unchecked MSR access errors will be thrown
+when trying to set it as a guest:
+
+ unchecked MSR access error: WRMSR to 0xc0010015 (tried to write 0x0000000001000011) at rIP: 0xffffffff890638f4 (native_write_msr+0x4/0x20)
+
+ Call Trace:
+ boost_set_msr+0x50/0x80 [acpi_cpufreq]
+ cpuhp_invoke_callback+0x86/0x560
+ sort_range+0x20/0x20
+ cpuhp_thread_fun+0xb0/0x110
+ smpboot_thread_fn+0xef/0x160
+ kthread+0x113/0x130
+ kthread_create_worker_on_cpu+0x70/0x70
+ ret_from_fork+0x35/0x40
+
+To avoid this issue, don't forcibly set the CPB capability for a CPU
+when running under a hypervisor.
+
+Signed-off-by: Frank van der Linden <fllinden@amazon.com>
+Acked-by: Borislav Petkov <bp@suse.de>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: bp@alien8.de
+Cc: jiaxun.yang@flygoat.com
+Fixes: 0237199186e7 ("x86/CPU/AMD: Set the CPB bit unconditionally on F17h")
+Link: http://lkml.kernel.org/r/20190522221745.GA15789@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com
+[ Minor edits to the changelog. ]
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/kernel/cpu/amd.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
+index be6d0543e626..52a65f14db06 100644
+--- a/arch/x86/kernel/cpu/amd.c
++++ b/arch/x86/kernel/cpu/amd.c
+@@ -766,8 +766,11 @@ static void init_amd_zn(struct cpuinfo_x86 *c)
+ {
+ set_cpu_cap(c, X86_FEATURE_ZEN);
+
+- /* Fix erratum 1076: CPB feature bit not being set in CPUID. */
+- if (!cpu_has(c, X86_FEATURE_CPB))
++ /*
++ * Fix erratum 1076: CPB feature bit not being set in CPUID.
++ * Always set it, except when running under a hypervisor.
++ */
++ if (!cpu_has(c, X86_FEATURE_HYPERVISOR) && !cpu_has(c, X86_FEATURE_CPB))
+ set_cpu_cap(c, X86_FEATURE_CPB);
+ }
+
+--
+2.20.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
