August 2020 - Linux-stable-mirror

stable-rc 4.14: arm64: Internal error: Oops: clk_reparent __clk_set_parent_before on db410c

by Naresh Kamboju

Kernel Internal oops while booting stable-rc 4.14 kernel on qcom db410c device this problem happened only once on this specific platform. and rcu_preempt detected stalls on CPUs/tasks detected after this and board hung. metadata: git branch: linux-4.14.y git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git commit: 5b1e982af0f810358664827a6333affb4f5d8eb5 git describe: v4.14.188-126-g5b1e982af0f8 make_kernelversion: 4.14.189-rc1 kernel-config: https://builds.tuxbuild.com/12PM71zBW-5EAp5ztC_yxg/kernel.config Crash dump: [ 5.424958] Unable to handle kernel paging request at virtual address 00001008 [ 5.435485] Mem abort info: [ 5.442509] Exception class = DABT (current EL), IL = 32 bits [ 5.445203] SET = 0, FnV = 0 [[ 5.451101] EA = 0, S1PTW =[ 5.454226] Data abort info: [ 5.457264] ISV = 0, ISS = 0x00000044 [ 5.460390] CM = 0, WnR = 1 [ 5.463951] user pgtable: 4k pages, 48-bit VAs, pgd = ffff80003d66d000 [ 5.467078] [0000000000001008] *pgd=0000000000000000 [ 5.473503] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 5.479838] Modules linked in: adv7511 msm mdt_loader msm_rng drm_kms_helper rng_core drm fuse [ 5.485405] Process kworker/2:0 (pid: 21, stack limit = 0xffff000009450000) [ 5.494090] CPU: 2 PID: 21 Comm: kworker/2:0 Not tainted 4.14.189-rc1 #1 [ 5.501036] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 5.507996] Workqueue: events deferred_probe_work_func [ 5.514935] task: ffff80003d454380 task.stack: ffff000009450000 [ 5.520155] pc : clk_reparent+0x60/0xe8 [ 5.526058] lr : __clk_set_parent_before+0x40/0x88 [ 5.529882] sp : ffff000009453640 pstate : 800001c5 [ 5.534748] x29: ffff000009453640 x28: ffff0000090b7000 [ 5.539615] x27: ffff80003fe7c478 x26: ffff0000094537a8 [ 5.545175] x25: 0000000000000001 x24: ffff000009239038 [ 5.550736] x23: ffff80003b6be688 x22: 0000000000000000 [ 5.556297] x21: 0000000000000000 x20: ffff80003c9d8c00 [ 5.561858] x19: ffff80003d798900 x18: 00000000fffffffe [ 5.567419] x17: 0000ffff7fdbb6a0 x16: ffff00000821ad98 [ 5.572980] x15: 0000000000000001 x14: ffffffffffffffff [ 5.578540] x13: ffff0000094537c8 x12: 0000000000000010 [ 5.584102] x11: 0000000000000010 x10: 0101010101010101 [ 5.589663] x9 : 0000000000000000 x8 : 7f7f7f7f7f7f7f7f [ 5.595223] x7 : fefefefefeff6e77 x6 : 0000000000000140 [ 5.600784] x5 : 0000000000000001 x4 : ffff80003c9d8c00 [ 5.606344] x3 : ffff80003d798900 x2 : 0000000000000004 [ 5.611905] x1 : ffff80003d7989a8 x0 : 0000000000001000 [ 5.617467] Call trace: [ 5.623030] clk_reparent+0x60/0xe8 [ 5.625465] __clk_set_parent_before+0x40/0x88 [ 5.628943] clk_register+0x330/0x618 [ 5.633668] pll_28nm_register+0xa4/0x340 [msm] [ 5.637492] msm_dsi_pll_28nm_init+0xc8/0x1d8 [msm] [ 5.642007] msm_dsi_pll_init+0x34/0xe0 [msm] [ 5.646870] dsi_phy_driver_probe+0x1cc/0x310 [msm] [ 5.651196] platform_drv_probe+0x58/0xb8 [ 5.656060] driver_probe_device+0x228/0x2d0 [ 5.660231] __device_attach_driver+0xb8/0xe8 [ 5.664750] bus_for_each_drv+0x64/0xa0 [ 5.669269] __device_attach+0xcc/0x138 [ 5.673093] device_initial_probe+0x10/0x18 [ 5.676918] bus_probe_device+0x90/0x98 [ 5.681088] device_add+0x3c4/0x5a8 [ 5.684915] of_device_add+0x40/0x58 [ 5.688392] of_platform_device_create_pdata+0x80/0xe8 [ 5.692219] of_platform_bus_create+0xd4/0x308 [ 5.697432] of_platform_populate+0x48/0xb8 [ 5.702143] msm_pdev_probe+0x3c/0x328 [msm] [ 5.706125] platform_drv_probe+0x58/0xb8 [ 5.710642] driver_probe_device+0x228/0x2d0 [ 5.714814] __device_attach_driver+0xb8/0xe8 [ 5.719334] bus_for_each_drv+0x64/0xa0 [ 5.723852] __device_attach+0xcc/0x138 [ 5.727677] device_initial_probe+0x10/0x18 [ 5.731502] bus_probe_device+0x90/0x98 [ 5.735675] deferred_probe_work_func+0xa4/0x140 [ 5.739502] process_one_work+0x19c/0x300 [ 5.744366] worker_thread+0x4c/0x420 [ 5.748539] kthread+0x100/0x130 [ 5.752362] ret_from_fork+0x10/0x1c [ 5.755842] Code: 54000260 f9405080 f9005460 b4000040 (f9000401) [ 5.759669] ---[ end trace 6d70d7dd8a236384 ]--- [ 5.765922] note: kworker/2:0[21] exited with preempt_count 1 [ 26.777168] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 26.777204] 0-...: (1 GPs behind) idle=2fa/140000000000001/0 softirq=1679/1723 fqs=2625 [ 26.783112] 1-...: (1 GPs behind) idle=53a/140000000000000/0 softirq=1946/1958 fqs=2625 [ 26.791444] (detected by 3, t=5252 jiffies, g=58, c=57, q=2362) [ 26.799781] Task dump for CPU 0: [ 26.806033] systemd-udevd R running task 0 2533 1 0x00000202 [ 26.809515] Call trace: [ 26.816814] __switch_to+0xe8/0x148 [ 26.819248] __wake_up_common+0x80/0x170 [ 26.822724] __wake_up_common_lock+0x7c/0xa8 [ 26.826897] __wake_up_sync_key+0x1c/0x28 [ 26.831416] sock_def_readable+0x40/0x88 [ 26.835584] Task dump for CPU 1: [ 26.839755] systemd R running task 0 1 0 0x0000000a [ 26.843237] Call trace: [ 26.850531] __switch_to+0xe8/0x148 [ 26.852968] 0xffff800009fc8000 [ 26.856467] INFO: rcu_sched detected stalls on CPUs/tasks: [ 26.859584] 0-...: (1 GPs behind) idle=2fa/140000000000001/0 softirq=1722/1723 fqs=2625 [ 26.865145] 1-...: (1 GPs behind) idle=53a/140000000000000/0 softirq=1957/1958 fqs=2625 [ 26.873477] (detected by 3, t=5270 jiffies, g=-150, c=-151, q=3) [ 26.881815] Task dump for CPU 0: [ 26.888067] systemd-udevd R running task 0 2533 1 0x00000202 [ 26.891549] Call trace: [ 26.898845] __switch_to+0xe8/0x148 [ 26.901281] __wake_up_common+0x80/0x170 [ 26.904758] __wake_up_common_lock+0x7c/0xa8 [ 26.908931] __wake_up_sync_key+0x1c/0x28 [ 26.913449] sock_def_readable+0x40/0x88 [ 26.917618] Task dump for CPU 1: [ 26.921790] systemd R running task 0 1 0 0x0000000a [ 26.925271] Call trace: [ 26.932565] __switch_to+0xe8/0x148 [ 26.935002] 0xffff800009fc8000 [ 41.449201] random: crng init done [ 41.449221] random: 7 urandom warning(s) missed due to ratelimiting [ 89.797164] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 89.797195] 0-...: (1 GPs behind) idle=2fa/140000000000001/0 softirq=1679/1723 fqs=10482 [ 89.803103] 1-...: (1 GPs behind) idle=53a/140000000000000/0 softirq=1946/1958 fqs=10482 [ 89.811437] (detected by 3, t=21007 jiffies, g=58, c=57, q=2578) [ 89.819773] Task dump for CPU 0: [ 89.826027] systemd-udevd R running task 0 2533 1 0x00000202 [ 89.829508] Call trace: [ 89.836807] __switch_to+0xe8/0x148 [ 89.839241] __wake_up_common+0x80/0x170 [ 89.842717] __wake_up_common_lock+0x7c/0xa8 [ 89.846891] __wake_up_sync_key+0x1c/0x28 [ 89.851410] sock_def_readable+0x40/0x88 <System Hung> Full test log, https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.188-… -- Linaro LKFT https://lkft.linaro.org

