From patchwork Thu Mar 11 00:06:16 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 397323 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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=ham 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 7E220C433DB for ; Thu, 11 Mar 2021 00:07:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5329964FCD for ; Thu, 11 Mar 2021 00:07:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229643AbhCKAG3 (ORCPT ); Wed, 10 Mar 2021 19:06:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:45672 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229593AbhCKAGR (ORCPT ); Wed, 10 Mar 2021 19:06:17 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id D36CE64E33; Thu, 11 Mar 2021 00:06:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1615421177; bh=eBw6Er0rU51Hw+o8upNvkWLSj/B7ASVGL2a9wlNGeIE=; h=Date:From:To:Subject:From; b=vNkU0N+sUHsBzQG4Yh63Oh+jpN8RkQM7gr+cyW4fSrAGRQmuQQ0NgQW+u9nqfRk5X twI167aezceeTX5Diulwfa/wFzi4FCtIDPSFYLZ5Q49a50xQmXibURH8mfz5f8KnVG 2tOSGeDeYMO1AyuuSutXoqy5amvPHx2sSOMu6jzw= Date: Wed, 10 Mar 2021 16:06:16 -0800 From: akpm@linux-foundation.org To: aarcange@redhat.com, bgardon@google.com, dimitri.sivanich@hpe.com, hannes@cmpxchg.org, jgg@ziepe.ca, jglisse@redhat.com, mhocko@suse.com, mm-commits@vger.kernel.org, rientjes@google.com, seanjc@google.com, stable@vger.kernel.org Subject: + mm-oom_kill-ensure-mmu-notifier-range_end-is-paired-with-range_start.patch added to -mm tree Message-ID: <20210311000616.GIEHU6C1Q%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch titled Subject: mm/oom_kill: ensure MMU notifier range_end() is paired with range_start() has been added to the -mm tree. Its filename is mm-oom_kill-ensure-mmu-notifier-range_end-is-paired-with-range_start.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/mm-oom_kill-ensure-mmu-notifier-range_end-is-paired-with-range_start.patch and later at https://ozlabs.org/~akpm/mmotm/broken-out/mm-oom_kill-ensure-mmu-notifier-range_end-is-paired-with-range_start.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: Sean Christopherson Subject: mm/oom_kill: ensure MMU notifier range_end() is paired with range_start() Invoke the MMU notifier's .invalidate_range_end() callbacks even if one of the .invalidate_range_start() callbacks failed. If there are multiple notifiers, the notifier that did not fail may have performed actions in its ...start() that it expects to unwind via ...end(). Per the mmu_notifier_ops documentation, ...start() and ...end() must be paired. The only in-kernel usage that is fatally broken is the SGI UV GRU driver, which effectively blocks and sleeps fault handlers during ...start(), and unblocks/wakes the handlers during ...end(). But, the only users that can fail ...start() are the i915 and Nouveau drivers, which are unlikely to collide with the SGI driver. KVM is the only other user of ...end(), and while KVM also blocks fault handlers in ...start(), the fault handlers do not sleep and originate in killable ioctl() calls. So while it's possible for the i915 and Nouveau drivers to collide with KVM, the bug is benign for KVM since the process is dying and KVM's guest is about to be terminated. So, as of today, the bug is likely benign. But, that may not always be true, e.g. there is a potential use case for blocking memslot updates in KVM while an invalidation is in-progress, and failure to unblock would result in said updates being blocked indefinitely and hanging. Found by inspection. Verified by adding a second notifier in KVM that periodically returns -EAGAIN on non-blockable ranges, triggering OOM, and observing that KVM exits with an elevated notifier count. Link: https://lkml.kernel.org/r/20210310213117.1444147-1-seanjc@google.com Fixes: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers") Signed-off-by: Sean Christopherson Reviewed-by: Ben Gardon Cc: David Rientjes Cc: Jason Gunthorpe Cc: Michal Hocko Cc: "Jérôme Glisse" Cc: Andrea Arcangeli Cc: Johannes Weiner Cc: Dimitri Sivanich Cc: Signed-off-by: Andrew Morton --- mm/oom_kill.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/mm/oom_kill.c~mm-oom_kill-ensure-mmu-notifier-range_end-is-paired-with-range_start +++ a/mm/oom_kill.c @@ -546,12 +546,10 @@ bool __oom_reap_task_mm(struct mm_struct vma, mm, vma->vm_start, vma->vm_end); tlb_gather_mmu(&tlb, mm); - if (mmu_notifier_invalidate_range_start_nonblock(&range)) { - tlb_finish_mmu(&tlb); + if (!mmu_notifier_invalidate_range_start_nonblock(&range)) + unmap_page_range(&tlb, vma, range.start, range.end, NULL); + else ret = false; - continue; - } - unmap_page_range(&tlb, vma, range.start, range.end, NULL); mmu_notifier_invalidate_range_end(&range); tlb_finish_mmu(&tlb); }