- Linux-stable-mirror - lists.linaro.org

stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 53 passed with 1 untried/unknown (v4.4.206-71-g9e88c306dad6)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 53 passed with 1 untried/unknown (v4.4.206-71-g9e88c306dad6) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.206-71-… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.206-71-g9e88c306dad6 Git Commit: 9e88c306dad62fbf851b965d9728a902587ba5de Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 26 unique boards, 9 SoC families, 9 builds out of 190 --- For more info write to <info(a)kernelci.org>

5 years, 11 months

1
0
0 0

+ mm-fix-uninitialized-memmaps-on-a-partially-populated-last-section.patch added to -mm tree

by Andrew Morton

The patch titled Subject: mm/page_alloc.c: fix uninitialized memmaps on a partially populated last section has been added to the -mm tree. Its filename is mm-fix-uninitialized-memmaps-on-a-partially-populated-last-section.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-fix-uninitialized-memmaps-on-a-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-fix-uninitialized-memmaps-on-a-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: David Hildenbrand <david(a)redhat.com> Subject: mm/page_alloc.c: fix uninitialized memmaps on a partially populated last section If max_pfn is not aligned to a section boundary, we can easily run into BUGs. This can e.g., be triggered on x86-64 under QEMU by specifying a memory size that is not a multiple of 128MB (e.g., 4097MB, but also 4160MB). I was told that on real HW, we can easily have this scenario (esp., one of the main reasons sub-section hotadd of devmem was added). The issue is, that we have a valid memmap (pfn_valid()) for the whole section, and the whole section will be marked "online". pfn_to_online_page() will succeed, but the memmap contains garbage. E.g., doing a "./page-types -r -a 0x144001" when QEMU was started with "-m 4160M" - (see tools/vm/page-types.c): [ 200.476376] BUG: unable to handle page fault for address: fffffffffffffffe [ 200.477500] #PF: supervisor read access in kernel mode [ 200.478334] #PF: error_code(0x0000) - not-present page [ 200.479076] PGD 59614067 P4D 59614067 PUD 59616067 PMD 0 [ 200.479557] Oops: 0000 [#4] SMP NOPTI [ 200.479875] CPU: 0 PID: 603 Comm: page-types Tainted: G D W 5.5.0-rc1-next-20191209 #93 [ 200.480646] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4 [ 200.481648] RIP: 0010:stable_page_flags+0x4d/0x410 [ 200.482061] Code: f3 ff 41 89 c0 48 b8 00 00 00 00 01 00 00 00 45 84 c0 0f 85 cd 02 00 00 48 8b 53 08 48 8b 2b 48f [ 200.483644] RSP: 0018:ffffb139401cbe60 EFLAGS: 00010202 [ 200.484091] RAX: fffffffffffffffe RBX: fffffbeec5100040 RCX: 0000000000000000 [ 200.484697] RDX: 0000000000000001 RSI: ffffffff9535c7cd RDI: 0000000000000246 [ 200.485313] RBP: ffffffffffffffff R08: 0000000000000000 R09: 0000000000000000 [ 200.485917] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000144001 [ 200.486523] R13: 00007ffd6ba55f48 R14: 00007ffd6ba55f40 R15: ffffb139401cbf08 [ 200.487130] FS: 00007f68df717580(0000) GS:ffff9ec77fa00000(0000) knlGS:0000000000000000 [ 200.487804] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 200.488295] CR2: fffffffffffffffe CR3: 0000000135d48000 CR4: 00000000000006f0 [ 200.488897] Call Trace: [ 200.489115] kpageflags_read+0xe9/0x140 [ 200.489447] proc_reg_read+0x3c/0x60 [ 200.489755] vfs_read+0xc2/0x170 [ 200.490037] ksys_pread64+0x65/0xa0 [ 200.490352] do_syscall_64+0x5c/0xa0 [ 200.490665] entry_SYSCALL_64_after_hwframe+0x49/0xbe But it can be triggered much easier via "cat /proc/kpageflags > /dev/null" after cold/hot plugging a DIMM to such a system: [root@localhost ~]# cat /proc/kpageflags > /dev/null [ 111.517275] BUG: unable to handle page fault for address: fffffffffffffffe [ 111.517907] #PF: supervisor read access in kernel mode [ 111.518333] #PF: error_code(0x0000) - not-present page [ 111.518771] PGD a240e067 P4D a240e067 PUD a2410067 PMD 0 This patch fixes that by at least zero-ing out that memmap (so e.g., page_to_pfn() will not crash). Commit 907ec5fca3dc ("mm: zero remaining unavailable struct pages") tried to fix a similar issue, but forgot to consider this special case. After this patch, there are still problems to solve. E.g., not all of these pages falling into a memory hole will actually get initialized later and set PageReserved - they are only zeroed out - but at least the immediate crashes are gone. A follow-up patch will take care of this. Link: http://lkml.kernel.org/r/20191211163201.17179-2-david@redhat.com Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap") Signed-off-by: David Hildenbrand <david(a)redhat.com> Tested-by: Daniel Jordan <daniel.m.jordan(a)oracle.com> Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Steven Sistare <steven.sistare(a)oracle.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com> Cc: Bob Picco <bob.picco(a)oracle.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Stephen Rothwell <sfr(a)canb.auug.org.au> Cc: <stable(a)vger.kernel.org> [4.15+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/mm/page_alloc.c~mm-fix-uninitialized-memmaps-on-a-partially-populated-last-section +++ a/mm/page_alloc.c @@ -6932,7 +6932,8 @@ static u64 zero_pfn_range(unsigned long * This function also addresses a similar issue where struct pages are left * uninitialized because the physical address range is not covered by * memblock.memory or memblock.reserved. That could happen when memblock - * layout is manually configured via memmap=. + * layout is manually configured via memmap=, or when the highest physical + * address (max_pfn) does not end on a section boundary. */ void __init zero_resv_unavail(void) { @@ -6950,7 +6951,16 @@ void __init zero_resv_unavail(void) pgcnt += zero_pfn_range(PFN_DOWN(next), PFN_UP(start)); next = end; } - pgcnt += zero_pfn_range(PFN_DOWN(next), max_pfn); + + /* + * Early sections always have a fully populated memmap for the whole + * section - see pfn_valid(). If the last section has holes at the + * end and that section is marked "online", the memmap will be + * considered initialized. Make sure that memmap has a well defined + * state. + */ + pgcnt += zero_pfn_range(PFN_DOWN(next), + round_up(max_pfn, PAGES_PER_SECTION)); /* * Struct pages that do not have backing memory. This could be because _ Patches currently in -mm which might be from david(a)redhat.com are mm-fix-uninitialized-memmaps-on-a-partially-populated-last-section.patch fs-proc-pagec-allow-inspection-of-last-section-and-fix-end-detection.patch mm-initialize-memmap-of-unavailable-memory-directly.patch mm-memory_hotplug-shrink-zones-when-offlining-memory.patch mm-memory_hotplug-poison-memmap-in-remove_pfn_range_from_zone.patch mm-memory_hotplug-we-always-have-a-zone-in-find_smallestbiggest_section_pfn.patch mm-memory_hotplug-dont-check-for-all-holes-in-shrink_zone_span.patch mm-memory_hotplug-drop-local-variables-in-shrink_zone_span.patch mm-memory_hotplug-cleanup-__remove_pages.patch

5 years, 11 months

1
0
0 0

stable-rc/linux-4.19.y boot: 84 boots: 0 failed, 83 passed with 1 untried/unknown (v4.19.88-244-g62dbca0959b3)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 84 boots: 0 failed, 83 passed with 1 untried/unknown (v4.19.88-244-g62dbca0959b3) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.88-24… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.88-244-g62dbca0959b3 Git Commit: 62dbca0959b37287a49ac6a949578849d490df83 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 48 unique boards, 15 SoC families, 14 builds out of 206 --- For more info write to <info(a)kernelci.org>

5 years, 11 months

1
0
0 0

+ mm-oom-fix-pgtables-units-mismatch-in-killed-process-message.patch added to -mm tree

by Andrew Morton

The patch titled Subject: mm/oom: fix pgtables units mismatch in Killed process message has been added to the -mm tree. Its filename is mm-oom-fix-pgtables-units-mismatch-in-killed-process-message.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-oom-fix-pgtables-units-mismatch… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-oom-fix-pgtables-units-mismatch… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Ilya Dryomov <idryomov(a)gmail.com> Subject: mm/oom: fix pgtables units mismatch in Killed process message pr_err() expects kB, but mm_pgtables_bytes() returns the number of bytes. As everything else is printed in kB, I chose to fix the value rather than the string. Before: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name ... [ 1878] 1000 1878 217253 151144 1269760 0 0 python ... Out of memory: Killed process 1878 (python) total-vm:869012kB, anon-rss:604572kB, file-rss:4kB, shmem-rss:0kB, UID:1000 pgtables:1269760kB oom_score_adj:0 After: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name ... [ 1436] 1000 1436 217253 151890 1294336 0 0 python ... Out of memory: Killed process 1436 (python) total-vm:869012kB, anon-rss:607516kB, file-rss:44kB, shmem-rss:0kB, UID:1000 pgtables:1264kB oom_score_adj:0 Link: http://lkml.kernel.org/r/20191211202830.1600-1-idryomov@gmail.com Fixes: 70cb6d267790 ("mm/oom: add oom_score_adj and pgtables to Killed process message") Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Edward Chron <echron(a)arista.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: David Rientjes <rientjes(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/oom_kill.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/oom_kill.c~mm-oom-fix-pgtables-units-mismatch-in-killed-process-message +++ a/mm/oom_kill.c @@ -890,7 +890,7 @@ static void __oom_kill_process(struct ta K(get_mm_counter(mm, MM_FILEPAGES)), K(get_mm_counter(mm, MM_SHMEMPAGES)), from_kuid(&init_user_ns, task_uid(victim)), - mm_pgtables_bytes(mm), victim->signal->oom_score_adj); + mm_pgtables_bytes(mm) >> 10, victim->signal->oom_score_adj); task_unlock(victim); /* _ Patches currently in -mm which might be from idryomov(a)gmail.com are mm-oom-fix-pgtables-units-mismatch-in-killed-process-message.patch

