[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070215232447.5ee67f50.akpm@linux-foundation.org>
Date: Thu, 15 Feb 2007 23:24:47 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Jeremy Fitzhardinge <jeremy@...p.org>
Cc: Andi Kleen <ak@....de>, linux-kernel@...r.kernel.org,
virtualization@...ts.osdl.org, xen-devel@...ts.xensource.com,
Chris Wright <chrisw@...s-sol.org>,
Zachary Amsden <zach@...are.com>,
Ian Pratt <ian.pratt@...source.com>,
Christian Limpach <Christian.Limpach@...cam.ac.uk>,
Jan Beulich <JBeulich@...ell.com>
Subject: Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
On Thu, 15 Feb 2007 23:08:02 -0800 Jeremy Fitzhardinge <jeremy@...p.org> wrote:
> Andrew Morton wrote:
> > This won't work when CONFIG_PREEMPT=y. The pagefault handler will see
> > in_atomic() and will scram.
> >
>
> Is there some other way to get the pagetable populated for the address
> range?
>
If you really need to run atomically, that gets ugly. Even of one were to
run handle_mm_fault() by hand, it still needs to allocate memory.
Two ugly options might be:
a) touch all the pages, then go atomic, then touch them all again. If
one of them faults (ie: you raced with swapout) then go back and try
again. Obviously susceptible to livelocking.
b) Do get_user_pages() against all the pages, then go atomic, then do
put_page() against them all. Of course, they can immediately get
swapped out.
But that function's already racy against swapout and I guess it works OK.
I don't have clue what it is actually trying to do, so I'm guessing madly
here.
-
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