4 years, 4 months

4
7
0 0

Re: [PATCH] omapfb: dss: Fix max fclk divider for omap36xx

by Tomi Valkeinen

On 04/08/2020 16:13, Adam Ford wrote: > > > On Thu, Jul 9, 2020 at 7:12 AM Adam Ford <aford173(a)gmail.com <mailto:aford173@gmail.com>> wrote: > > There appears to be a timing issue where using a divider of 32 breaks > the DSS for OMAP36xx despite the TRM stating 32 is a valid > number. Through experimentation, it appears that 31 works. > > This same fix was issued for kernels 4.5+. However, between > kernels 4.4 and 4.5, the directory structure was changed when the > dss directory was moved inside the omapfb directory. That broke the > patch on kernels older than 4.5, because it didn't permit the patch > to apply cleanly for 4.4 and older. > > A similar patch was applied to the 3.16 kernel already, but not to 4.4. > Commit 4b911101a5cd ("drm/omap: fix max fclk divider for omap36xx") is > on the 3.16 stable branch with notes from Ben about the path change. > > Since this was applied for 3.16 already, this patch is for kernels > 3.17 through 4.4 only. > > Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev") > > Cc: <stable(a)vger.kernel.org <mailto:stable@vger.kernel.org>> #3.17 - 4.4 > CC: <tomi.valkeinen(a)ti.com <mailto:tomi.valkeinen@ti.com>> > Signed-off-by: Adam Ford <aford173(a)gmail.com <mailto:aford173@gmail.com>> > > > Tomi, > > Can you comment on this? The 4.4 is still waiting for this fix. The other branches are fixed. Looks good to me. Reviewed-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

