From: Jason Gunthorpe <jgg@ziepe.ca>
To: Sean Christopherson <seanjc@google.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"David Rientjes" <rientjes@google.com>,
"Ben Gardon" <bgardon@google.com>,
"Michal Hocko" <mhocko@suse.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Andrea Arcangeli" <aarcange@redhat.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Dimitri Sivanich" <dimitri.sivanich@hpe.com>
Subject: Re: [PATCH] mm/oom_kill: Ensure MMU notifier range_end() is paired with range_start()
Date: Wed, 10 Mar 2021 21:50:13 -0400 [thread overview]
Message-ID: <20210311015013.GS444867@ziepe.ca> (raw)
In-Reply-To: <YElwQU9mPUNwPg7q@google.com>
On Wed, Mar 10, 2021 at 05:20:01PM -0800, Sean Christopherson wrote:
> > Which I believe is fatal to kvm? These notifiers certainly do not only
> > happen at process exit.
>
> My point about the process dying is that the existing bug that causes
> mmu_notifier_count to become imbalanced is benign only because the process is
> being killed, and thus KVM will stop running its vCPUs.
Are you saying we only call non-blocking invalidate during a process
exit event??
> > So, both of the remaining _end users become corrupted with this patch!
>
> I don't follow. mn_hlist_invalidate_range_start() iterates over all
> notifiers, even if a notifier earlier in the chain failed. How will
> KVM become imbalanced?
Er, ok, that got left in a weird way. There is another "bug" where end
is not supposed to be called if the start failed.
> The existing _end users never fail their _start. If KVM started failing its
> start, then yes, it could get corrupted.
Well, maybe that is the way out of this now. If we don't permit a
start to fail if there is an end then we have no problem to unwind it
as we can continue to call everything. This can't be backported too
far though, the itree notifier conversions are what made the WARN_ON
safe today.
Something very approximately like this is closer to my preference:
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 61ee40ed804ee5..6d5cd20f81dadc 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -501,10 +501,25 @@ static int mn_hlist_invalidate_range_start(
"");
WARN_ON(mmu_notifier_range_blockable(range) ||
_ret != -EAGAIN);
+ /*
+ * We call all the notifiers on any EAGAIN,
+ * there is no way for a notifier to know if
+ * its start method failed, thus a start that
+ * does EAGAIN can't also do end.
+ */
+ WARN_ON(ops->invalidate_range_end);
ret = _ret;
}
}
}
+
+ if (ret) {
+ /* Must be non-blocking to get here*/
+ hlist_for_each_entry_rcu (subscription, &subscriptions->list,
+ hlist, srcu_read_lock_held(&srcu))
+ subscription->ops->invalidate_range_end(subscription,
+ range);
+ }
srcu_read_unlock(&srcu, id);
return ret;
next prev parent reply other threads:[~2021-03-11 1:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 21:31 Sean Christopherson
2021-03-10 22:08 ` Ben Gardon
2021-03-11 0:06 ` Andrew Morton
2021-03-11 0:28 ` Jason Gunthorpe
2021-03-11 1:20 ` Sean Christopherson
2021-03-11 1:50 ` Jason Gunthorpe [this message]
2021-03-11 7:22 ` Sean Christopherson
2021-03-11 16:20 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210311015013.GS444867@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bgardon@google.com \
--cc=dimitri.sivanich@hpe.com \
--cc=hannes@cmpxchg.org \
--cc=jglisse@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=rientjes@google.com \
--cc=seanjc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox