From: Greg Kroah-Hartman Date: Mon, 30 Jul 2018 12:16:07 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v4.17.12~13 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=34c89bcb61f6a33b0d27b826766ecc1b7454baac;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: ovl-sync-upper-dirty-data-when-syncing-overlayfs.patch pci-pciehp-assume-nocompl-for-thunderbolt-ports.patch pci-xgene-remove-leftover-pci_scan_child_bus-call.patch rdma-uverbs-protect-from-attempts-to-create-flows-on-unsupported-qp.patch usb-gadget-udc-renesas_usb3-should-remove-debugfs.patch --- diff --git a/queue-4.14/ovl-sync-upper-dirty-data-when-syncing-overlayfs.patch b/queue-4.14/ovl-sync-upper-dirty-data-when-syncing-overlayfs.patch new file mode 100644 index 00000000000..4b9d816e774 --- /dev/null +++ b/queue-4.14/ovl-sync-upper-dirty-data-when-syncing-overlayfs.patch @@ -0,0 +1,63 @@ +From e8d4bfe3a71537284a90561f77c85dea6c154369 Mon Sep 17 00:00:00 2001 +From: Chengguang Xu +Date: Wed, 29 Nov 2017 10:01:32 +0800 +Subject: ovl: Sync upper dirty data when syncing overlayfs + +From: Chengguang Xu + +commit e8d4bfe3a71537284a90561f77c85dea6c154369 upstream. + +When executing filesystem sync or umount on overlayfs, +dirty data does not get synced as expected on upper filesystem. +This patch fixes sync filesystem method to keep data consistency +for overlayfs. + +Signed-off-by: Chengguang Xu +Fixes: e593b2bf513d ("ovl: properly implement sync_filesystem()") +Cc: #4.11 +Signed-off-by: Miklos Szeredi +Signed-off-by: Sudip Mukherjee +Signed-off-by: Greg Kroah-Hartman +--- + fs/overlayfs/super.c | 19 +++++++++++++++---- + 1 file changed, 15 insertions(+), 4 deletions(-) + +--- a/fs/overlayfs/super.c ++++ b/fs/overlayfs/super.c +@@ -232,6 +232,7 @@ static void ovl_put_super(struct super_b + kfree(ufs); + } + ++/* Sync real dirty inodes in upper filesystem (if it exists) */ + static int ovl_sync_fs(struct super_block *sb, int wait) + { + struct ovl_fs *ufs = sb->s_fs_info; +@@ -240,14 +241,24 @@ static int ovl_sync_fs(struct super_bloc + + if (!ufs->upper_mnt) + return 0; +- upper_sb = ufs->upper_mnt->mnt_sb; +- if (!upper_sb->s_op->sync_fs) ++ ++ /* ++ * If this is a sync(2) call or an emergency sync, all the super blocks ++ * will be iterated, including upper_sb, so no need to do anything. ++ * ++ * If this is a syncfs(2) call, then we do need to call ++ * sync_filesystem() on upper_sb, but enough if we do it when being ++ * called with wait == 1. ++ */ ++ if (!wait) + return 0; + +- /* real inodes have already been synced by sync_filesystem(ovl_sb) */ ++ upper_sb = ufs->upper_mnt->mnt_sb; ++ + down_read(&upper_sb->s_umount); +- ret = upper_sb->s_op->sync_fs(upper_sb, wait); ++ ret = sync_filesystem(upper_sb); + up_read(&upper_sb->s_umount); ++ + return ret; + } + diff --git a/queue-4.14/pci-pciehp-assume-nocompl-for-thunderbolt-ports.patch b/queue-4.14/pci-pciehp-assume-nocompl-for-thunderbolt-ports.patch new file mode 100644 index 00000000000..2bc9c009296 --- /dev/null +++ b/queue-4.14/pci-pciehp-assume-nocompl-for-thunderbolt-ports.patch @@ -0,0 +1,80 @@ +From 493fb50e958c1c6deef7feff0b8c3855def78d75 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Wed, 17 Jan 2018 16:48:39 +0100 +Subject: PCI: pciehp: Assume NoCompl+ for Thunderbolt ports + +From: Lukas Wunner + +commit 493fb50e958c1c6deef7feff0b8c3855def78d75 upstream. + +Certain Thunderbolt 1 controllers claim to support Command Completed events +(value of 0b in the No Command Completed Support field of the Slot +Capabilities register) but in reality they neither set the Command +Completed bit in the Slot Status register nor signal a Command Completed +interrupt: + + 8086:1513 CV82524 [Light Ridge 4C 2010] + 8086:151a DSL2310 [Eagle Ridge 2C 2011] + 8086:151b CVL2510 [Light Peak 2C 2010] + 8086:1547 DSL3510 [Cactus Ridge 4C 2012] + 8086:1548 DSL3310 [Cactus Ridge 2C 2012] + 8086:1549 DSL2210 [Port Ridge 1C 2011] + +All known newer chips (Redwood Ridge and onwards) set No Command Completed +Support, indicating that they do not support Command Completed events. + +The user-visible impact is that after unplugging such a device, 2 seconds +elapse until pciehp is unbound. That's because on ->remove, +pcie_write_cmd() is called via pcie_disable_notification() and every call +to pcie_write_cmd() takes 2 seconds (1 second for each invocation of +pcie_wait_cmd()): + + [ 337.942727] pciehp 0000:0a:00.0:pcie204: Timeout on hotplug command 0x1038 (issued 21176 msec ago) + [ 340.014735] pciehp 0000:0a:00.0:pcie204: Timeout on hotplug command 0x0000 (issued 2072 msec ago) + +That by itself has always been unpleasant, but the situation has become +worse with commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during +shutdown"): Now pciehp is unbound on ->shutdown. Because Thunderbolt +controllers typically have 4 hotplug ports, every reboot and shutdown is +now delayed by 8 seconds, plus another 2 seconds for every attached +Thunderbolt 1 device. + +Thunderbolt hotplug slots are not physical slots that one inserts cards +into, but rather logical hotplug slots implemented in silicon. Devices +appear beyond those logical slots once a PCI tunnel is established on top +of the Thunderbolt Converged I/O switch. One would expect commands written +to the Slot Control register to be executed immediately by the silicon, so +for simplicity we always assume NoCompl+ for Thunderbolt ports. + +Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown") +Tested-by: Mika Westerberg +Signed-off-by: Lukas Wunner +Signed-off-by: Bjorn Helgaas +Reviewed-by: Mika Westerberg +Cc: stable@vger.kernel.org # v4.12+ +Cc: Sinan Kaya +Cc: Yehezkel Bernat +Cc: Michael Jamet +Cc: Andreas Noever +Signed-off-by: Sudip Mukherjee +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/hotplug/pciehp_hpc.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/pci/hotplug/pciehp_hpc.c ++++ b/drivers/pci/hotplug/pciehp_hpc.c +@@ -863,6 +863,13 @@ struct controller *pcie_init(struct pcie + if (pdev->hotplug_user_indicators) + slot_cap &= ~(PCI_EXP_SLTCAP_AIP | PCI_EXP_SLTCAP_PIP); + ++ /* ++ * We assume no Thunderbolt controllers support Command Complete events, ++ * but some controllers falsely claim they do. ++ */ ++ if (pdev->is_thunderbolt) ++ slot_cap |= PCI_EXP_SLTCAP_NCCS; ++ + ctrl->slot_cap = slot_cap; + mutex_init(&ctrl->ctrl_lock); + init_waitqueue_head(&ctrl->queue); diff --git a/queue-4.14/pci-xgene-remove-leftover-pci_scan_child_bus-call.patch b/queue-4.14/pci-xgene-remove-leftover-pci_scan_child_bus-call.patch new file mode 100644 index 00000000000..7dda7cb673f --- /dev/null +++ b/queue-4.14/pci-xgene-remove-leftover-pci_scan_child_bus-call.patch @@ -0,0 +1,41 @@ +From 94b9d290b753cbbc87971ee134511245f5872a83 Mon Sep 17 00:00:00 2001 +From: Lorenzo Pieralisi +Date: Tue, 21 Nov 2017 15:49:31 +0000 +Subject: PCI: xgene: Remove leftover pci_scan_child_bus() call + +From: Lorenzo Pieralisi + +commit 94b9d290b753cbbc87971ee134511245f5872a83 upstream. + +The changes in commit 9af275be15f7 ("PCI: xgene: Convert PCI scan API to +pci_scan_root_bus_bridge()") converted the xgene PCI host driver to +the new pci_scan_root_bus_bridge() bus scanning API but erroneously left +the existing pci_scan_child_bus() call in place which resulted in duplicate +PCI bus enumerations. + +Remove the leftover pci_scan_child_bus() call to properly complete the API +conversion. + +Fixes: 9af275be15f7 ("PCI: xgene: Convert PCI scan API to pci_scan_root_bus_bridge()") +Tested-by: Khuong Dinh +Signed-off-by: Lorenzo Pieralisi +Cc: # 4.13+ +Cc: Bjorn Helgaas +Cc: Tanmay Inamdar +Signed-off-by: Sudip Mukherjee +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/host/pci-xgene.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/pci/host/pci-xgene.c ++++ b/drivers/pci/host/pci-xgene.c +@@ -686,7 +686,6 @@ static int xgene_pcie_probe_bridge(struc + + bus = bridge->bus; + +- pci_scan_child_bus(bus); + pci_assign_unassigned_bus_resources(bus); + list_for_each_entry(child, &bus->children, node) + pcie_bus_configure_settings(child); diff --git a/queue-4.14/rdma-uverbs-protect-from-attempts-to-create-flows-on-unsupported-qp.patch b/queue-4.14/rdma-uverbs-protect-from-attempts-to-create-flows-on-unsupported-qp.patch new file mode 100644 index 00000000000..c3e2b7e461c --- /dev/null +++ b/queue-4.14/rdma-uverbs-protect-from-attempts-to-create-flows-on-unsupported-qp.patch @@ -0,0 +1,44 @@ +From 940efcc8889f0d15567eb07fc9fd69b06e366aa5 Mon Sep 17 00:00:00 2001 +From: Leon Romanovsky +Date: Sun, 24 Jun 2018 11:23:42 +0300 +Subject: RDMA/uverbs: Protect from attempts to create flows on unsupported QP + +From: Leon Romanovsky + +commit 940efcc8889f0d15567eb07fc9fd69b06e366aa5 upstream. + +Flows can be created on UD and RAW_PACKET QP types. Attempts to provide +other QP types as an input causes to various unpredictable failures. + +The reason is that in order to support all various types (e.g. XRC), we +are supposed to use real_qp handle and not qp handle and expect to +driver/FW to fail such (XRC) flows. The simpler and safer variant is to +ban all QP types except UD and RAW_PACKET, instead of relying on +driver/FW. + +Cc: # 3.11 +Fixes: 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow through uverbs") +Cc: syzkaller +Reported-by: Noa Osherovich +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Sudip Mukherjee +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/core/uverbs_cmd.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/infiniband/core/uverbs_cmd.c ++++ b/drivers/infiniband/core/uverbs_cmd.c +@@ -3376,6 +3376,11 @@ int ib_uverbs_ex_create_flow(struct ib_u + goto err_uobj; + } + ++ if (qp->qp_type != IB_QPT_UD && qp->qp_type != IB_QPT_RAW_PACKET) { ++ err = -EINVAL; ++ goto err_put; ++ } ++ + flow_attr = kzalloc(sizeof(*flow_attr) + cmd.flow_attr.num_of_specs * + sizeof(union ib_flow_spec), GFP_KERNEL); + if (!flow_attr) { diff --git a/queue-4.14/series b/queue-4.14/series index 9e30f7a83e8..1e4d9e962b9 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -146,7 +146,6 @@ nvmem-properly-handle-returned-value-nvmem_reg_read.patch i40e-free-the-skb-after-clearing-the-bitlock.patch tty-fix-data-race-in-tty_insert_flip_string_fixed_flag.patch dma-iommu-fix-compilation-when-config_iommu_dma.patch -tick-prefer-a-lower-rating-device-only-if-it-s-cpu-local-device.patch net-phy-phylink-release-link-gpio.patch media-rcar_jpu-add-missing-clk_disable_unprepare-on-error-in-jpu_open.patch libata-fix-command-retry-decision.patch @@ -222,3 +221,8 @@ squashfs-be-more-careful-about-metadata-corruption.patch ext4-fix-inline-data-updates-with-checksums-enabled.patch ext4-check-for-allocation-block-validity-with-block-group-locked.patch ext4-fix-check-to-prevent-initializing-reserved-inodes.patch +pci-pciehp-assume-nocompl-for-thunderbolt-ports.patch +pci-xgene-remove-leftover-pci_scan_child_bus-call.patch +ovl-sync-upper-dirty-data-when-syncing-overlayfs.patch +usb-gadget-udc-renesas_usb3-should-remove-debugfs.patch +rdma-uverbs-protect-from-attempts-to-create-flows-on-unsupported-qp.patch diff --git a/queue-4.14/tick-prefer-a-lower-rating-device-only-if-it-s-cpu-local-device.patch b/queue-4.14/tick-prefer-a-lower-rating-device-only-if-it-s-cpu-local-device.patch deleted file mode 100644 index b33b431f74c..00000000000 --- a/queue-4.14/tick-prefer-a-lower-rating-device-only-if-it-s-cpu-local-device.patch +++ /dev/null @@ -1,40 +0,0 @@ -From foo@baz Sat Jul 28 10:25:26 CEST 2018 -From: Sudeep Holla -Date: Wed, 9 May 2018 17:02:08 +0100 -Subject: tick: Prefer a lower rating device only if it's CPU local device - -From: Sudeep Holla - -[ Upstream commit 1332a90558013ae4242e3dd7934bdcdeafb06c0d ] - -Checking the equality of cpumask for both new and old tick device doesn't -ensure that it's CPU local device. This will cause issue if a low rating -clockevent tick device is registered first followed by the registration -of higher rating clockevent tick device. - -In such case, clockevents_released list will never get emptied as both -the devices get selected as preferred one and we will loop forever in -clockevents_notify_released. - -Signed-off-by: Sudeep Holla -Signed-off-by: Thomas Gleixner -Cc: Frederic Weisbecker -Link: https://lkml.kernel.org/r/1525881728-4858-1-git-send-email-sudeep.holla@arm.com -Signed-off-by: Sasha Levin -Signed-off-by: Greg Kroah-Hartman ---- - kernel/time/tick-common.c | 3 ++- - 1 file changed, 2 insertions(+), 1 deletion(-) - ---- a/kernel/time/tick-common.c -+++ b/kernel/time/tick-common.c -@@ -277,7 +277,8 @@ static bool tick_check_preferred(struct - */ - return !curdev || - newdev->rating > curdev->rating || -- !cpumask_equal(curdev->cpumask, newdev->cpumask); -+ (!cpumask_equal(curdev->cpumask, newdev->cpumask) && -+ !tick_check_percpu(curdev, newdev, smp_processor_id())); - } - - /* diff --git a/queue-4.14/usb-gadget-udc-renesas_usb3-should-remove-debugfs.patch b/queue-4.14/usb-gadget-udc-renesas_usb3-should-remove-debugfs.patch new file mode 100644 index 00000000000..84fde61d95f --- /dev/null +++ b/queue-4.14/usb-gadget-udc-renesas_usb3-should-remove-debugfs.patch @@ -0,0 +1,54 @@ +From 1990cf7c21ea185cec98c6d45a82c04481261e35 Mon Sep 17 00:00:00 2001 +From: Yoshihiro Shimoda +Date: Tue, 10 Apr 2018 14:38:50 +0900 +Subject: usb: gadget: udc: renesas_usb3: should remove debugfs + +From: Yoshihiro Shimoda + +commit 1990cf7c21ea185cec98c6d45a82c04481261e35 upstream. + +This patch fixes an issue that this driver doesn't remove its debugfs. + +Fixes: 43ba968b00ea ("usb: gadget: udc: renesas_usb3: add debugfs to set the b-device mode") +Cc: # v4.14+ +Signed-off-by: Yoshihiro Shimoda +Reviewed-by: Simon Horman +Signed-off-by: Felipe Balbi +Signed-off-by: Sudip Mukherjee +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/gadget/udc/renesas_usb3.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/usb/gadget/udc/renesas_usb3.c ++++ b/drivers/usb/gadget/udc/renesas_usb3.c +@@ -334,6 +334,7 @@ struct renesas_usb3 { + struct usb_gadget_driver *driver; + struct extcon_dev *extcon; + struct work_struct extcon_work; ++ struct dentry *dentry; + + struct renesas_usb3_ep *usb3_ep; + int num_usb3_eps; +@@ -2397,8 +2398,12 @@ static void renesas_usb3_debugfs_init(st + + file = debugfs_create_file("b_device", 0644, root, usb3, + &renesas_usb3_b_device_fops); +- if (!file) ++ if (!file) { + dev_info(dev, "%s: Can't create debugfs mode\n", __func__); ++ debugfs_remove_recursive(root); ++ } else { ++ usb3->dentry = root; ++ } + } + + /*------- platform_driver ------------------------------------------------*/ +@@ -2406,6 +2411,7 @@ static int renesas_usb3_remove(struct pl + { + struct renesas_usb3 *usb3 = platform_get_drvdata(pdev); + ++ debugfs_remove_recursive(usb3->dentry); + device_remove_file(&pdev->dev, &dev_attr_role); + + usb_del_gadget_udc(&usb3->gadget);