Andrew Morton wrote:

On Thu, 15 Feb 2007 23:08:02 -0800 Jeremy Fitzhardinge [off-list ref] wrote:

  

quoted

Andrew Morton wrote:
    

quoted

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.
  

It's for populating the pagetable in a vmalloc area.  There's magic in
the fault handler to synchronize the vmalloc mappings between different
process's kernel mappings, so if the mapping isn't currently present, it
will fault and create the appropriate mapping.  It's not operating on
swappable user memory, so swapping isn't an issue; but if the fault
handler exits immediately with preempt disabled, then there's a problem.

(Even though we don't support preempt, I've been generally coding in a
preempt-safe way, just so that the code looks "normal".  And maybe we
will support preempt at some point.)

    J