From patchwork Fri Apr 24 03:32:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 226973 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70C5FC5518A for ; Fri, 24 Apr 2020 03:32:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4F61D2084D for ; Fri, 24 Apr 2020 03:32:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587699135; bh=heYBxyRSj6OCmDC8ifkTZrTjLvYjcxlqxGx3/mMEEfM=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=FKZjRKpBlNMKuXTPo+fqJZFKvP972WUT9TkzBUtHr3jQad2RUFPo8yj6sFPH6rBDR fAKUmYf65NWM2CyXb3r9+zu2RHWAfiSC0Xpff7O8Tb4lI0Yk3Zdk6zePvNe6KgnAYq eT2pAbDixXHBY3f4QT+nIorgxpfZ6QcjAHsORqZU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725922AbgDXDcP (ORCPT ); Thu, 23 Apr 2020 23:32:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:41826 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725888AbgDXDcO (ORCPT ); Thu, 23 Apr 2020 23:32:14 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B04A320715; Fri, 24 Apr 2020 03:32:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587699134; bh=heYBxyRSj6OCmDC8ifkTZrTjLvYjcxlqxGx3/mMEEfM=; h=Date:From:To:Subject:In-Reply-To:From; b=ltAJ2OTIhE3L6u1YdG/qUhtRaT9KYhoxi55ErXlp9wTMEeMJXTy3Dq1yD20kkzF/Y gOV0uuInsAcG2d3RY31fzfJ+gGOyS3oQoANKOWAJIoF8abV8j/JRgEPP90JXpZmuur fw1gC5wpVQ8jWFbcwiSn+uGerYmkjKbeIzk6KtPU= Date: Thu, 23 Apr 2020 20:32:13 -0700 From: Andrew Morton To: jbaron@akamai.com, khazhy@google.com, mm-commits@vger.kernel.org, r@hev.cc, rpenyaev@suse.de, stable@vger.kernel.org, viro@zeniv.linux.org.uk Subject: + eventpoll-fix-missing-wakeup-for-ovflist-in-ep_poll_callback.patch added to -mm tree Message-ID: <20200424033213.WRxjDVHj1%akpm@linux-foundation.org> In-Reply-To: <20200420181310.c18b3c0aa4dc5b3e5ec1be10@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch titled Subject: eventpoll: fix missing wakeup for ovflist in ep_poll_callback has been added to the -mm tree. Its filename is eventpoll-fix-missing-wakeup-for-ovflist-in-ep_poll_callback.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/eventpoll-fix-missing-wakeup-for-ovflist-in-ep_poll_callback.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/eventpoll-fix-missing-wakeup-for-ovflist-in-ep_poll_callback.patch 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: Khazhismel Kumykov Subject: eventpoll: fix missing wakeup for ovflist in ep_poll_callback In the event that we add to ovflist, before 339ddb53d373 we would be woken up by ep_scan_ready_list, and did no wakeup in ep_poll_callback. With that wakeup removed, if we add to ovflist here, we may never wake up. Rather than adding back the ep_scan_ready_list wakeup - which was resulting un uncessary wakeups, trigger a wake-up in ep_poll_callback. We noticed that one of our workloads was missing wakeups starting with 339ddb53d373 and upon manual inspection, this wakeup seemed missing to me. With this patch added, we no longer see missing wakeups. I haven't yet tried to make a small reproducer, but the existing kselftests in filesystem/epoll passed for me with this patch. Link: http://lkml.kernel.org/r/20200424025057.118641-1-khazhy@google.com Fixes: 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of nested epoll") Signed-off-by: Khazhismel Kumykov Cc: Alexander Viro Cc: Roman Penyaev Cc: Heiher Cc: Jason Baron Cc: Signed-off-by: Andrew Morton --- fs/eventpoll.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/eventpoll.c~eventpoll-fix-missing-wakeup-for-ovflist-in-ep_poll_callback +++ a/fs/eventpoll.c @@ -1240,7 +1240,7 @@ static int ep_poll_callback(wait_queue_e if (epi->next == EP_UNACTIVE_PTR && chain_epi_lockless(epi)) ep_pm_stay_awake_rcu(epi); - goto out_unlock; + goto out_wakeup_unlock; } /* If this file is already in the ready list we exit soon */ @@ -1249,6 +1249,7 @@ static int ep_poll_callback(wait_queue_e ep_pm_stay_awake_rcu(epi); } +out_wakeup_unlock: /* * Wake up ( if active ) both the eventpoll wait list and the ->poll() * wait list. From patchwork Tue Apr 21 01:13:51 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 227381 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7024DC54FCB for ; Tue, 21 Apr 2020 01:13:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5033721D79 for ; Tue, 21 Apr 2020 01:13:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587431634; bh=0NodWTlWfCZcGlszt6Yi/kd0x5OvcKZi5OCvXNbcLAA=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=XykzZtA7pr+WHrfb8y6HAInhdTtfhDVTZX1yzvyrFRFHyuHWXfPPR7plK38bMCzZL IyF4tKohI/BlopvHLZVHs5uXNasruJ3lofNNXPjfJMnEGKnCbBMdkpypPWInI0N3dU LiOPI0SBKti+UySx1HIMdNFJ/DwAZRkixPON8XWI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725958AbgDUBNx (ORCPT ); Mon, 20 Apr 2020 21:13:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:35382 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726793AbgDUBNx (ORCPT ); Mon, 20 Apr 2020 21:13:53 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 750BB208E4; Tue, 21 Apr 2020 01:13:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587431632; bh=0NodWTlWfCZcGlszt6Yi/kd0x5OvcKZi5OCvXNbcLAA=; h=Date:From:To:Subject:In-Reply-To:From; b=zii0oB0oO8bzXBPUJ4gPyhDrb+TvePnVtMznkOlBjgevcOWcKGkEJsmSETf5I2cau lYp67nn9zCKe7zpwI2+Clw5g0pJJMjsoWz1m+1ZlrEAlGnyLfofmj17VGqMtG2mDuB Sb9ciGqwt0VT42duBWcHpHn+3DwrnK+G63K6K0yk= Date: Mon, 20 Apr 2020 18:13:51 -0700 From: Andrew Morton To: akpm@linux-foundation.org, jgg@mellanox.com, linux-mm@kvack.org, longpeng2@huawei.com, mike.kravetz@oracle.com, mm-commits@vger.kernel.org, sean.j.christopherson@intel.com, stable@vger.kernel.org, torvalds@linux-foundation.org, willy@infradead.org Subject: [patch 05/15] mm/hugetlb: fix a addressing exception caused by huge_pte_offset Message-ID: <20200421011351.qwgQp5LVv%akpm@linux-foundation.org> In-Reply-To: <20200420181310.c18b3c0aa4dc5b3e5ec1be10@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Longpeng Subject: mm/hugetlb: fix a addressing exception caused by huge_pte_offset Our machine encountered a panic(addressing exception) after run for a long time and the calltrace is: RIP: 0010:[] [] hugetlb_fault+0x307/0xbe0 RSP: 0018:ffff9567fc27f808 EFLAGS: 00010286 RAX: e800c03ff1258d48 RBX: ffffd3bb003b69c0 RCX: e800c03ff1258d48 RDX: 17ff3fc00eda72b7 RSI: 00003ffffffff000 RDI: e800c03ff1258d48 RBP: ffff9567fc27f8c8 R08: e800c03ff1258d48 R09: 0000000000000080 R10: ffffaba0704c22a8 R11: 0000000000000001 R12: ffff95c87b4b60d8 R13: 00005fff00000000 R14: 0000000000000000 R15: ffff9567face8074 FS: 00007fe2d9ffb700(0000) GS:ffff956900e40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffd3bb003b69c0 CR3: 000000be67374000 CR4: 00000000003627e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: [] ? unlock_page+0x2b/0x30 [] ? hugetlb_fault+0x222/0xbe0 [] follow_hugetlb_page+0x175/0x540 [] ? cpumask_next_and+0x35/0x50 [] __get_user_pages+0x2a0/0x7e0 [] __get_user_pages_unlocked+0x15d/0x210 [] __gfn_to_pfn_memslot+0x3c5/0x460 [kvm] [] try_async_pf+0x6e/0x2a0 [kvm] [] tdp_page_fault+0x151/0x2d0 [kvm] ... [] kvm_arch_vcpu_ioctl_run+0x330/0x490 [kvm] [] kvm_vcpu_ioctl+0x309/0x6d0 [kvm] [] ? dequeue_signal+0x32/0x180 [] ? do_sigtimedwait+0xcd/0x230 [] do_vfs_ioctl+0x3f0/0x540 [] SyS_ioctl+0xa1/0xc0 [] system_call_fastpath+0x22/0x27 For 1G hugepages, huge_pte_offset() wants to return NULL or pudp, but it may return a wrong 'pmdp' if there is a race. Please look at the following code snippet: ... pud = pud_offset(p4d, addr); if (sz != PUD_SIZE && pud_none(*pud)) return NULL; /* hugepage or swap? */ if (pud_huge(*pud) || !pud_present(*pud)) return (pte_t *)pud; pmd = pmd_offset(pud, addr); if (sz != PMD_SIZE && pmd_none(*pmd)) return NULL; /* hugepage or swap? */ if (pmd_huge(*pmd) || !pmd_present(*pmd)) return (pte_t *)pmd; ... The following sequence would trigger this bug: 1. CPU0: sz = PUD_SIZE and *pud = 0 , continue 1. CPU0: "pud_huge(*pud)" is false 2. CPU1: calling hugetlb_no_page and set *pud to xxxx8e7(PRESENT) 3. CPU0: "!pud_present(*pud)" is false, continue 4. CPU0: pmd = pmd_offset(pud, addr) and maybe return a wrong pmdp However, we want CPU0 to return NULL or pudp in this case. We must make sure there is exactly one dereference of pud and pmd. Link: http://lkml.kernel.org/r/20200413010342.771-1-longpeng2@huawei.com Signed-off-by: Longpeng Reviewed-by: Mike Kravetz Reviewed-by: Jason Gunthorpe Cc: Matthew Wilcox Cc: Sean Christopherson Cc: Signed-off-by: Andrew Morton --- mm/hugetlb.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/mm/hugetlb.c~mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset +++ a/mm/hugetlb.c @@ -5365,8 +5365,8 @@ pte_t *huge_pte_offset(struct mm_struct { pgd_t *pgd; p4d_t *p4d; - pud_t *pud; - pmd_t *pmd; + pud_t *pud, pud_entry; + pmd_t *pmd, pmd_entry; pgd = pgd_offset(mm, addr); if (!pgd_present(*pgd)) @@ -5376,17 +5376,19 @@ pte_t *huge_pte_offset(struct mm_struct return NULL; pud = pud_offset(p4d, addr); - if (sz != PUD_SIZE && pud_none(*pud)) + pud_entry = READ_ONCE(*pud); + if (sz != PUD_SIZE && pud_none(pud_entry)) return NULL; /* hugepage or swap? */ - if (pud_huge(*pud) || !pud_present(*pud)) + if (pud_huge(pud_entry) || !pud_present(pud_entry)) return (pte_t *)pud; pmd = pmd_offset(pud, addr); - if (sz != PMD_SIZE && pmd_none(*pmd)) + pmd_entry = READ_ONCE(*pmd); + if (sz != PMD_SIZE && pmd_none(pmd_entry)) return NULL; /* hugepage or swap? */ - if (pmd_huge(*pmd) || !pmd_present(*pmd)) + if (pmd_huge(pmd_entry) || !pmd_present(pmd_entry)) return (pte_t *)pmd; return NULL; From patchwork Tue Apr 21 01:14:20 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 227380 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C0C9C54FCC for ; Tue, 21 Apr 2020 01:14:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 40FF6214AF for ; Tue, 21 Apr 2020 01:14:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587431662; bh=POEvJdt69gGHvAgZYMOBFNyiIXP6vxMXEMUcWRPFzFY=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=nmBOk5LxOreNq42zIFTl0IglMX0P8ksC3NYSL7D01y59lO6JSEHqP51LOV9hRXuU1 yOJZKNN1K4Lfc34eNUDSX47XIm6g1zxcjzp1+h8OfmiqAGuDKfTom+HRYO8aHrnDlq gUBPg0XdnqG4dyVlP6RDbZ1sOycj6Y2NHbY+QLJE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726161AbgDUBOV (ORCPT ); Mon, 20 Apr 2020 21:14:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:35892 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726109AbgDUBOV (ORCPT ); Mon, 20 Apr 2020 21:14:21 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0A8142070B; Tue, 21 Apr 2020 01:14:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587431661; bh=POEvJdt69gGHvAgZYMOBFNyiIXP6vxMXEMUcWRPFzFY=; h=Date:From:To:Subject:In-Reply-To:From; b=LpftIEp+Tyvxyzzzs0DUvlX2i5LW9MKTICmE6CaFccckP/BjS30QmSGpdJh9l3aBw cAbgHMNsmdN6GEfAxkgTV/vc3mGlrtOFxQ5go86h5DCHxXh+kMxJ0E/LItA2rbzuNp QV30MFGmvLRBVMEibvfk/EsMZ2ExXmT8y9VuATxA= Date: Mon, 20 Apr 2020 18:14:20 -0700 From: Andrew Morton To: akpm@linux-foundation.org, linux-mm@kvack.org, matthew.ruffell@canonical.com, mm-commits@vger.kernel.org, nhorman@tuxdriver.com, pabs3@bonedaddy.net, stable@vger.kernel.org, sudipm.mukherjee@gmail.com, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk Subject: [patch 14/15] coredump: fix null pointer dereference on coredump Message-ID: <20200421011420.GnVj8rZfk%akpm@linux-foundation.org> In-Reply-To: <20200420181310.c18b3c0aa4dc5b3e5ec1be10@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sudip Mukherjee Subject: coredump: fix null pointer dereference on coredump If the core_pattern is set to "|" and any process segfaults then we get a null pointer derefernce while trying to coredump. The call stack shows: [ 108.212680] RIP: 0010:do_coredump+0x628/0x11c0 When the core_pattern has only "|" there is no use of trying the coredump and we can check that while formating the corename and exit with an error. After this change I get: [ 48.453756] format_corename failed [ 48.453758] Aborting core Link: http://lkml.kernel.org/r/20200416194612.21418-1-sudipm.mukherjee@gmail.com Fixes: 315c69261dd3 ("coredump: split pipe command whitespace before expanding template") Signed-off-by: Sudip Mukherjee Reported-by: Matthew Ruffell Cc: Paul Wise Cc: Alexander Viro Cc: Neil Horman Cc: Signed-off-by: Andrew Morton --- fs/coredump.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/coredump.c~coredump-fix-null-pointer-dereference-on-coredump +++ a/fs/coredump.c @@ -211,6 +211,8 @@ static int format_corename(struct core_n return -ENOMEM; (*argv)[(*argc)++] = 0; ++pat_ptr; + if (!(*pat_ptr)) + return -ENOMEM; } /* Repeat as long as we have more pattern to process and more output