From mboxrd@z Thu Jan 1 00:00:00 1970 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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS 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 2E196C433E0 for ; Thu, 11 Mar 2021 00:06:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 768A464E86 for ; Thu, 11 Mar 2021 00:06:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 768A464E86 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0D3168D0253; Wed, 10 Mar 2021 19:06:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 083818D0250; Wed, 10 Mar 2021 19:06:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E668B8D0253; Wed, 10 Mar 2021 19:06:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id C55308D0250 for ; Wed, 10 Mar 2021 19:06:14 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 65D66363D for ; Thu, 11 Mar 2021 00:06:14 +0000 (UTC) X-FDA: 77905651068.03.4A7C81B Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf02.hostedemail.com (Postfix) with ESMTP id 935194080F59 for ; Thu, 11 Mar 2021 00:06:05 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id B832064E33; Thu, 11 Mar 2021 00:06:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1615421173; bh=qIPv+EoOptfJXUMF6cMDeGl3znse9/XkHNkaEbNi/wo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=f0b8REnlxOBN8ozqESJf7N3DVplCLI7jYw+q348zHSIhwQCfrfsFtNd23ZY45OI+o fkVBWygiVgNKmtF4zeg5tO/6shw5cXu+7/3RPweYzJQNssPQJExGppZwYYsx4C4pwT mR5/Nop6DsNFsOxtV9y2TdB5VCiKrEvY0J9EEbG0= Date: Wed, 10 Mar 2021 16:06:12 -0800 From: Andrew Morton To: Sean Christopherson Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Rientjes , Ben Gardon , Jason Gunthorpe , Michal Hocko , =?ISO-8859-1?Q?"J=E9r=F4m?= =?ISO-8859-1?Q?e_Glisse"?= , Andrea Arcangeli , Johannes Weiner , Dimitri Sivanich Subject: Re: [PATCH] mm/oom_kill: Ensure MMU notifier range_end() is paired with range_start() Message-Id: <20210310160612.dd57fcc60cbc4cc4bf86b869@linux-foundation.org> In-Reply-To: <20210310213117.1444147-1-seanjc@google.com> References: <20210310213117.1444147-1-seanjc@google.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: foe9h7eh7tpszuuw8x7ehkmoy91r5f5m X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 935194080F59 Received-SPF: none (linux-foundation.org>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615421165-526018 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 10 Mar 2021 13:31:17 -0800 Sean Christopherson wrote: > 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. Given that there's no way known of triggering this in 5.11 or earlier, I'd normally question the need to backport into -stable kernels. But I guess that people might later develop modules which they want to load into earlier kernels, in which case this might bite them. So I agree on the cc:stable thing.