4 years, 4 months

3
4
0 0

[PATCH] xen: don't reschedule in preemption off sections

by Juergen Gross

For support of long running hypercalls xen_maybe_preempt_hcall() is calling cond_resched() in case a hypercall marked as preemptible has been interrupted. Normally this is no problem, as only hypercalls done via some ioctl()s are marked to be preemptible. In rare cases when during such a preemptible hypercall an interrupt occurs and any softirq action is started from irq_exit(), a further hypercall issued by the softirq handler will be regarded to be preemptible, too. This might lead to rescheduling in spite of the softirq handler potentially having set preempt_disable(), leading to splats like: BUG: sleeping function called from invalid context at drivers/xen/preempt.c:37 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 20775, name: xl INFO: lockdep is turned off. CPU: 1 PID: 20775 Comm: xl Tainted: G D W 5.4.46-1_prgmr_debug.el7.x86_64 #1 Call Trace: <IRQ> dump_stack+0x8f/0xd0 ___might_sleep.cold.76+0xb2/0x103 xen_maybe_preempt_hcall+0x48/0x70 xen_do_hypervisor_callback+0x37/0x40 RIP: e030:xen_hypercall_xen_version+0xa/0x20 Code: ... RSP: e02b:ffffc900400dcc30 EFLAGS: 00000246 RAX: 000000000004000d RBX: 0000000000000200 RCX: ffffffff8100122a RDX: ffff88812e788000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffffff83ee3ad0 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffff8881824aa0b0 R13: 0000000865496000 R14: 0000000865496000 R15: ffff88815d040000 ? xen_hypercall_xen_version+0xa/0x20 ? xen_force_evtchn_callback+0x9/0x10 ? check_events+0x12/0x20 ? xen_restore_fl_direct+0x1f/0x20 ? _raw_spin_unlock_irqrestore+0x53/0x60 ? debug_dma_sync_single_for_cpu+0x91/0xc0 ? _raw_spin_unlock_irqrestore+0x53/0x60 ? xen_swiotlb_sync_single_for_cpu+0x3d/0x140 ? mlx4_en_process_rx_cq+0x6b6/0x1110 [mlx4_en] ? mlx4_en_poll_rx_cq+0x64/0x100 [mlx4_en] ? net_rx_action+0x151/0x4a0 ? __do_softirq+0xed/0x55b ? irq_exit+0xea/0x100 ? xen_evtchn_do_upcall+0x2c/0x40 ? xen_do_hypervisor_callback+0x29/0x40 </IRQ> ? xen_hypercall_domctl+0xa/0x20 ? xen_hypercall_domctl+0x8/0x20 ? privcmd_ioctl+0x221/0x990 [xen_privcmd] ? do_vfs_ioctl+0xa5/0x6f0 ? ksys_ioctl+0x60/0x90 ? trace_hardirqs_off_thunk+0x1a/0x20 ? __x64_sys_ioctl+0x16/0x20 ? do_syscall_64+0x62/0x250 ? entry_SYSCALL_64_after_hwframe+0x49/0xbe Fix that by testing preempt_count() before calling cond_resched(). In kernel 5.8 this can't happen any more due to the entry code rework (more than 100 patches, so not a candidate for backporting). The issue was introduced in kernel 4.3, so this patch should go into all stable kernels in [4.3 ... 5.7]. Reported-by: Sarah Newman <srn(a)prgmr.com> Fixes: 0fa2f5cb2b0ecd8 ("sched/preempt, xen: Use need_resched() instead of should_resched()") Cc: Sarah Newman <srn(a)prgmr.com> Cc: stable(a)vger.kernel.org Signed-off-by: Juergen Gross <jgross(a)suse.com> Tested-by: Chris Brannon <cmb(a)prgmr.com> --- drivers/xen/preempt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c index 17240c5325a3..6ad87b5c95ed 100644 --- a/drivers/xen/preempt.c +++ b/drivers/xen/preempt.c @@ -27,7 +27,7 @@ EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall); asmlinkage __visible void xen_maybe_preempt_hcall(void) { if (unlikely(__this_cpu_read(xen_in_preemptible_hcall) - && need_resched())) { + && need_resched() && !preempt_count())) { /* * Clear flag as we may be rescheduled on a different * cpu. -- 2.26.2

4 years, 4 months

2
1
0 0

LLVM=1 patches for 5.4

by Nick Desaulniers

Dear stable kernel maintainers, Please consider the attached mbox file, which contains 9 patches which cherry pick cleanly onto 5.4: 1. commit fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/ Clang/LLVM") 2. commit 0f44fbc162b7 ("Documentation/llvm: fix the name of llvm-size") 3. commit 63b903dfebde ("net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware") 4. commit 734f3719d343 ("net: wan: wanxl: use $(M68KCC) instead of $(M68KAS) for rebuilding firmware") 5. commit eefb8c124fd9 ("x86/boot: kbuild: allow readelf executable to be specified") 6. commit 94f7345b7124 ("kbuild: remove PYTHON2 variable") 7. commit aa824e0c962b ("kbuild: remove AS variable") 8. commit 7e20e47c70f8 ("kbuild: replace AS=clang with LLVM_IAS=1") 9. commit a0d1c951ef08 ("kbuild: support LLVM=1 to switch the default tools to Clang/LLVM") This series improves/simplifies building kernels with Clang and LLVM utilities; it will help the various CI systems testing kernels built with Clang+LLVM utilities (in fact I will be pointing to this, if accepted, next week at plumbers with those CI system maintainers), and we will make immediate use of it in Android (see also: https://android-review.googlesource.com/c/platform/prebuilts/clang/host/lin…). We can always carry it out of tree in Android, but I think the series is fairly tame, and would prefer not to. I only particularly care about 5+8+9 (eefb8c124fd9, 7e20e47c70f8, and a0d1c951ef08), but the rest are required for them to cherry-pick cleanly. I don't mind separating those three out, though they won't be clean cherry-picks at that point. It might be good to have Masahiro review the series. If accepted, I plan to wire up test coverage of these immediately in https://github.com/ClangBuiltLinux/continuous-integration/issues/300. Most of the above landed in v5.7-rc1, with 94f7345b7124 landing in v5.6-rc1 and eefb8c124fd9 landing in v5.5-rc3. -- Thanks, ~Nick Desaulniers

4 years, 4 months

3
3
0 0