5 years, 11 months

1
0
0 0

[PATCH v2 11/13] KVM: x86: Protect exit_reason from being used in Spectre-v1/L1TF attacks

by Marios Pomonis

This fixes a Spectre-v1/L1TF vulnerability in vmx_handle_exit(). While exit_reason is set by the hardware and therefore should not be attacker-influenced, an unknown exit_reason could potentially be used to perform such an attack. Fixes: commit 55d2375e58a6 ("KVM: nVMX: Move nested code to dedicated files") Signed-off-by: Marios Pomonis <pomonis(a)google.com> Signed-off-by: Nick Finco <nifi(a)google.com> Suggested-by: Sean Christopherson <sean.j.christopherson(a)intel.com> Reviewed-by: Andrew Honig <ahonig(a)google.com> Cc: stable(a)vger.kernel.org --- arch/x86/kvm/vmx/vmx.c | 55 +++++++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 25 deletions(-) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 82b25f1812aa..78f2fef97d93 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -5918,34 +5918,39 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu) } } - if (exit_reason < kvm_vmx_max_exit_handlers - && kvm_vmx_exit_handlers[exit_reason]) { + if (exit_reason >= kvm_vmx_max_exit_handlers) + goto unexpected_vmexit; #ifdef CONFIG_RETPOLINE - if (exit_reason == EXIT_REASON_MSR_WRITE) - return kvm_emulate_wrmsr(vcpu); - else if (exit_reason == EXIT_REASON_PREEMPTION_TIMER) - return handle_preemption_timer(vcpu); - else if (exit_reason == EXIT_REASON_PENDING_INTERRUPT) - return handle_interrupt_window(vcpu); - else if (exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT) - return handle_external_interrupt(vcpu); - else if (exit_reason == EXIT_REASON_HLT) - return kvm_emulate_halt(vcpu); - else if (exit_reason == EXIT_REASON_EPT_MISCONFIG) - return handle_ept_misconfig(vcpu); + if (exit_reason == EXIT_REASON_MSR_WRITE) + return kvm_emulate_wrmsr(vcpu); + else if (exit_reason == EXIT_REASON_PREEMPTION_TIMER) + return handle_preemption_timer(vcpu); + else if (exit_reason == EXIT_REASON_PENDING_INTERRUPT) + return handle_interrupt_window(vcpu); + else if (exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT) + return handle_external_interrupt(vcpu); + else if (exit_reason == EXIT_REASON_HLT) + return kvm_emulate_halt(vcpu); + else if (exit_reason == EXIT_REASON_EPT_MISCONFIG) + return handle_ept_misconfig(vcpu); #endif - return kvm_vmx_exit_handlers[exit_reason](vcpu); - } else { - vcpu_unimpl(vcpu, "vmx: unexpected exit reason 0x%x\n", - exit_reason); - dump_vmcs(); - vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR; - vcpu->run->internal.suberror = + + exit_reason = array_index_nospec(exit_reason, + kvm_vmx_max_exit_handlers); + if (!kvm_vmx_exit_handlers[exit_reason]) + goto unexpected_vmexit; + + return kvm_vmx_exit_handlers[exit_reason](vcpu); + +unexpected_vmexit: + vcpu_unimpl(vcpu, "vmx: unexpected exit reason 0x%x\n", exit_reason); + dump_vmcs(); + vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR; + vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_UNEXPECTED_EXIT_REASON; - vcpu->run->internal.ndata = 1; - vcpu->run->internal.data[0] = exit_reason; - return 0; - } + vcpu->run->internal.ndata = 1; + vcpu->run->internal.data[0] = exit_reason; + return 0; } /* -- 2.24.0.525.g8f36a354ae-goog

5 years, 11 months

1
0
0 0

[PATCH 06/24] compat_ioctl: block: handle Persistent Reservations

by Arnd Bergmann

These were added to blkdev_ioctl() in linux-5.5 but not blkdev_compat_ioctl, so add them now. Cc: <stable(a)vger.kernel.org> # v4.4+ Fixes: bbd3e064362e ("block: add an API for Persistent Reservations") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- block/compat_ioctl.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/block/compat_ioctl.c b/block/compat_ioctl.c index 5b13e344229c..f16ae92065d7 100644 --- a/block/compat_ioctl.c +++ b/block/compat_ioctl.c @@ -408,6 +408,14 @@ long compat_blkdev_ioctl(struct file *file, unsigned cmd, unsigned long arg) case BLKTRACETEARDOWN: /* compatible */ ret = blk_trace_ioctl(bdev, cmd, compat_ptr(arg)); return ret; + case IOC_PR_REGISTER: + case IOC_PR_RESERVE: + case IOC_PR_RELEASE: + case IOC_PR_PREEMPT: + case IOC_PR_PREEMPT_ABORT: + case IOC_PR_CLEAR: + return blkdev_ioctl(bdev, mode, cmd, + (unsigned long)compat_ptr(arg)); default: if (disk->fops->compat_ioctl) ret = disk->fops->compat_ioctl(bdev, mode, cmd, arg); -- 2.20.0

5 years, 11 months

1
0
0 0

stable-rc/linux-4.9.y boot: 63 boots: 0 failed, 62 passed with 1 untried/unknown (v4.9.206-92-gede24ca9232b)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 63 boots: 0 failed, 62 passed with 1 untried/unknown (v4.9.206-92-gede24ca9232b) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.206-92-… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.206-92-gede24ca9232b Git Commit: ede24ca9232b565f0f6d655b1670e89e25814bb4 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 31 unique boards, 12 SoC families, 12 builds out of 197 --- For more info write to <info(a)kernelci.org>

5 years, 11 months

1
0
0 0

stable-rc/linux-4.4.y boot: 99 boots: 0 failed, 94 passed with 5 offline (v4.4.206-70-g680ea7f4b671)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 99 boots: 0 failed, 94 passed with 5 offline (v4.4.206-70-g680ea7f4b671) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.206-70-… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.206-70-g680ea7f4b671 Git Commit: 680ea7f4b671397be095319bda4f20c832007bca Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 47 unique boards, 16 SoC families, 14 builds out of 190 Offline Platforms: arm: exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab sunxi_defconfig: gcc-8 sun7i-a20-bananapi: 1 offline lab multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab sun7i-a20-bananapi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 11 months

1
0
0 0

stable-rc/linux-5.3.y boot: 151 boots: 1 failed, 142 passed with 6 offline, 1 untried/unknown, 1 conflict (v5.3.15-100-g365e7b9094d3)

by kernelci.org bot

stable-rc/linux-5.3.y boot: 151 boots: 1 failed, 142 passed with 6 offline, 1 untried/unknown, 1 conflict (v5.3.15-100-g365e7b9094d3) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.3.y/kernel/v5.3.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.3.y/kernel/v5.3.15-100-… Tree: stable-rc Branch: linux-5.3.y Git Describe: v5.3.15-100-g365e7b9094d3 Git Commit: 365e7b9094d353d3c85a1ef427b75774368af535 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 88 unique boards, 25 SoC families, 19 builds out of 208 Boot Failure Detected: arm64: defconfig: gcc-8: meson-gxl-s805x-libretech-ac: 1 failed lab Offline Platforms: arm: exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab sunxi_defconfig: gcc-8 sun7i-a20-bananapi: 1 offline lab multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab mt7623n-bananapi-bpi-r2: 1 offline lab sun7i-a20-bananapi: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm64: defconfig: meson-gxm-q200: lab-baylibre: PASS (gcc-8) lab-baylibre-seattle: FAIL (gcc-8) --- For more info write to <info(a)kernelci.org>

5 years, 11 months

1
0
0 0

+ revert-ipcsem-remove-uneeded-sem_undo_list-lock-usage-in-exit_sem.patch added to -mm tree

by Andrew Morton

The patch titled Subject: Revert "ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()" has been added to the -mm tree. Its filename is revert-ipcsem-remove-uneeded-sem_undo_list-lock-usage-in-exit_sem.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/revert-ipcsem-remove-uneeded-sem_u… and later at http://ozlabs.org/~akpm/mmotm/broken-out/revert-ipcsem-remove-uneeded-sem_u… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Ioanna Alifieraki <ioanna-maria.alifieraki(a)canonical.com> Subject: Revert "ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()" This reverts commit a97955844807e327df11aa33869009d14d6b7de0. Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()") removes a lock that is needed. This leads to a process looping infinitely in exit_sem() and can also lead to a crash. There is a reproducer available in [1] and with the commit reverted the issue does not reproduce anymore. Using the reproducer found in [1] is fairly easy to reach a point where one of the child processes is looping infinitely in exit_sem between for(;;) and if (semid == -1) block, while it's trying to free its last sem_undo structure which has already been freed by freeary(). Each sem_undo struct is on two lists: one per semaphore set (list_id) and one per process (list_proc). The list_id list tracks undos by semaphore set, and the list_proc by process. Undo structures are removed either by freeary() or by exit_sem(). The freeary function is invoked when the user invokes a syscall to remove a semaphore set. During this operation freeary() traverses the list_id associated with the semaphore set and removes the undo structures from both the list_id and list_proc lists. For this case, exit_sem() is called at process exit. Each process contains a struct sem_undo_list (referred to as "ulp") which contains the head for the list_proc list. When the process exits, exit_sem() traverses this list to remove each sem_undo struct. As in freeary(), whenever a sem_undo struct is removed from list_proc, it is also removed from the list_id list. Removing elements from list_id is safe for both exit_sem() and freeary() due to sem_lock(). Removing elements from list_proc is not safe; freeary() locks &un->ulp->lock when it performs list_del_rcu(&un->list_proc) but exit_sem() does not (locking was removed by commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()"). This can result in the following situation while executing the reproducer [1] : Consider a child process in exit_sem() and the parent in freeary() (because of semctl(sid[i], NSEM, IPC_RMID)). The list_proc for the child contains the last two undo structs A and B (the rest have been removed either by exit_sem() or freeary()). The semid for A is 1 and semid for B is 2. exit_sem() removes A and at the same time freeary() removes B. Since A and B have different semid sem_lock() will acquire different locks for each process and both can proceed. The bug is that they remove A and B from the same list_proc at the same time because only freeary() acquires the ulp lock. When exit_sem() removes A it makes ulp->list_proc.next to point at B and at the same time freeary() removes B setting B->semid=-1. At the next iteration of for(;;) loop exit_sem() will try to remove B. The only way to break from for(;;) is for (&un->list_proc == &ulp->list_proc) to be true which is not. Then exit_sem() will check if B->semid=-1 which is and will continue looping in for(;;) until the memory for B is reallocated and the value at B->semid is changed. At that point, exit_sem() will crash attempting to unlink B from the lists (this can be easily triggered by running the reproducer [1] a second time). To prove this scenario instrumentation was added to keep information about each sem_undo (un) struct that is removed per process and per semaphore set (sma). CPU0 CPU1 [caller holds sem_lock(sma for A)] ... freeary() exit_sem() ... ... ... sem_lock(sma for B) spin_lock(A->ulp->lock) ... list_del_rcu(un_A->list_proc) list_del_rcu(un_B->list_proc) Undo structures A and B have different semid and sem_lock() operations proceed. However they belong to the same list_proc list and they are removed at the same time. This results into ulp->list_proc.next pointing to the address of B which is already removed. After reverting commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()") the issue was no longer reproducible. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779 Link: http://lkml.kernel.org/r/20191211191318.11860-1-ioanna-maria.alifieraki@can… Fixes: a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()") Signed-off-by: Ioanna Alifieraki <ioanna-maria.alifieraki(a)canonical.com> Cc: Manfred Spraul <manfred(a)colorfullife.com> Cc: Herton Krzesinski <herton(a)redhat.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: <malat(a)debian.org> Cc: Joel Fernandes (Google) <joel(a)joelfernandes.org> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Jay Vosburgh <jay.vosburgh(a)canonical.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- ipc/sem.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/ipc/sem.c~revert-ipcsem-remove-uneeded-sem_undo_list-lock-usage-in-exit_sem +++ a/ipc/sem.c @@ -2368,11 +2368,9 @@ void exit_sem(struct task_struct *tsk) ipc_assert_locked_object(&sma->sem_perm); list_del(&un->list_id); - /* we are the last process using this ulp, acquiring ulp->lock - * isn't required. Besides that, we are also protected against - * IPC_RMID as we hold sma->sem_perm lock now - */ + spin_lock(&ulp->lock); list_del_rcu(&un->list_proc); + spin_unlock(&ulp->lock); /* perform adjustments registered in un */ for (i = 0; i < sma->sem_nsems; i++) { _ Patches currently in -mm which might be from ioanna-maria.alifieraki(a)canonical.com are revert-ipcsem-remove-uneeded-sem_undo_list-lock-usage-in-exit_sem.patch

5 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror