From: Greg Kroah-Hartman Date: Thu, 11 May 2017 12:19:12 +0000 (+0200) Subject: 4.11-stable patches X-Git-Tag: v4.4.68~19 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=7560eced63fa9415aec1e22f68a22f80866929f2;p=thirdparty%2Fkernel%2Fstable-queue.git 4.11-stable patches added patches: f2fs-sanity-check-segment-count.patch xen-arm-arm64-fix-xen_dma_ops-after-815dd18-consolidate-get_dma_ops.patch xen-revert-commits-da72ff5bfcb0-and-72a9b186292d.patch --- diff --git a/queue-4.11/f2fs-sanity-check-segment-count.patch b/queue-4.11/f2fs-sanity-check-segment-count.patch new file mode 100644 index 00000000000..897d7fe89a5 --- /dev/null +++ b/queue-4.11/f2fs-sanity-check-segment-count.patch @@ -0,0 +1,52 @@ +From b9dd46188edc2f0d1f37328637860bb65a771124 Mon Sep 17 00:00:00 2001 +From: Jin Qian +Date: Tue, 25 Apr 2017 16:28:48 -0700 +Subject: f2fs: sanity check segment count + +From: Jin Qian + +commit b9dd46188edc2f0d1f37328637860bb65a771124 upstream. + +F2FS uses 4 bytes to represent block address. As a result, supported +size of disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments. + +Signed-off-by: Jin Qian +Signed-off-by: Jaegeuk Kim +Signed-off-by: Greg Kroah-Hartman + +--- + fs/f2fs/super.c | 7 +++++++ + include/linux/f2fs_fs.h | 6 ++++++ + 2 files changed, 13 insertions(+) + +--- a/fs/f2fs/super.c ++++ b/fs/f2fs/super.c +@@ -1483,6 +1483,13 @@ static int sanity_check_raw_super(struct + return 1; + } + ++ if (le32_to_cpu(raw_super->segment_count) > F2FS_MAX_SEGMENT) { ++ f2fs_msg(sb, KERN_INFO, ++ "Invalid segment count (%u)", ++ le32_to_cpu(raw_super->segment_count)); ++ return 1; ++ } ++ + /* check CP/SIT/NAT/SSA/MAIN_AREA area boundary */ + if (sanity_check_area_boundary(sbi, bh)) + return 1; +--- a/include/linux/f2fs_fs.h ++++ b/include/linux/f2fs_fs.h +@@ -302,6 +302,12 @@ struct f2fs_nat_block { + #define SIT_ENTRY_PER_BLOCK (PAGE_SIZE / sizeof(struct f2fs_sit_entry)) + + /* ++ * F2FS uses 4 bytes to represent block address. As a result, supported size of ++ * disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments. ++ */ ++#define F2FS_MAX_SEGMENT ((16 * 1024 * 1024) / 2) ++ ++/* + * Note that f2fs_sit_entry->vblocks has the following bit-field information. + * [15:10] : allocation type such as CURSEG_XXXX_TYPE + * [9:0] : valid block count diff --git a/queue-4.11/series b/queue-4.11/series index 61c82b39ffa..0d51e7a956d 100644 --- a/queue-4.11/series +++ b/queue-4.11/series @@ -22,3 +22,6 @@ tcp-randomize-timestamps-on-syncookies.patch bnxt_en-allocate-enough-space-for-ntp_fltr_bmap.patch bpf-don-t-let-ldimm64-leak-map-addresses-on-unprivileged.patch net-mdio-mux-bcm-iproc-call-mdiobus_free-in-error-path.patch +f2fs-sanity-check-segment-count.patch +xen-arm-arm64-fix-xen_dma_ops-after-815dd18-consolidate-get_dma_ops.patch +xen-revert-commits-da72ff5bfcb0-and-72a9b186292d.patch diff --git a/queue-4.11/xen-arm-arm64-fix-xen_dma_ops-after-815dd18-consolidate-get_dma_ops.patch b/queue-4.11/xen-arm-arm64-fix-xen_dma_ops-after-815dd18-consolidate-get_dma_ops.patch new file mode 100644 index 00000000000..57c15a791bd --- /dev/null +++ b/queue-4.11/xen-arm-arm64-fix-xen_dma_ops-after-815dd18-consolidate-get_dma_ops.patch @@ -0,0 +1,176 @@ +From e058632670b709145730a134acc3f83f392f7aa7 Mon Sep 17 00:00:00 2001 +From: Stefano Stabellini +Date: Thu, 13 Apr 2017 14:04:21 -0700 +Subject: xen/arm,arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..." + +From: Stefano Stabellini + +commit e058632670b709145730a134acc3f83f392f7aa7 upstream. + +The following commit: + + commit 815dd18788fe0d41899f51b91d0560279cf16b0d + Author: Bart Van Assche + Date: Fri Jan 20 13:04:04 2017 -0800 + + treewide: Consolidate get_dma_ops() implementations + +rearranges get_dma_ops in a way that xen_dma_ops are not returned when +running on Xen anymore, dev->dma_ops is returned instead (see +arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and +include/linux/dma-mapping.h:get_dma_ops). + +Fix the problem by storing dev->dma_ops in dev_archdata, and setting +dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally +by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from +dev_archdata when needed. It also allows us to remove __generic_dma_ops +from common headers. + +Signed-off-by: Stefano Stabellini +Tested-by: Julien Grall +Suggested-by: Catalin Marinas +Reviewed-by: Catalin Marinas +CC: linux@armlinux.org.uk +CC: catalin.marinas@arm.com +CC: will.deacon@arm.com +CC: boris.ostrovsky@oracle.com +CC: jgross@suse.com +CC: Julien Grall +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/include/asm/device.h | 3 +++ + arch/arm/include/asm/dma-mapping.h | 12 +----------- + arch/arm/mm/dma-mapping.c | 7 +++++++ + arch/arm64/include/asm/device.h | 3 +++ + arch/arm64/include/asm/dma-mapping.h | 13 +------------ + arch/arm64/mm/dma-mapping.c | 7 +++++++ + include/xen/arm/page-coherent.h | 8 ++++++++ + 7 files changed, 30 insertions(+), 23 deletions(-) + +--- a/arch/arm/include/asm/device.h ++++ b/arch/arm/include/asm/device.h +@@ -16,6 +16,9 @@ struct dev_archdata { + #ifdef CONFIG_ARM_DMA_USE_IOMMU + struct dma_iommu_mapping *mapping; + #endif ++#ifdef CONFIG_XEN ++ const struct dma_map_ops *dev_dma_ops; ++#endif + bool dma_coherent; + }; + +--- a/arch/arm/include/asm/dma-mapping.h ++++ b/arch/arm/include/asm/dma-mapping.h +@@ -16,19 +16,9 @@ + extern const struct dma_map_ops arm_dma_ops; + extern const struct dma_map_ops arm_coherent_dma_ops; + +-static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev) +-{ +- if (dev && dev->dma_ops) +- return dev->dma_ops; +- return &arm_dma_ops; +-} +- + static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus) + { +- if (xen_initial_domain()) +- return xen_dma_ops; +- else +- return __generic_dma_ops(NULL); ++ return &arm_dma_ops; + } + + #define HAVE_ARCH_DMA_SUPPORTED 1 +--- a/arch/arm/mm/dma-mapping.c ++++ b/arch/arm/mm/dma-mapping.c +@@ -2414,6 +2414,13 @@ void arch_setup_dma_ops(struct device *d + dma_ops = arm_get_dma_map_ops(coherent); + + set_dma_ops(dev, dma_ops); ++ ++#ifdef CONFIG_XEN ++ if (xen_initial_domain()) { ++ dev->archdata.dev_dma_ops = dev->dma_ops; ++ dev->dma_ops = xen_dma_ops; ++ } ++#endif + } + + void arch_teardown_dma_ops(struct device *dev) +--- a/arch/arm64/include/asm/device.h ++++ b/arch/arm64/include/asm/device.h +@@ -20,6 +20,9 @@ struct dev_archdata { + #ifdef CONFIG_IOMMU_API + void *iommu; /* private IOMMU data */ + #endif ++#ifdef CONFIG_XEN ++ const struct dma_map_ops *dev_dma_ops; ++#endif + bool dma_coherent; + }; + +--- a/arch/arm64/include/asm/dma-mapping.h ++++ b/arch/arm64/include/asm/dma-mapping.h +@@ -27,11 +27,8 @@ + #define DMA_ERROR_CODE (~(dma_addr_t)0) + extern const struct dma_map_ops dummy_dma_ops; + +-static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev) ++static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus) + { +- if (dev && dev->dma_ops) +- return dev->dma_ops; +- + /* + * We expect no ISA devices, and all other DMA masters are expected to + * have someone call arch_setup_dma_ops at device creation time. +@@ -39,14 +36,6 @@ static inline const struct dma_map_ops * + return &dummy_dma_ops; + } + +-static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus) +-{ +- if (xen_initial_domain()) +- return xen_dma_ops; +- else +- return __generic_dma_ops(NULL); +-} +- + void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, + const struct iommu_ops *iommu, bool coherent); + #define arch_setup_dma_ops arch_setup_dma_ops +--- a/arch/arm64/mm/dma-mapping.c ++++ b/arch/arm64/mm/dma-mapping.c +@@ -977,4 +977,11 @@ void arch_setup_dma_ops(struct device *d + + dev->archdata.dma_coherent = coherent; + __iommu_setup_dma_ops(dev, dma_base, size, iommu); ++ ++#ifdef CONFIG_XEN ++ if (xen_initial_domain()) { ++ dev->archdata.dev_dma_ops = dev->dma_ops; ++ dev->dma_ops = xen_dma_ops; ++ } ++#endif + } +--- a/include/xen/arm/page-coherent.h ++++ b/include/xen/arm/page-coherent.h +@@ -2,8 +2,16 @@ + #define _ASM_ARM_XEN_PAGE_COHERENT_H + + #include ++#include + #include + ++static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev) ++{ ++ if (dev && dev->archdata.dev_dma_ops) ++ return dev->archdata.dev_dma_ops; ++ return get_arch_dma_ops(NULL); ++} ++ + void __xen_dma_map_page(struct device *hwdev, struct page *page, + dma_addr_t dev_addr, unsigned long offset, size_t size, + enum dma_data_direction dir, unsigned long attrs); diff --git a/queue-4.11/xen-revert-commits-da72ff5bfcb0-and-72a9b186292d.patch b/queue-4.11/xen-revert-commits-da72ff5bfcb0-and-72a9b186292d.patch new file mode 100644 index 00000000000..7669ace6e36 --- /dev/null +++ b/queue-4.11/xen-revert-commits-da72ff5bfcb0-and-72a9b186292d.patch @@ -0,0 +1,259 @@ +From 84d582d236dc1f9085e741affc72e9ba061a67c2 Mon Sep 17 00:00:00 2001 +From: Boris Ostrovsky +Date: Mon, 24 Apr 2017 15:04:53 -0400 +Subject: xen: Revert commits da72ff5bfcb0 and 72a9b186292d + +From: Boris Ostrovsky + +commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream. + +Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741) +established that commit 72a9b186292d ("xen: Remove event channel +notification through Xen PCI platform device") (and thus commit +da72ff5bfcb0 ("partially revert "xen: Remove event channel +notification through Xen PCI platform device"")) are unnecessary and, +in fact, prevent HVM guests from booting on Xen releases prior to 4.0 + +Therefore we revert both of those commits. + +The summary of that discussion is below: + + Here is the brief summary of the current situation: + + Before the offending commit (72a9b186292): + + 1) INTx does not work because of the reset_watches path. + 2) The reset_watches path is only taken if you have Xen > 4.0 + 3) The Linux Kernel by default will use vector inject if the hypervisor + support. So even INTx does not work no body running the kernel with + Xen > 4.0 would notice. Unless he explicitly disabled this feature + either in the kernel or in Xen (and this can only be disabled by + modifying the code, not user-supported way to do it). + + After the offending commit (+ partial revert): + + 1) INTx is no longer support for HVM (only for PV guests). + 2) Any HVM guest The kernel will not boot on Xen < 4.0 which does + not have vector injection support. Since the only other mode + supported is INTx which. + + So based on this summary, I think before commit (72a9b186292) we were + in much better position from a user point of view. + +Signed-off-by: Boris Ostrovsky +Reviewed-by: Juergen Gross +Cc: Boris Ostrovsky +Cc: Thomas Gleixner +Cc: Ingo Molnar +Cc: "H. Peter Anvin" +Cc: x86@kernel.org +Cc: Konrad Rzeszutek Wilk +Cc: Bjorn Helgaas +Cc: Stefano Stabellini +Cc: Julien Grall +Cc: Vitaly Kuznetsov +Cc: Paul Gortmaker +Cc: Ross Lagerwall +Cc: xen-devel@lists.xenproject.org +Cc: linux-kernel@vger.kernel.org +Cc: linux-pci@vger.kernel.org +Cc: Anthony Liguori +Cc: KarimAllah Ahmed +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/xen/events.h | 11 +++++++++++ + arch/x86/pci/xen.c | 2 +- + arch/x86/xen/enlighten.c | 16 +++++++++++----- + arch/x86/xen/smp.c | 2 ++ + arch/x86/xen/time.c | 5 +++++ + drivers/xen/events/events_base.c | 26 +++++++++++++++++--------- + drivers/xen/platform-pci.c | 13 +++---------- + 7 files changed, 50 insertions(+), 25 deletions(-) + +--- a/arch/x86/include/asm/xen/events.h ++++ b/arch/x86/include/asm/xen/events.h +@@ -20,4 +20,15 @@ static inline int xen_irqs_disabled(stru + /* No need for a barrier -- XCHG is a barrier on x86. */ + #define xchg_xen_ulong(ptr, val) xchg((ptr), (val)) + ++extern int xen_have_vector_callback; ++ ++/* ++ * Events delivered via platform PCI interrupts are always ++ * routed to vcpu 0 and hence cannot be rebound. ++ */ ++static inline bool xen_support_evtchn_rebind(void) ++{ ++ return (!xen_hvm_domain() || xen_have_vector_callback); ++} ++ + #endif /* _ASM_X86_XEN_EVENTS_H */ +--- a/arch/x86/pci/xen.c ++++ b/arch/x86/pci/xen.c +@@ -447,7 +447,7 @@ void __init xen_msi_init(void) + + int __init pci_xen_hvm_init(void) + { +- if (!xen_feature(XENFEAT_hvm_pirqs)) ++ if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs)) + return 0; + + #ifdef CONFIG_ACPI +--- a/arch/x86/xen/enlighten.c ++++ b/arch/x86/xen/enlighten.c +@@ -138,6 +138,8 @@ struct shared_info xen_dummy_shared_info + void *xen_initial_gdt; + + RESERVE_BRK(shared_info_page_brk, PAGE_SIZE); ++__read_mostly int xen_have_vector_callback; ++EXPORT_SYMBOL_GPL(xen_have_vector_callback); + + static int xen_cpu_up_prepare(unsigned int cpu); + static int xen_cpu_up_online(unsigned int cpu); +@@ -1861,7 +1863,9 @@ static int xen_cpu_up_prepare(unsigned i + xen_vcpu_setup(cpu); + } + +- if (xen_pv_domain() || xen_feature(XENFEAT_hvm_safe_pvclock)) ++ if (xen_pv_domain() || ++ (xen_have_vector_callback && ++ xen_feature(XENFEAT_hvm_safe_pvclock))) + xen_setup_timer(cpu); + + rc = xen_smp_intr_init(cpu); +@@ -1877,7 +1881,9 @@ static int xen_cpu_dead(unsigned int cpu + { + xen_smp_intr_free(cpu); + +- if (xen_pv_domain() || xen_feature(XENFEAT_hvm_safe_pvclock)) ++ if (xen_pv_domain() || ++ (xen_have_vector_callback && ++ xen_feature(XENFEAT_hvm_safe_pvclock))) + xen_teardown_timer(cpu); + + return 0; +@@ -1916,8 +1922,8 @@ static void __init xen_hvm_guest_init(vo + + xen_panic_handler_init(); + +- BUG_ON(!xen_feature(XENFEAT_hvm_callback_vector)); +- ++ if (xen_feature(XENFEAT_hvm_callback_vector)) ++ xen_have_vector_callback = 1; + xen_hvm_smp_init(); + WARN_ON(xen_cpuhp_setup()); + xen_unplug_emulated_devices(); +@@ -1958,7 +1964,7 @@ bool xen_hvm_need_lapic(void) + return false; + if (!xen_hvm_domain()) + return false; +- if (xen_feature(XENFEAT_hvm_pirqs)) ++ if (xen_feature(XENFEAT_hvm_pirqs) && xen_have_vector_callback) + return false; + return true; + } +--- a/arch/x86/xen/smp.c ++++ b/arch/x86/xen/smp.c +@@ -742,6 +742,8 @@ static void __init xen_hvm_smp_prepare_c + + void __init xen_hvm_smp_init(void) + { ++ if (!xen_have_vector_callback) ++ return; + smp_ops.smp_prepare_cpus = xen_hvm_smp_prepare_cpus; + smp_ops.smp_send_reschedule = xen_smp_send_reschedule; + smp_ops.cpu_die = xen_cpu_die; +--- a/arch/x86/xen/time.c ++++ b/arch/x86/xen/time.c +@@ -432,6 +432,11 @@ static void xen_hvm_setup_cpu_clockevent + + void __init xen_hvm_init_time_ops(void) + { ++ /* vector callback is needed otherwise we cannot receive interrupts ++ * on cpu > 0 and at this point we don't know how many cpus are ++ * available */ ++ if (!xen_have_vector_callback) ++ return; + if (!xen_feature(XENFEAT_hvm_safe_pvclock)) { + printk(KERN_INFO "Xen doesn't support pvclock on HVM," + "disable pv timer\n"); +--- a/drivers/xen/events/events_base.c ++++ b/drivers/xen/events/events_base.c +@@ -1312,6 +1312,9 @@ static int rebind_irq_to_cpu(unsigned ir + if (!VALID_EVTCHN(evtchn)) + return -1; + ++ if (!xen_support_evtchn_rebind()) ++ return -1; ++ + /* Send future instances of this interrupt to other vcpu. */ + bind_vcpu.port = evtchn; + bind_vcpu.vcpu = xen_vcpu_nr(tcpu); +@@ -1645,15 +1648,20 @@ void xen_callback_vector(void) + { + int rc; + uint64_t callback_via; +- +- callback_via = HVM_CALLBACK_VECTOR(HYPERVISOR_CALLBACK_VECTOR); +- rc = xen_set_callback_via(callback_via); +- BUG_ON(rc); +- pr_info("Xen HVM callback vector for event delivery is enabled\n"); +- /* in the restore case the vector has already been allocated */ +- if (!test_bit(HYPERVISOR_CALLBACK_VECTOR, used_vectors)) +- alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, +- xen_hvm_callback_vector); ++ if (xen_have_vector_callback) { ++ callback_via = HVM_CALLBACK_VECTOR(HYPERVISOR_CALLBACK_VECTOR); ++ rc = xen_set_callback_via(callback_via); ++ if (rc) { ++ pr_err("Request for Xen HVM callback vector failed\n"); ++ xen_have_vector_callback = 0; ++ return; ++ } ++ pr_info("Xen HVM callback vector for event delivery is enabled\n"); ++ /* in the restore case the vector has already been allocated */ ++ if (!test_bit(HYPERVISOR_CALLBACK_VECTOR, used_vectors)) ++ alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, ++ xen_hvm_callback_vector); ++ } + } + #else + void xen_callback_vector(void) {} +--- a/drivers/xen/platform-pci.c ++++ b/drivers/xen/platform-pci.c +@@ -67,7 +67,7 @@ static uint64_t get_callback_via(struct + pin = pdev->pin; + + /* We don't know the GSI. Specify the PCI INTx line instead. */ +- return ((uint64_t)0x01 << HVM_CALLBACK_VIA_TYPE_SHIFT) | /* PCI INTx identifier */ ++ return ((uint64_t)0x01 << 56) | /* PCI INTx identifier */ + ((uint64_t)pci_domain_nr(pdev->bus) << 32) | + ((uint64_t)pdev->bus->number << 16) | + ((uint64_t)(pdev->devfn & 0xff) << 8) | +@@ -90,7 +90,7 @@ static int xen_allocate_irq(struct pci_d + static int platform_pci_resume(struct pci_dev *pdev) + { + int err; +- if (!xen_pv_domain()) ++ if (xen_have_vector_callback) + return 0; + err = xen_set_callback_via(callback_via); + if (err) { +@@ -138,14 +138,7 @@ static int platform_pci_probe(struct pci + platform_mmio = mmio_addr; + platform_mmiolen = mmio_len; + +- /* +- * Xen HVM guests always use the vector callback mechanism. +- * L1 Dom0 in a nested Xen environment is a PV guest inside in an +- * HVM environment. It needs the platform-pci driver to get +- * notifications from L0 Xen, but it cannot use the vector callback +- * as it is not exported by L1 Xen. +- */ +- if (xen_pv_domain()) { ++ if (!xen_have_vector_callback) { + ret = xen_allocate_irq(pdev); + if (ret) { + dev_warn(&pdev->dev, "request_irq failed err=%d\n", ret);