On Mon, 21 Mar 2011 13:22:30 +1100
Benjamin Herrenschmidt [off-list ref] wrote:

On Sun, 2011-03-20 at 19:20 -0700, Hugh Dickins wrote:

quoted

quoted

As long as the races to avoid are between map/unmap vs. access, yes, it
-should- be fine, and we used to not do demand faulting on kernel space
(but for how long ?). I'm wondering why we don't just stick a ptl in
there or is there a good reason why we can't ?

We can - but we usually prefer to avoid unnecessary locking.
An arch function which locks init_mm.page_table_lock on powerpc,
but does nothing on others? 

That still means gratuitous differences between how the normal and
kernel page tables are handled. Maybe that's not worth bothering ...

So what will we do here?  I still have

mm-remove-unused-token-argument-from-apply_to_page_range-callback.patch
mm-add-apply_to_page_range_batch.patch
ioremap-use-apply_to_page_range_batch-for-ioremap_page_range.patch
vmalloc-use-plain-pte_clear-for-unmaps.patch
vmalloc-use-apply_to_page_range_batch-for-vunmap_page_range.patch
vmalloc-use-apply_to_page_range_batch-for-vmap_page_range_noflush.patch
vmalloc-use-apply_to_page_range_batch-in-alloc_vm_area.patch
xen-mmu-use-apply_to_page_range_batch-in-xen_remap_domain_mfn_range.patch
xen-grant-table-use-apply_to_page_range_batch.patch

floating around and at some stage they may cause merge problems.