[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080408220627.GP10133@duo.random>
Date: Wed, 9 Apr 2008 00:06:27 +0200
From: Andrea Arcangeli <andrea@...ranet.com>
To: Avi Kivity <avi@...ranet.com>
Cc: Christoph Lameter <clameter@....com>, akpm@...ux-foundation.org,
Nick Piggin <npiggin@...e.de>,
Steve Wise <swise@...ngridcomputing.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-mm@...ck.org,
Kanoj Sarcar <kanojsarcar@...oo.com>,
Roland Dreier <rdreier@...co.com>,
Jack Steiner <steiner@....com>, linux-kernel@...r.kernel.org,
kvm-devel@...ts.sourceforge.net, Robin Holt <holt@....com>,
general@...ts.openfabrics.org, Hugh Dickins <hugh@...itas.com>
Subject: Re: [PATCH 0 of 9] mmu notifier #v12
On Wed, Apr 09, 2008 at 12:46:49AM +0300, Avi Kivity wrote:
> That's unusual. What happens to the notifier? Suppose I destroy a vm
Yes it's quite unusual.
> without exiting the process, what happens if it fires?
The mmu notifier ops should stop doing stuff (if there will be no
memslots they will be noops), or the ops can be replaced atomically
with null pointers. The important thing is that the module can't go
away until ->release is invoked or until mmu_notifier_unregister
returned 0.
Previously there was no mmu_notifier_unregister, so adding it can't be
a regression compared to #v11, even if it can fail and you may have to
retry later after returning to userland. Retrying from userland is
always safe in oom kill terms, only looping inside the kernel isn't
safe as do_exit has no chance to run.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists