[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080417163642.GE11364@sgi.com>
Date: Thu, 17 Apr 2008 11:36:42 -0500
From: Robin Holt <holt@....com>
To: Andrea Arcangeli <andrea@...ranet.com>
Cc: Christoph Lameter <clameter@....com>, Robin Holt <holt@....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,
Avi Kivity <avi@...ranet.com>, kvm-devel@...ts.sourceforge.net,
general@...ts.openfabrics.org, Hugh Dickins <hugh@...itas.com>
Subject: Re: [PATCH 1 of 9] Lock the entire mm to prevent any mmu related
operation to happen
On Thu, Apr 17, 2008 at 05:51:57PM +0200, Andrea Arcangeli wrote:
> On Wed, Apr 16, 2008 at 11:35:38AM -0700, Christoph Lameter wrote:
> > On Wed, 16 Apr 2008, Robin Holt wrote:
> >
> > > I don't think this lock mechanism is completely working. I have
> > > gotten a few failures trying to dereference 0x100100 which appears to
> > > be LIST_POISON1.
> >
> > How does xpmem unregistering of notifiers work?
>
> Especially are you using mmu_notifier_unregister?
In this case, we are not making the call to unregister, we are waiting
for the _release callout which has already removed it from the list.
In the event that the user has removed all the grants, we use unregister.
That typically does not occur. We merely wait for exit processing to
clean up the structures.
Thanks,
Robin
--
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