FAILED: patch "[PATCH] mm/hugetlb: fix calculation of" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 75802ca66354a39ab8e35822747cd08b3384a99a Mon Sep 17 00:00:00 2001 From: Peter Xu <peterx(a)redhat.com> Date: Thu, 6 Aug 2020 23:26:11 -0700 Subject: [PATCH] mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible This is found by code observation only. Firstly, the worst case scenario should assume the whole range was covered by pmd sharing. The old algorithm might not work as expected for ranges like (1g-2m, 1g+2m), where the adjusted range should be (0, 1g+2m) but the expected range should be (0, 2g). Since at it, remove the loop since it should not be required. With that, the new code should be faster too when the invalidating range is huge. Mike said: : With range (1g-2m, 1g+2m) within a vma (0, 2g) the existing code will only : adjust to (0, 1g+2m) which is incorrect. : : We should cc stable. The original reason for adjusting the range was to : prevent data corruption (getting wrong page). Since the range is not : always adjusted correctly, the potential for corruption still exists. : : However, I am fairly confident that adjust_range_if_pmd_sharing_possible : is only gong to be called in two cases: : : 1) for a single page : 2) for range == entire vma : : In those cases, the current code should produce the correct results. : : To be safe, let's just cc stable. Fixes: 017b1660df89 ("mm: migration: fix migration of huge PMD shared pages") Signed-off-by: Peter Xu <peterx(a)redhat.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Link: http://lkml.kernel.org/r/20200730201636.74778-1-peterx@redhat.com Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 27556d4d49fe..e52c878940bb 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5314,25 +5314,21 @@ static bool vma_shareable(struct vm_area_struct *vma, unsigned long addr) void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma, unsigned long *start, unsigned long *end) { - unsigned long check_addr; + unsigned long a_start, a_end; if (!(vma->vm_flags & VM_MAYSHARE)) return; - for (check_addr = *start; check_addr < *end; check_addr += PUD_SIZE) { - unsigned long a_start = check_addr & PUD_MASK; - unsigned long a_end = a_start + PUD_SIZE; + /* Extend the range to be PUD aligned for a worst case scenario */ + a_start = ALIGN_DOWN(*start, PUD_SIZE); + a_end = ALIGN(*end, PUD_SIZE); - /* - * If sharing is possible, adjust start/end if necessary. - */ - if (range_in_vma(vma, a_start, a_end)) { - if (a_start < *start) - *start = a_start; - if (a_end > *end) - *end = a_end; - } - } + /* + * Intersect the range with the vma range, since pmd sharing won't be + * across vma after all + */ + *start = max(vma->vm_start, a_start); + *end = min(vma->vm_end, a_end); } /*

4 years, 4 months

3
2
0 0

[STABLE 4.4 to 5.4][PATCH 0/2] epoll fixes

by Marc Zyngier

Hi Greg, Here's the backport for a couple of epoll fixes that don't cleanly backport to anything older than 5.7. These backports cleanly apply from 5.4 all the way to 4.4. Thanks, M. Al Viro (1): do_epoll_ctl(): clean the failure exits up a bit Marc Zyngier (1): epoll: Keep a reference on files added to the check list fs/eventpoll.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) -- 2.27.0

4 years, 4 months

2
3
0 0

[PATCH v4.9] powerpc: Allow 4224 bytes of stack expansion for the signal frame

by Daniel Axtens

From: Michael Ellerman <mpe(a)ellerman.id.au> commit 63dee5df43a31f3844efabc58972f0a206ca4534 upstream. We have powerpc specific logic in our page fault handling to decide if an access to an unmapped address below the stack pointer should expand the stack VMA. The code was originally added in 2004 "ported from 2.4". The rough logic is that the stack is allowed to grow to 1MB with no extra checking. Over 1MB the access must be within 2048 bytes of the stack pointer, or be from a user instruction that updates the stack pointer. The 2048 byte allowance below the stack pointer is there to cover the 288 byte "red zone" as well as the "about 1.5kB" needed by the signal delivery code. Unfortunately since then the signal frame has expanded, and is now 4224 bytes on 64-bit kernels with transactional memory enabled. This means if a process has consumed more than 1MB of stack, and its stack pointer lies less than 4224 bytes from the next page boundary, signal delivery will fault when trying to expand the stack and the process will see a SEGV. The total size of the signal frame is the size of struct rt_sigframe (which includes the red zone) plus __SIGNAL_FRAMESIZE (128 bytes on 64-bit). The 2048 byte allowance was correct until 2008 as the signal frame was: struct rt_sigframe { struct ucontext uc; /* 0 1440 */ /* --- cacheline 11 boundary (1408 bytes) was 32 bytes ago --- */ long unsigned int _unused[2]; /* 1440 16 */ unsigned int tramp[6]; /* 1456 24 */ struct siginfo * pinfo; /* 1480 8 */ void * puc; /* 1488 8 */ struct siginfo info; /* 1496 128 */ /* --- cacheline 12 boundary (1536 bytes) was 88 bytes ago --- */ char abigap[288]; /* 1624 288 */ /* size: 1920, cachelines: 15, members: 7 */ /* padding: 8 */ }; 1920 + 128 = 2048 Then in commit ce48b2100785 ("powerpc: Add VSX context save/restore, ptrace and signal support") (Jul 2008) the signal frame expanded to 2304 bytes: struct rt_sigframe { struct ucontext uc; /* 0 1696 */ <-- /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ long unsigned int _unused[2]; /* 1696 16 */ unsigned int tramp[6]; /* 1712 24 */ struct siginfo * pinfo; /* 1736 8 */ void * puc; /* 1744 8 */ struct siginfo info; /* 1752 128 */ /* --- cacheline 14 boundary (1792 bytes) was 88 bytes ago --- */ char abigap[288]; /* 1880 288 */ /* size: 2176, cachelines: 17, members: 7 */ /* padding: 8 */ }; 2176 + 128 = 2304 At this point we should have been exposed to the bug, though as far as I know it was never reported. I no longer have a system old enough to easily test on. Then in 2010 commit 320b2b8de126 ("mm: keep a guard page below a grow-down stack segment") caused our stack expansion code to never trigger, as there was always a VMA found for a write up to PAGE_SIZE below r1. That meant the bug was hidden as we continued to expand the signal frame in commit 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context") (Feb 2013): struct rt_sigframe { struct ucontext uc; /* 0 1696 */ /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ struct ucontext uc_transact; /* 1696 1696 */ <-- /* --- cacheline 26 boundary (3328 bytes) was 64 bytes ago --- */ long unsigned int _unused[2]; /* 3392 16 */ unsigned int tramp[6]; /* 3408 24 */ struct siginfo * pinfo; /* 3432 8 */ void * puc; /* 3440 8 */ struct siginfo info; /* 3448 128 */ /* --- cacheline 27 boundary (3456 bytes) was 120 bytes ago --- */ char abigap[288]; /* 3576 288 */ /* size: 3872, cachelines: 31, members: 8 */ /* padding: 8 */ /* last cacheline: 32 bytes */ }; 3872 + 128 = 4000 And commit 573ebfa6601f ("powerpc: Increase stack redzone for 64-bit userspace to 512 bytes") (Feb 2014): struct rt_sigframe { struct ucontext uc; /* 0 1696 */ /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ struct ucontext uc_transact; /* 1696 1696 */ /* --- cacheline 26 boundary (3328 bytes) was 64 bytes ago --- */ long unsigned int _unused[2]; /* 3392 16 */ unsigned int tramp[6]; /* 3408 24 */ struct siginfo * pinfo; /* 3432 8 */ void * puc; /* 3440 8 */ struct siginfo info; /* 3448 128 */ /* --- cacheline 27 boundary (3456 bytes) was 120 bytes ago --- */ char abigap[512]; /* 3576 512 */ <-- /* size: 4096, cachelines: 32, members: 8 */ /* padding: 8 */ }; 4096 + 128 = 4224 Then finally in 2017, commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") exposed us to the existing bug, because it changed the stack VMA to be the correct/real size, meaning our stack expansion code is now triggered. Fix it by increasing the allowance to 4224 bytes. Hard-coding 4224 is obviously unsafe against future expansions of the signal frame in the same way as the existing code. We can't easily use sizeof() because the signal frame structure is not in a header. We will either fix that, or rip out all the custom stack expansion checking logic entirely. Fixes: ce48b2100785 ("powerpc: Add VSX context save/restore, ptrace and signal support") Cc: stable(a)vger.kernel.org # v2.6.27+ Reported-by: Tom Lane <tgl(a)sss.pgh.pa.us> Tested-by: Daniel Axtens <dja(a)axtens.net> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20200724092528.1578671-2-mpe@ellerman.id.au Signed-off-by: Daniel Axtens <dja(a)axtens.net> --- arch/powerpc/mm/fault.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c index 2791f568bdb2..3e4fb430ae45 100644 --- a/arch/powerpc/mm/fault.c +++ b/arch/powerpc/mm/fault.c @@ -192,6 +192,9 @@ static int mm_fault_error(struct pt_regs *regs, unsigned long addr, int fault) return MM_FAULT_CONTINUE; } +// This comes from 64-bit struct rt_sigframe + __SIGNAL_FRAMESIZE +#define SIGFRAME_MAX_SIZE (4096 + 128) + /* * For 600- and 800-family processors, the error_code parameter is DSISR * for a data fault, SRR1 for an instruction fault. For 400-family processors @@ -341,7 +344,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long address, /* * N.B. The POWER/Open ABI allows programs to access up to * 288 bytes below the stack pointer. - * The kernel signal delivery code writes up to about 1.5kB + * The kernel signal delivery code writes up to about 4kB * below the stack pointer (r1) before decrementing it. * The exec code can write slightly over 640kB to the stack * before setting the user r1. Thus we allow the stack to @@ -365,7 +368,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long address, * between the last mapped region and the stack will * expand the stack rather than segfaulting. */ - if (address + 2048 < uregs->gpr[1] && !store_update_sp) + if (address + SIGFRAME_MAX_SIZE < uregs->gpr[1] && !store_update_sp) goto bad_area; } if (expand_stack(vma, address)) -- 2.25.1

4 years, 4 months

2
1
0 0

FAILED: patch "[PATCH] EDAC/{i7core, sb, pnd2, skx}: Fix error event severity" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 45bc6098a3e279d8e391d22428396687562797e2 Mon Sep 17 00:00:00 2001 From: Tony Luck <tony.luck(a)intel.com> Date: Tue, 7 Jul 2020 12:43:24 -0700 Subject: [PATCH] EDAC/{i7core,sb,pnd2,skx}: Fix error event severity IA32_MCG_STATUS.RIPV indicates whether the return RIP value pushed onto the stack as part of machine check delivery is valid or not. Various drivers copied a code fragment that uses the RIPV bit to determine the severity of the error as either HW_EVENT_ERR_UNCORRECTED or HW_EVENT_ERR_FATAL, but this check is reversed (marking errors where RIPV is set as "FATAL"). Reverse the tests so that the error is marked fatal when RIPV is not set. Reported-by: Gabriele Paoloni <gabriele.paoloni(a)intel.com> Signed-off-by: Tony Luck <tony.luck(a)intel.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Cc: <stable(a)vger.kernel.org> Link: https://lkml.kernel.org/r/20200707194324.14884-1-tony.luck@intel.com diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c index 5860ca41185c..2acd9f9284a2 100644 --- a/drivers/edac/i7core_edac.c +++ b/drivers/edac/i7core_edac.c @@ -1710,9 +1710,9 @@ static void i7core_mce_output_error(struct mem_ctl_info *mci, if (uncorrected_error) { core_err_cnt = 1; if (ripv) - tp_event = HW_EVENT_ERR_FATAL; - else tp_event = HW_EVENT_ERR_UNCORRECTED; + else + tp_event = HW_EVENT_ERR_FATAL; } else { tp_event = HW_EVENT_ERR_CORRECTED; } diff --git a/drivers/edac/pnd2_edac.c b/drivers/edac/pnd2_edac.c index fd363746f5b0..b8fc4b84fd86 100644 --- a/drivers/edac/pnd2_edac.c +++ b/drivers/edac/pnd2_edac.c @@ -1155,7 +1155,7 @@ static void pnd2_mce_output_error(struct mem_ctl_info *mci, const struct mce *m, u32 optypenum = GET_BITFIELD(m->status, 4, 6); int rc; - tp_event = uc_err ? (ripv ? HW_EVENT_ERR_FATAL : HW_EVENT_ERR_UNCORRECTED) : + tp_event = uc_err ? (ripv ? HW_EVENT_ERR_UNCORRECTED : HW_EVENT_ERR_FATAL) : HW_EVENT_ERR_CORRECTED; /* diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c index d414698ca324..c5ab634cb6a4 100644 --- a/drivers/edac/sb_edac.c +++ b/drivers/edac/sb_edac.c @@ -2982,9 +2982,9 @@ static void sbridge_mce_output_error(struct mem_ctl_info *mci, if (uncorrected_error) { core_err_cnt = 1; if (ripv) { - tp_event = HW_EVENT_ERR_FATAL; - } else { tp_event = HW_EVENT_ERR_UNCORRECTED; + } else { + tp_event = HW_EVENT_ERR_FATAL; } } else { tp_event = HW_EVENT_ERR_CORRECTED; diff --git a/drivers/edac/skx_common.c b/drivers/edac/skx_common.c index 6d8d6dc626bf..2b4ce8e5ac2f 100644 --- a/drivers/edac/skx_common.c +++ b/drivers/edac/skx_common.c @@ -493,9 +493,9 @@ static void skx_mce_output_error(struct mem_ctl_info *mci, if (uncorrected_error) { core_err_cnt = 1; if (ripv) { - tp_event = HW_EVENT_ERR_FATAL; - } else { tp_event = HW_EVENT_ERR_UNCORRECTED; + } else { + tp_event = HW_EVENT_ERR_FATAL; } } else { tp_event = HW_EVENT_ERR_CORRECTED;

