From dd388b06e958fc5b4f497f9d802bcda8169621c4 Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Wed, 19 Jun 2019 20:06:58 -0400 Subject: [PATCH] fixes for 4.4 Signed-off-by: Sasha Levin --- ...-after-free-when-accessing-sd-s_dent.patch | 58 ++++++++ .../gpio-fix-gpio-adp5588-build-errors.patch | 54 ++++++++ ...ntial-memory-leak-in-i2cdev_ioctl_rd.patch | 33 +++++ ...ild-errors-by-exporting-paddr_to_nid.patch | 58 ++++++++ ...se-new-mutex-to-synchronize-access-t.patch | 125 ++++++++++++++++++ ...e-sure-device-name-is-nul-terminated.patch | 56 ++++++++ ...dio-access-in-sh_eth_close-for-r-car.patch | 51 +++++++ ...5-drop-redundant-module_device_table.patch | 54 ++++++++ ...er-add-ordering-to-rb-nest-increment.patch | 60 +++++++++ ...-fix-exposing-a-temporarily-decrease.patch | 97 ++++++++++++++ ...d-a-check-for-null-pointer-in-cxgbi_.patch | 34 +++++ ...te-sas-port-if-expander-discover-fai.patch | 89 +++++++++++++ queue-4.4/series | 13 ++ ...t-force-the-cpb-cap-when-running-und.patch | 68 ++++++++++ 14 files changed, 850 insertions(+) create mode 100644 queue-4.4/configfs-fix-use-after-free-when-accessing-sd-s_dent.patch create mode 100644 queue-4.4/gpio-fix-gpio-adp5588-build-errors.patch create mode 100644 queue-4.4/i2c-dev-fix-potential-memory-leak-in-i2cdev_ioctl_rd.patch create mode 100644 queue-4.4/ia64-fix-build-errors-by-exporting-paddr_to_nid.patch create mode 100644 queue-4.4/kvm-ppc-book3s-use-new-mutex-to-synchronize-access-t.patch create mode 100644 queue-4.4/misdn-make-sure-device-name-is-nul-terminated.patch create mode 100644 queue-4.4/net-sh_eth-fix-mdio-access-in-sh_eth_close-for-r-car.patch create mode 100644 queue-4.4/net-tulip-de4x5-drop-redundant-module_device_table.patch create mode 100644 queue-4.4/perf-ring_buffer-add-ordering-to-rb-nest-increment.patch create mode 100644 queue-4.4/perf-ring_buffer-fix-exposing-a-temporarily-decrease.patch create mode 100644 queue-4.4/scsi-libcxgbi-add-a-check-for-null-pointer-in-cxgbi_.patch create mode 100644 queue-4.4/scsi-libsas-delete-sas-port-if-expander-discover-fai.patch create mode 100644 queue-4.4/x86-cpu-amd-don-t-force-the-cpb-cap-when-running-und.patch diff --git a/queue-4.4/configfs-fix-use-after-free-when-accessing-sd-s_dent.patch b/queue-4.4/configfs-fix-use-after-free-when-accessing-sd-s_dent.patch new file mode 100644 index 0000000000..4b67e315c6 --- /dev/null +++ b/queue-4.4/configfs-fix-use-after-free-when-accessing-sd-s_dent.patch @@ -0,0 +1,58 @@ +From 319b11cb0c6fcc13f33b21d8fc27ea17e9f1fec5 Mon Sep 17 00:00:00 2001 +From: Sahitya Tummala +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 +Signed-off-by: Christoph Hellwig +Signed-off-by: Sasha Levin +--- + 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 a7a1b218f308..8e709b641b55 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 + diff --git a/queue-4.4/gpio-fix-gpio-adp5588-build-errors.patch b/queue-4.4/gpio-fix-gpio-adp5588-build-errors.patch new file mode 100644 index 0000000000..40b989d80b --- /dev/null +++ b/queue-4.4/gpio-fix-gpio-adp5588-build-errors.patch @@ -0,0 +1,54 @@ +From 36cfcbda69850e8c715bd0b551b726682c46410f Mon Sep 17 00:00:00 2001 +From: Randy Dunlap +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 +Signed-off-by: Randy Dunlap +Cc: linux-gpio@vger.kernel.org +Reviewed-by: Bartosz Golaszewski +Acked-by: Michael Hennerich +Signed-off-by: Linus Walleij +Signed-off-by: Sasha Levin +--- + drivers/gpio/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig +index 469dc378adeb..aaae6040b4c8 100644 +--- a/drivers/gpio/Kconfig ++++ b/drivers/gpio/Kconfig +@@ -579,6 +579,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 + diff --git a/queue-4.4/i2c-dev-fix-potential-memory-leak-in-i2cdev_ioctl_rd.patch b/queue-4.4/i2c-dev-fix-potential-memory-leak-in-i2cdev_ioctl_rd.patch new file mode 100644 index 0000000000..04ed1d9f32 --- /dev/null +++ b/queue-4.4/i2c-dev-fix-potential-memory-leak-in-i2cdev_ioctl_rd.patch @@ -0,0 +1,33 @@ +From 61d5c0503ff1e93e828a990d178c5ac967370faa Mon Sep 17 00:00:00 2001 +From: Yingjoe Chen +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 +Signed-off-by: Wolfram Sang +Signed-off-by: Sasha Levin +--- + 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 57e3790c87b1..e56b774e7cf9 100644 +--- a/drivers/i2c/i2c-dev.c ++++ b/drivers/i2c/i2c-dev.c +@@ -295,6 +295,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 + diff --git a/queue-4.4/ia64-fix-build-errors-by-exporting-paddr_to_nid.patch b/queue-4.4/ia64-fix-build-errors-by-exporting-paddr_to_nid.patch new file mode 100644 index 0000000000..63a34a8385 --- /dev/null +++ b/queue-4.4/ia64-fix-build-errors-by-exporting-paddr_to_nid.patch @@ -0,0 +1,58 @@ +From c7ae0c1c52c26dd3b47d7a9ac7aed1dc5815742f Mon Sep 17 00:00:00 2001 +From: Randy Dunlap +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 +Signed-off-by: Randy Dunlap +Cc: Tony Luck +Cc: Fenghua Yu +Cc: linux-ia64@vger.kernel.org +Signed-off-by: Tony Luck +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/kvm-ppc-book3s-use-new-mutex-to-synchronize-access-t.patch b/queue-4.4/kvm-ppc-book3s-use-new-mutex-to-synchronize-access-t.patch new file mode 100644 index 0000000000..ef52783a0d --- /dev/null +++ b/queue-4.4/kvm-ppc-book3s-use-new-mutex-to-synchronize-access-t.patch @@ -0,0 +1,125 @@ +From c02e2824815699284ebe609881871fa1a87affa3 Mon Sep 17 00:00:00 2001 +From: Paul Mackerras +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 +Signed-off-by: Sasha Levin +--- + 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 a92d95aee42d..1883627eb12c 100644 +--- a/arch/powerpc/include/asm/kvm_host.h ++++ b/arch/powerpc/include/asm/kvm_host.h +@@ -250,6 +250,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 099c79d8c160..4aab1c9c83e1 100644 +--- a/arch/powerpc/kvm/book3s.c ++++ b/arch/powerpc/kvm/book3s.c +@@ -809,6 +809,7 @@ int kvmppc_core_init_vm(struct kvm *kvm) + #ifdef CONFIG_PPC64 + INIT_LIST_HEAD(&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 + diff --git a/queue-4.4/misdn-make-sure-device-name-is-nul-terminated.patch b/queue-4.4/misdn-make-sure-device-name-is-nul-terminated.patch new file mode 100644 index 0000000000..f8afb50ac0 --- /dev/null +++ b/queue-4.4/misdn-make-sure-device-name-is-nul-terminated.patch @@ -0,0 +1,56 @@ +From 79b4d07c2b456146a18c361416a9b74a447375a9 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 0d29b5a6356d..8cbb75d09a1d 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 + diff --git a/queue-4.4/net-sh_eth-fix-mdio-access-in-sh_eth_close-for-r-car.patch b/queue-4.4/net-sh_eth-fix-mdio-access-in-sh_eth_close-for-r-car.patch new file mode 100644 index 0000000000..97ca16e51c --- /dev/null +++ b/queue-4.4/net-sh_eth-fix-mdio-access-in-sh_eth_close-for-r-car.patch @@ -0,0 +1,51 @@ +From 780b76b0e5ac342961ec8439d02814383dbc68d1 Mon Sep 17 00:00:00 2001 +From: Yoshihiro Shimoda +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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 afaf79b8761f..2d9f4ed9a65e 100644 +--- a/drivers/net/ethernet/renesas/sh_eth.c ++++ b/drivers/net/ethernet/renesas/sh_eth.c +@@ -1408,6 +1408,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 + diff --git a/queue-4.4/net-tulip-de4x5-drop-redundant-module_device_table.patch b/queue-4.4/net-tulip-de4x5-drop-redundant-module_device_table.patch new file mode 100644 index 0000000000..8bb2d86903 --- /dev/null +++ b/queue-4.4/net-tulip-de4x5-drop-redundant-module_device_table.patch @@ -0,0 +1,54 @@ +From ad05cfe9d38eef5af2ff74c84c6d554e40a9bbbc Mon Sep 17 00:00:00 2001 +From: Kees Cook +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 \ + ^ +: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 \ + ^ +: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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 3acde3b9b767..7799cf33cc6e 100644 +--- a/drivers/net/ethernet/dec/tulip/de4x5.c ++++ b/drivers/net/ethernet/dec/tulip/de4x5.c +@@ -2106,7 +2106,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 + diff --git a/queue-4.4/perf-ring_buffer-add-ordering-to-rb-nest-increment.patch b/queue-4.4/perf-ring_buffer-add-ordering-to-rb-nest-increment.patch new file mode 100644 index 0000000000..0e7473ece3 --- /dev/null +++ b/queue-4.4/perf-ring_buffer-add-ordering-to-rb-nest-increment.patch @@ -0,0 +1,60 @@ +From aac6a6e89be07d98ba180c87e757313e4c1fa447 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +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 +Signed-off-by: Peter Zijlstra (Intel) +Cc: Alexander Shishkin +Cc: Arnaldo Carvalho de Melo +Cc: Jiri Olsa +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Stephane Eranian +Cc: Thomas Gleixner +Cc: Vince Weaver +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 +Signed-off-by: Sasha Levin +--- + 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 70e31c48ae9b..410f83cad06c 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 + diff --git a/queue-4.4/perf-ring_buffer-fix-exposing-a-temporarily-decrease.patch b/queue-4.4/perf-ring_buffer-fix-exposing-a-temporarily-decrease.patch new file mode 100644 index 0000000000..83a705cf3c --- /dev/null +++ b/queue-4.4/perf-ring_buffer-fix-exposing-a-temporarily-decrease.patch @@ -0,0 +1,97 @@ +From ca50d7785feb5b493c3f1e18bb551e1b6e436ef7 Mon Sep 17 00:00:00 2001 +From: Yabin Cui +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 +Signed-off-by: Peter Zijlstra (Intel) +Cc: Alexander Shishkin +Cc: Arnaldo Carvalho de Melo +Cc: Arnaldo Carvalho de Melo +Cc: Jiri Olsa +Cc: Linus Torvalds +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Stephane Eranian +Cc: Thomas Gleixner +Cc: Vince Weaver +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 +Signed-off-by: Sasha Levin +--- + 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 7324d83d6bd8..70e31c48ae9b 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 + diff --git a/queue-4.4/scsi-libcxgbi-add-a-check-for-null-pointer-in-cxgbi_.patch b/queue-4.4/scsi-libcxgbi-add-a-check-for-null-pointer-in-cxgbi_.patch new file mode 100644 index 0000000000..55bec96ee5 --- /dev/null +++ b/queue-4.4/scsi-libcxgbi-add-a-check-for-null-pointer-in-cxgbi_.patch @@ -0,0 +1,34 @@ +From ebd5dfd2d41d9a25294b8ed590d8d8104b06b5f7 Mon Sep 17 00:00:00 2001 +From: Varun Prakash +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 +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + 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 f3bb7af4e984..5eaf14c15590 100644 +--- a/drivers/scsi/cxgbi/libcxgbi.c ++++ b/drivers/scsi/cxgbi/libcxgbi.c +@@ -634,6 +634,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 + diff --git a/queue-4.4/scsi-libsas-delete-sas-port-if-expander-discover-fai.patch b/queue-4.4/scsi-libsas-delete-sas-port-if-expander-discover-fai.patch new file mode 100644 index 0000000000..66d6174c50 --- /dev/null +++ b/queue-4.4/scsi-libsas-delete-sas-port-if-expander-discover-fai.patch @@ -0,0 +1,89 @@ +From 2265765f2f0dcc8666aa8880e09c5cda529837d7 Mon Sep 17 00:00:00 2001 +From: Jason Yan +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 +Signed-off-by: Jason Yan +CC: John Garry +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/series b/queue-4.4/series index 1b2796f5e7..d81effea83 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -66,3 +66,16 @@ ipv6-flowlabel-fl6_sock_lookup-must-use-atomic_inc_not_zero.patch lapb-fixed-leak-of-control-blocks.patch neigh-fix-use-after-free-read-in-pneigh_get_next.patch sunhv-fix-device-naming-inconsistency-between-sunhv_console-and-sunhv_reg.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 +ia64-fix-build-errors-by-exporting-paddr_to_nid.patch +kvm-ppc-book3s-use-new-mutex-to-synchronize-access-t.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-libsas-delete-sas-port-if-expander-discover-fai.patch diff --git a/queue-4.4/x86-cpu-amd-don-t-force-the-cpb-cap-when-running-und.patch b/queue-4.4/x86-cpu-amd-don-t-force-the-cpb-cap-when-running-und.patch new file mode 100644 index 0000000000..0a5d44262b --- /dev/null +++ b/queue-4.4/x86-cpu-amd-don-t-force-the-cpb-cap-when-running-und.patch @@ -0,0 +1,68 @@ +From a234ba1195013b23cf39057ab619597632cd72a1 Mon Sep 17 00:00:00 2001 +From: Frank van der Linden +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 +Acked-by: Borislav Petkov +Cc: Andy Lutomirski +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +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 +Signed-off-by: Sasha Levin +--- + 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 e94e6f16172b..6f2483292de0 100644 +--- a/arch/x86/kernel/cpu/amd.c ++++ b/arch/x86/kernel/cpu/amd.c +@@ -717,8 +717,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 + -- 2.39.2