From: Greg Kroah-Hartman Date: Sun, 20 May 2018 08:55:08 +0000 (+0200) Subject: 4.4-stable patches X-Git-Tag: v4.9.102~25 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3839bec833dc3f668fa7dd2f49264a0bb7a1601c;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: mm-don-t-allow-deferred-pages-with-need_per_cpu_km.patch s390-cpum_sf-ensure-sample-frequency-of-perf-event-attributes-is-non-zero.patch s390-qdio-don-t-release-memory-in-qdio_setup_irq.patch s390-qdio-fix-access-to-uninitialized-qdio_q-fields.patch s390-remove-indirect-branch-from-do_softirq_own_stack.patch --- diff --git a/queue-4.4/mm-don-t-allow-deferred-pages-with-need_per_cpu_km.patch b/queue-4.4/mm-don-t-allow-deferred-pages-with-need_per_cpu_km.patch new file mode 100644 index 00000000000..ebf48bc4c83 --- /dev/null +++ b/queue-4.4/mm-don-t-allow-deferred-pages-with-need_per_cpu_km.patch @@ -0,0 +1,90 @@ +From ab1e8d8960b68f54af42b6484b5950bd13a4054b Mon Sep 17 00:00:00 2001 +From: Pavel Tatashin +Date: Fri, 18 May 2018 16:09:13 -0700 +Subject: mm: don't allow deferred pages with NEED_PER_CPU_KM + +From: Pavel Tatashin + +commit ab1e8d8960b68f54af42b6484b5950bd13a4054b upstream. + +It is unsafe to do virtual to physical translations before mm_init() is +called if struct page is needed in order to determine the memory section +number (see SECTION_IN_PAGE_FLAGS). This is because only in mm_init() +we initialize struct pages for all the allocated memory when deferred +struct pages are used. + +My recent fix in commit c9e97a1997 ("mm: initialize pages on demand +during boot") exposed this problem, because it greatly reduced number of +pages that are initialized before mm_init(), but the problem existed +even before my fix, as Fengguang Wu found. + +Below is a more detailed explanation of the problem. + +We initialize struct pages in four places: + +1. Early in boot a small set of struct pages is initialized to fill the + first section, and lower zones. + +2. During mm_init() we initialize "struct pages" for all the memory that + is allocated, i.e reserved in memblock. + +3. Using on-demand logic when pages are allocated after mm_init call + (when memblock is finished) + +4. After smp_init() when the rest free deferred pages are initialized. + +The problem occurs if we try to do va to phys translation of a memory +between steps 1 and 2. Because we have not yet initialized struct pages +for all the reserved pages, it is inherently unsafe to do va to phys if +the translation itself requires access of "struct page" as in case of +this combination: CONFIG_SPARSE && !CONFIG_SPARSE_VMEMMAP + +The following path exposes the problem: + + start_kernel() + trap_init() + setup_cpu_entry_areas() + setup_cpu_entry_area(cpu) + get_cpu_gdt_paddr(cpu) + per_cpu_ptr_to_phys(addr) + pcpu_addr_to_page(addr) + virt_to_page(addr) + pfn_to_page(__pa(addr) >> PAGE_SHIFT) + +We disable this path by not allowing NEED_PER_CPU_KM with deferred +struct pages feature. + +The problems are discussed in these threads: + http://lkml.kernel.org/r/20180418135300.inazvpxjxowogyge@wfg-t540p.sh.intel.com + http://lkml.kernel.org/r/20180419013128.iurzouiqxvcnpbvz@wfg-t540p.sh.intel.com + http://lkml.kernel.org/r/20180426202619.2768-1-pasha.tatashin@oracle.com + +Link: http://lkml.kernel.org/r/20180515175124.1770-1-pasha.tatashin@oracle.com +Fixes: 3a80a7fa7989 ("mm: meminit: initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set") +Signed-off-by: Pavel Tatashin +Acked-by: Michal Hocko +Reviewed-by: Andrew Morton +Cc: Steven Sistare +Cc: Daniel Jordan +Cc: Mel Gorman +Cc: Fengguang Wu +Cc: Dennis Zhou +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +--- a/mm/Kconfig ++++ b/mm/Kconfig +@@ -628,6 +628,7 @@ config DEFERRED_STRUCT_PAGE_INIT + default n + depends on ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT + depends on MEMORY_HOTPLUG ++ depends on !NEED_PER_CPU_KM + help + Ordinarily all struct pages are initialised during early boot in a + single thread. On very large machines this can take a considerable diff --git a/queue-4.4/s390-cpum_sf-ensure-sample-frequency-of-perf-event-attributes-is-non-zero.patch b/queue-4.4/s390-cpum_sf-ensure-sample-frequency-of-perf-event-attributes-is-non-zero.patch new file mode 100644 index 00000000000..605cc1fecac --- /dev/null +++ b/queue-4.4/s390-cpum_sf-ensure-sample-frequency-of-perf-event-attributes-is-non-zero.patch @@ -0,0 +1,38 @@ +From 4bbaf2584b86b0772413edeac22ff448f36351b1 Mon Sep 17 00:00:00 2001 +From: Hendrik Brueckner +Date: Thu, 3 May 2018 15:56:15 +0200 +Subject: s390/cpum_sf: ensure sample frequency of perf event attributes is non-zero + +From: Hendrik Brueckner + +commit 4bbaf2584b86b0772413edeac22ff448f36351b1 upstream. + +Correct a trinity finding for the perf_event_open() system call with +a perf event attribute structure that uses a frequency but has the +sampling frequency set to zero. This causes a FP divide exception during +the sample rate initialization for the hardware sampling facility. + +Fixes: 8c069ff4bd606 ("s390/perf: add support for the CPU-Measurement Sampling Facility") +Cc: stable@vger.kernel.org # 3.14+ +Reviewed-by: Heiko Carstens +Signed-off-by: Hendrik Brueckner +Signed-off-by: Martin Schwidefsky +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kernel/perf_cpum_sf.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/s390/kernel/perf_cpum_sf.c ++++ b/arch/s390/kernel/perf_cpum_sf.c +@@ -744,6 +744,10 @@ static int __hw_perf_event_init(struct p + */ + rate = 0; + if (attr->freq) { ++ if (!attr->sample_freq) { ++ err = -EINVAL; ++ goto out; ++ } + rate = freq_to_sample_rate(&si, attr->sample_freq); + rate = hw_limit_rate(&si, rate); + attr->freq = 0; diff --git a/queue-4.4/s390-qdio-don-t-release-memory-in-qdio_setup_irq.patch b/queue-4.4/s390-qdio-don-t-release-memory-in-qdio_setup_irq.patch new file mode 100644 index 00000000000..061b5a9ed09 --- /dev/null +++ b/queue-4.4/s390-qdio-don-t-release-memory-in-qdio_setup_irq.patch @@ -0,0 +1,65 @@ +From 2e68adcd2fb21b7188ba449f0fab3bee2910e500 Mon Sep 17 00:00:00 2001 +From: Julian Wiedmann +Date: Wed, 2 May 2018 08:28:34 +0200 +Subject: s390/qdio: don't release memory in qdio_setup_irq() + +From: Julian Wiedmann + +commit 2e68adcd2fb21b7188ba449f0fab3bee2910e500 upstream. + +Calling qdio_release_memory() on error is just plain wrong. It frees +the main qdio_irq struct, when following code still uses it. + +Also, no other error path in qdio_establish() does this. So trust +callers to clean up via qdio_free() if some step of the QDIO +initialization fails. + +Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") +Cc: #v2.6.27+ +Signed-off-by: Julian Wiedmann +Signed-off-by: Martin Schwidefsky +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/s390/cio/qdio_setup.c | 10 ++-------- + 1 file changed, 2 insertions(+), 8 deletions(-) + +--- a/drivers/s390/cio/qdio_setup.c ++++ b/drivers/s390/cio/qdio_setup.c +@@ -456,7 +456,6 @@ int qdio_setup_irq(struct qdio_initializ + { + struct ciw *ciw; + struct qdio_irq *irq_ptr = init_data->cdev->private->qdio_data; +- int rc; + + memset(&irq_ptr->qib, 0, sizeof(irq_ptr->qib)); + memset(&irq_ptr->siga_flag, 0, sizeof(irq_ptr->siga_flag)); +@@ -493,16 +492,14 @@ int qdio_setup_irq(struct qdio_initializ + ciw = ccw_device_get_ciw(init_data->cdev, CIW_TYPE_EQUEUE); + if (!ciw) { + DBF_ERROR("%4x NO EQ", irq_ptr->schid.sch_no); +- rc = -EINVAL; +- goto out_err; ++ return -EINVAL; + } + irq_ptr->equeue = *ciw; + + ciw = ccw_device_get_ciw(init_data->cdev, CIW_TYPE_AQUEUE); + if (!ciw) { + DBF_ERROR("%4x NO AQ", irq_ptr->schid.sch_no); +- rc = -EINVAL; +- goto out_err; ++ return -EINVAL; + } + irq_ptr->aqueue = *ciw; + +@@ -510,9 +507,6 @@ int qdio_setup_irq(struct qdio_initializ + irq_ptr->orig_handler = init_data->cdev->handler; + init_data->cdev->handler = qdio_int_handler; + return 0; +-out_err: +- qdio_release_memory(irq_ptr); +- return rc; + } + + void qdio_print_subchannel_info(struct qdio_irq *irq_ptr, diff --git a/queue-4.4/s390-qdio-fix-access-to-uninitialized-qdio_q-fields.patch b/queue-4.4/s390-qdio-fix-access-to-uninitialized-qdio_q-fields.patch new file mode 100644 index 00000000000..06c61c8417e --- /dev/null +++ b/queue-4.4/s390-qdio-fix-access-to-uninitialized-qdio_q-fields.patch @@ -0,0 +1,42 @@ +From e521813468f786271a87e78e8644243bead48fad Mon Sep 17 00:00:00 2001 +From: Julian Wiedmann +Date: Wed, 2 May 2018 08:48:43 +0200 +Subject: s390/qdio: fix access to uninitialized qdio_q fields + +From: Julian Wiedmann + +commit e521813468f786271a87e78e8644243bead48fad upstream. + +Ever since CQ/QAOB support was added, calling qdio_free() straight after +qdio_alloc() results in qdio_release_memory() accessing uninitialized +memory (ie. q->u.out.use_cq and q->u.out.aobs). Followed by a +kmem_cache_free() on the random AOB addresses. + +For older kernels that don't have 6e30c549f6ca, the same applies if +qdio_establish() fails in the DEV_STATE_ONLINE check. + +While initializing q->u.out.use_cq would be enough to fix this +particular bug, the more future-proof change is to just zero-alloc the +whole struct. + +Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks") +Cc: #v3.2+ +Signed-off-by: Julian Wiedmann +Signed-off-by: Martin Schwidefsky +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/s390/cio/qdio_setup.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/s390/cio/qdio_setup.c ++++ b/drivers/s390/cio/qdio_setup.c +@@ -140,7 +140,7 @@ static int __qdio_allocate_qs(struct qdi + int i; + + for (i = 0; i < nr_queues; i++) { +- q = kmem_cache_alloc(qdio_q_cache, GFP_KERNEL); ++ q = kmem_cache_zalloc(qdio_q_cache, GFP_KERNEL); + if (!q) + return -ENOMEM; + diff --git a/queue-4.4/s390-remove-indirect-branch-from-do_softirq_own_stack.patch b/queue-4.4/s390-remove-indirect-branch-from-do_softirq_own_stack.patch new file mode 100644 index 00000000000..1bc272fd2d9 --- /dev/null +++ b/queue-4.4/s390-remove-indirect-branch-from-do_softirq_own_stack.patch @@ -0,0 +1,38 @@ +From 9f18fff63cfd6f559daa1eaae60640372c65f84b Mon Sep 17 00:00:00 2001 +From: Martin Schwidefsky +Date: Tue, 24 Apr 2018 11:18:49 +0200 +Subject: s390: remove indirect branch from do_softirq_own_stack + +From: Martin Schwidefsky + +commit 9f18fff63cfd6f559daa1eaae60640372c65f84b upstream. + +The inline assembly to call __do_softirq on the irq stack uses +an indirect branch. This can be replaced with a normal relative +branch. + +Cc: stable@vger.kernel.org # 4.16 +Fixes: f19fbd5ed6 ("s390: introduce execute-trampolines for branches") +Reviewed-by: Hendrik Brueckner +Signed-off-by: Martin Schwidefsky +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kernel/irq.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/arch/s390/kernel/irq.c ++++ b/arch/s390/kernel/irq.c +@@ -173,10 +173,9 @@ void do_softirq_own_stack(void) + new -= STACK_FRAME_OVERHEAD; + ((struct stack_frame *) new)->back_chain = old; + asm volatile(" la 15,0(%0)\n" +- " basr 14,%2\n" ++ " brasl 14,__do_softirq\n" + " la 15,0(%1)\n" +- : : "a" (new), "a" (old), +- "a" (__do_softirq) ++ : : "a" (new), "a" (old) + : "0", "1", "2", "3", "4", "5", "14", + "cc", "memory" ); + } else { diff --git a/queue-4.4/series b/queue-4.4/series index ca99b120205..2039a9583ec 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -54,3 +54,8 @@ tracing-x86-xen-remove-zero-data-size-trace-events-trace_xen_mmu_flush_tlb-_all. proc-read-mm-s-arg-env-_-start-end-with-mmap-semaphore-taken.patch procfs-fix-pthread-cross-thread-naming-if-pr_dumpable.patch powerpc-powernv-fix-nvram-sleep-in-invalid-context-when-crashing.patch +mm-don-t-allow-deferred-pages-with-need_per_cpu_km.patch +s390-qdio-fix-access-to-uninitialized-qdio_q-fields.patch +s390-cpum_sf-ensure-sample-frequency-of-perf-event-attributes-is-non-zero.patch +s390-qdio-don-t-release-memory-in-qdio_setup_irq.patch +s390-remove-indirect-branch-from-do_softirq_own_stack.patch