Merge branch 'akpm' (patches from Andrew)

2) for querying the policy, we do not need to take an extra reference on the

   target task's task policy nor vma policies because we always acquire the

   task's mm's mmap_sem for read during the query.  The set_mempolicy() and

   mbind() APIs [see below] always acquire the mmap_sem for write when

   task's mm's mmap_lock for read during the query.  The set_mempolicy() and

   mbind() APIs [see below] always acquire the mmap_lock for write when

   installing or replacing task or vma policies.  Thus, there is no possibility

   of a task or thread freeing a policy while another task or thread is

   querying it.

3) Page allocation usage of task or vma policy occurs in the fault path where

   we hold them mmap_sem for read.  Again, because replacing the task or vma

   policy requires that the mmap_sem be held for write, the policy can't be

   we hold them mmap_lock for read.  Again, because replacing the task or vma

   policy requires that the mmap_lock be held for write, the policy can't be

   freed out from under us while we're using it for page allocation.

4) Shared policies require special consideration.  One task can replace a

   shared memory policy while another task, with a distinct mmap_sem, is

   shared memory policy while another task, with a distinct mmap_lock, is

   querying or allocating a page based on the policy.  To resolve this

   potential race, the shared policy infrastructure adds an extra reference

   to the shared policy during lookup while holding a spin lock on the shared

The real advantage of userfaults if compared to regular virtual memory

management of mremap/mprotect is that the userfaults in all their

operations never involve heavyweight structures like vmas (in fact the

``userfaultfd`` runtime load never takes the mmap_sem for writing).

``userfaultfd`` runtime load never takes the mmap_lock for writing).

Vmas are not suitable for page- (or hugepage) granular fault tracking

when dealing with virtual address spaces that could span

locking rules:

=============	========	===========================

ops		mmap_sem	PageLocked(page)

ops		mmap_lock	PageLocked(page)

=============	========	===========================

open:		yes

close:		yes

 again:

      range.notifier_seq = mmu_interval_read_begin(&interval_sub);

      down_read(&mm->mmap_sem);

      mmap_read_lock(mm);

      ret = hmm_range_fault(&range);

      if (ret) {

          up_read(&mm->mmap_sem);

          mmap_read_unlock(mm);

          if (ret == -EBUSY)

                 goto again;

          return ret;

      }

      up_read(&mm->mmap_sem);

      mmap_read_unlock(mm);

      take_lock(driver->update);

      if (mmu_interval_read_retry(&ni, range.notifier_seq) {

To make pagetable walks huge pmd aware, all you need to do is to call

pmd_trans_huge() on the pmd returned by pmd_offset. You must hold the

mmap_sem in read (or write) mode to be sure a huge pmd cannot be

mmap_lock in read (or write) mode to be sure a huge pmd cannot be

created from under you by khugepaged (khugepaged collapse_huge_page

takes the mmap_sem in write mode in addition to the anon_vma lock). If

takes the mmap_lock in write mode in addition to the anon_vma lock). If

pmd_trans_huge returns false, you just fallback in the old code

paths. If instead pmd_trans_huge returns true, you have to take the

page table lock (pmd_lock()) and re-run pmd_trans_huge. Taking the