4 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] powerpc/pseries: Do not initiate shutdown when system is" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 90a9b102eddf6a3f987d15f4454e26a2532c1c98 Mon Sep 17 00:00:00 2001 From: Vasant Hegde <hegdevasant(a)linux.vnet.ibm.com> Date: Thu, 20 Aug 2020 11:48:44 +0530 Subject: [PATCH] powerpc/pseries: Do not initiate shutdown when system is running on UPS As per PAPR we have to look for both EPOW sensor value and event modifier to identify the type of event and take appropriate action. In LoPAPR v1.1 section 10.2.2 includes table 136 "EPOW Action Codes": SYSTEM_SHUTDOWN 3 The system must be shut down. An EPOW-aware OS logs the EPOW error log information, then schedules the system to be shut down to begin after an OS defined delay internal (default is 10 minutes.) Then in section 10.3.2.2.8 there is table 146 "Platform Event Log Format, Version 6, EPOW Section", which includes the "EPOW Event Modifier": For EPOW sensor value = 3 0x01 = Normal system shutdown with no additional delay 0x02 = Loss of utility power, system is running on UPS/Battery 0x03 = Loss of system critical functions, system should be shutdown 0x04 = Ambient temperature too high All other values = reserved We have a user space tool (rtas_errd) on LPAR to monitor for EPOW_SHUTDOWN_ON_UPS. Once it gets an event it initiates shutdown after predefined time. It also starts monitoring for any new EPOW events. If it receives "Power restored" event before predefined time it will cancel the shutdown. Otherwise after predefined time it will shutdown the system. Commit 79872e35469b ("powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown") changed our handling of the "on UPS/Battery" case, to immediately shutdown the system. This breaks existing setups that rely on the userspace tool to delay shutdown and let the system run on the UPS. Fixes: 79872e35469b ("powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown") Cc: stable(a)vger.kernel.org # v4.0+ Signed-off-by: Vasant Hegde <hegdevasant(a)linux.vnet.ibm.com> [mpe: Massage change log and add PAPR references] Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20200820061844.306460-1-hegdevasant@linux.vnet.ib… diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c index f3736fcd98fc..13c86a292c6d 100644 --- a/arch/powerpc/platforms/pseries/ras.c +++ b/arch/powerpc/platforms/pseries/ras.c @@ -184,7 +184,6 @@ static void handle_system_shutdown(char event_modifier) case EPOW_SHUTDOWN_ON_UPS: pr_emerg("Loss of system power detected. System is running on" " UPS/battery. Check RTAS error log for details\n"); - orderly_poweroff(true); break; case EPOW_SHUTDOWN_LOSS_OF_CRITICAL_FUNCTIONS:

4 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] epoll: Keep a reference on files added to the check list" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a9ed4a6560b8562b7e2e2bed9527e88001f7b682 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <maz(a)kernel.org> Date: Wed, 19 Aug 2020 17:12:17 +0100 Subject: [PATCH] epoll: Keep a reference on files added to the check list When adding a new fd to an epoll, and that this new fd is an epoll fd itself, we recursively scan the fds attached to it to detect cycles, and add non-epool files to a "check list" that gets subsequently parsed. However, this check list isn't completely safe when deletions can happen concurrently. To sidestep the issue, make sure that a struct file placed on the check list sees its f_count increased, ensuring that a concurrent deletion won't result in the file disapearing from under our feet. Cc: stable(a)vger.kernel.org Signed-off-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 12eebcdea9c8..196003d9242c 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1994,9 +1994,11 @@ static int ep_loop_check_proc(void *priv, void *cookie, int call_nests) * not already there, and calling reverse_path_check() * during ep_insert(). */ - if (list_empty(&epi->ffd.file->f_tfile_llink)) + if (list_empty(&epi->ffd.file->f_tfile_llink)) { + get_file(epi->ffd.file); list_add(&epi->ffd.file->f_tfile_llink, &tfile_check_list); + } } } mutex_unlock(&ep->mtx); @@ -2040,6 +2042,7 @@ static void clear_tfile_check_list(void) file = list_first_entry(&tfile_check_list, struct file, f_tfile_llink); list_del_init(&file->f_tfile_llink); + fput(file); } INIT_LIST_HEAD(&tfile_check_list); } @@ -2204,13 +2207,17 @@ int do_epoll_ctl(int epfd, int op, int fd, struct epoll_event *epds, clear_tfile_check_list(); goto error_tgt_fput; } - } else + } else { + get_file(tf.file); list_add(&tf.file->f_tfile_llink, &tfile_check_list); + } error = epoll_mutex_lock(&ep->mtx, 0, nonblock); if (error) { out_del: list_del(&tf.file->f_tfile_llink); + if (!is_file_epoll(tf.file)) + fput(tf.file); goto error_tgt_fput; } if (is_file_epoll(tf.file)) {

4 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2020