linux-toradex.git/mm/mmap.c, branch v2.6.27.17

System call wrappers part 13

2009-01-18T18:35:36+00:00

commit 6a6160a7b5c27b3c38651baef92a14fa7072b3c1 upstream.

Signed-off-by: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman

Convert all system calls to return a long

2009-01-18T18:35:30+00:00

commit 2ed7c03ec17779afb4fcfa3b8c61df61bd4879ba upstream.

Convert all system calls to return a long. This should be a NOP since all
converted types should have the same size anyway.
With the exception of sys_exit_group which returned void. But that doesn't
matter since the system call doesn't return.

Signed-off-by: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman

mmap: fix petty bug in anonymous shared mmap offset handling

2008-09-04T02:58:53+00:00

Anonymous mappings should ignore offset but shared anonymous mapping
forgot to clear it and makes the following legit test program trigger
SIGBUS.

 #include 
 #include 
 #include 

 #define PAGE_SIZE	4096

 int main(void)
 {
	 char *p;
	 int i;

	 p = mmap(NULL, 2 * PAGE_SIZE, PROT_READ|PROT_WRITE,
		  MAP_SHARED|MAP_ANONYMOUS, -1, PAGE_SIZE);
	 if (p == MAP_FAILED) {
		 perror("mmap");
		 return 1;
	 }

	 for (i = 0; i < 2; i++) {
		 printf("page %d\n", i);
		 p[i * 4096] = i;
	 }
	 return 0;
 }

Fix it.

Signed-off-by: Tejun Heo 
Acked-by: Hugh Dickins 
Acked-by: KOSAKI Motohiro 
Signed-off-by: Linus Torvalds

Merge branch 'core/locking' into core/urgent

2008-08-11T22:11:49+00:00

mm: fix mm_take_all_locks() locking order

2008-08-11T07:30:25+00:00

Lockdep spotted:

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.27-rc1 #270
-------------------------------------------------------
qemu-kvm/2033 is trying to acquire lock:
 (&inode->i_data.i_mmap_lock){----}, at: [] mm_take_all_locks+0xc2/0xea

but task is already holding lock:
 (&anon_vma->lock){----}, at: [] mm_take_all_locks+0x70/0xea

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&anon_vma->lock){----}:
       [] __lock_acquire+0x11be/0x14d2
       [] lock_acquire+0x5e/0x7a
       [] _spin_lock+0x3b/0x47
       [] vma_adjust+0x200/0x444
       [] split_vma+0x12f/0x146
       [] mprotect_fixup+0x13c/0x536
       [] sys_mprotect+0x1a9/0x21e
       [] system_call_fastpath+0x16/0x1b
       [] 0xffffffffffffffff

-> #0 (&inode->i_data.i_mmap_lock){----}:
       [] __lock_acquire+0xedb/0x14d2
       [] lock_release_non_nested+0x1c2/0x219
       [] lock_release+0x127/0x14a
       [] _spin_unlock+0x1e/0x50
       [] mm_drop_all_locks+0x7f/0xb0
       [] do_mmu_notifier_register+0xe2/0x112
       [] mmu_notifier_register+0xe/0x10
       [] kvm_dev_ioctl+0x11e/0x287 [kvm]
       [] vfs_ioctl+0x2a/0x78
       [] do_vfs_ioctl+0x257/0x274
       [] sys_ioctl+0x55/0x78
       [] system_call_fastpath+0x16/0x1b
       [] 0xffffffffffffffff

other info that might help us debug this:

5 locks held by qemu-kvm/2033:
 #0:  (&mm->mmap_sem){----}, at: [] do_mmu_notifier_register+0x55/0x112
 #1:  (mm_all_locks_mutex){--..}, at: [] mm_take_all_locks+0x34/0xea
 #2:  (&anon_vma->lock){----}, at: [] mm_take_all_locks+0x70/0xea
 #3:  (&anon_vma->lock){----}, at: [] mm_take_all_locks+0x70/0xea
 #4:  (&anon_vma->lock){----}, at: [] mm_take_all_locks+0x70/0xea

stack backtrace:
Pid: 2033, comm: qemu-kvm Not tainted 2.6.27-rc1 #270

Call Trace:
 [] print_circular_bug_tail+0xb8/0xc3
 [] __lock_acquire+0xedb/0x14d2
 [] ? add_lock_to_list+0x7e/0xad
 [] ? mm_take_all_locks+0x70/0xea
 [] ? mm_take_all_locks+0x70/0xea
 [] lock_release_non_nested+0x1c2/0x219
 [] ? mm_take_all_locks+0xc2/0xea
 [] ? mm_take_all_locks+0xc2/0xea
 [] ? trace_hardirqs_on_caller+0x4d/0x115
 [] ? mm_drop_all_locks+0x7f/0xb0
 [] lock_release+0x127/0x14a
 [] _spin_unlock+0x1e/0x50
 [] mm_drop_all_locks+0x7f/0xb0
 [] do_mmu_notifier_register+0xe2/0x112
 [] mmu_notifier_register+0xe/0x10
 [] kvm_dev_ioctl+0x11e/0x287 [kvm]
 [] ? file_has_perm+0x83/0x8e
 [] vfs_ioctl+0x2a/0x78
 [] do_vfs_ioctl+0x257/0x274
 [] sys_ioctl+0x55/0x78
 [] system_call_fastpath+0x16/0x1b

Which the locking hierarchy in mm/rmap.c confirms as valid.

Fix this by first taking all the mapping->i_mmap_lock instances and then
take all anon_vma->lock instances.

Signed-off-by: Peter Zijlstra 
Acked-by: Hugh Dickins 
Signed-off-by: Ingo Molnar

lockdep: annotate mm_take_all_locks()

2008-08-11T07:30:25+00:00

The nesting is correct due to holding mmap_sem, use the new annotation
to annotate this.

Signed-off-by: Peter Zijlstra 
Signed-off-by: Ingo Molnar

mm: fix uninitialized variables for find_vma_prepare callers

2008-08-05T21:33:50+00:00

gcc 4.3.0 correctly emits the following warnings.
When a vma covering addr is found, find_vma_prepare indeed returns without
setting pprev, rb_link, and rb_parent.

  mm/mmap.c: In function `insert_vm_struct':
  mm/mmap.c:2085: warning: `rb_parent' may be used uninitialized in this function
  mm/mmap.c:2085: warning: `rb_link' may be used uninitialized in this function
  mm/mmap.c:2084: warning: `prev' may be used uninitialized in this function
  mm/mmap.c: In function `copy_vma':
  mm/mmap.c:2124: warning: `rb_parent' may be used uninitialized in this function
  mm/mmap.c:2124: warning: `rb_link' may be used uninitialized in this function
  mm/mmap.c:2123: warning: `prev' may be used uninitialized in this function
  mm/mmap.c: In function `do_brk':
  mm/mmap.c:1951: warning: `rb_parent' may be used uninitialized in this function
  mm/mmap.c:1951: warning: `rb_link' may be used uninitialized in this function
  mm/mmap.c:1949: warning: `prev' may be used uninitialized in this function
  mm/mmap.c: In function `mmap_region':
  mm/mmap.c:1092: warning: `rb_parent' may be used uninitialized in this function
  mm/mmap.c:1092: warning: `rb_link' may be used uninitialized in this function
  mm/mmap.c:1089: warning: `prev' may be used uninitialized in this function

Hugh adds: in fact, none of find_vma_prepare's callers use those values
when a vma is found to be already covering addr, it's either an error or
an occasion to munmap and repeat.  Okay, let's quieten the compiler (but I
would prefer it if pprev, rb_link and rb_parent were meaningful in that
case, rather than whatever's in them from descending the tree).

Signed-off-by: Benny Halevy 
Signed-off-by: Hugh Dickins 
Cc: "Ryan Hope" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mmu-notifiers: core

2008-07-28T23:30:21+00:00

With KVM/GFP/XPMEM there isn't just the primary CPU MMU pointing to pages.
 There are secondary MMUs (with secondary sptes and secondary tlbs) too.
sptes in the kvm case are shadow pagetables, but when I say spte in
mmu-notifier context, I mean "secondary pte".  In GRU case there's no
actual secondary pte and there's only a secondary tlb because the GRU
secondary MMU has no knowledge about sptes and every secondary tlb miss
event in the MMU always generates a page fault that has to be resolved by
the CPU (this is not the case of KVM where the a secondary tlb miss will
walk sptes in hardware and it will refill the secondary tlb transparently
to software if the corresponding spte is present).  The same way
zap_page_range has to invalidate the pte before freeing the page, the spte
(and secondary tlb) must also be invalidated before any page is freed and
reused.

Currently we take a page_count pin on every page mapped by sptes, but that
means the pages can't be swapped whenever they're mapped by any spte
because they're part of the guest working set.  Furthermore a spte unmap
event can immediately lead to a page to be freed when the pin is released
(so requiring the same complex and relatively slow tlb_gather smp safe
logic we have in zap_page_range and that can be avoided completely if the
spte unmap event doesn't require an unpin of the page previously mapped in
the secondary MMU).

The mmu notifiers allow kvm/GRU/XPMEM to attach to the tsk->mm and know
when the VM is swapping or freeing or doing anything on the primary MMU so
that the secondary MMU code can drop sptes before the pages are freed,
avoiding all page pinning and allowing 100% reliable swapping of guest
physical address space.  Furthermore it avoids the code that teardown the
mappings of the secondary MMU, to implement a logic like tlb_gather in
zap_page_range that would require many IPI to flush other cpu tlbs, for
each fixed number of spte unmapped.

To make an example: if what happens on the primary MMU is a protection
downgrade (from writeable to wrprotect) the secondary MMU mappings will be
invalidated, and the next secondary-mmu-page-fault will call
get_user_pages and trigger a do_wp_page through get_user_pages if it
called get_user_pages with write=1, and it'll re-establishing an updated
spte or secondary-tlb-mapping on the copied page.  Or it will setup a
readonly spte or readonly tlb mapping if it's a guest-read, if it calls
get_user_pages with write=0.  This is just an example.

This allows to map any page pointed by any pte (and in turn visible in the
primary CPU MMU), into a secondary MMU (be it a pure tlb like GRU, or an
full MMU with both sptes and secondary-tlb like the shadow-pagetable layer
with kvm), or a remote DMA in software like XPMEM (hence needing of
schedule in XPMEM code to send the invalidate to the remote node, while no
need to schedule in kvm/gru as it's an immediate event like invalidating
primary-mmu pte).

At least for KVM without this patch it's impossible to swap guests
reliably.  And having this feature and removing the page pin allows
several other optimizations that simplify life considerably.

Dependencies:

1) mm_take_all_locks() to register the mmu notifier when the whole VM
   isn't doing anything with "mm".  This allows mmu notifier users to keep
   track if the VM is in the middle of the invalidate_range_begin/end
   critical section with an atomic counter incraese in range_begin and
   decreased in range_end.  No secondary MMU page fault is allowed to map
   any spte or secondary tlb reference, while the VM is in the middle of
   range_begin/end as any page returned by get_user_pages in that critical
   section could later immediately be freed without any further
   ->invalidate_page notification (invalidate_range_begin/end works on
   ranges and ->invalidate_page isn't called immediately before freeing
   the page).  To stop all page freeing and pagetable overwrites the
   mmap_sem must be taken in write mode and all other anon_vma/i_mmap
   locks must be taken too.

2) It'd be a waste to add branches in the VM if nobody could possibly
   run KVM/GRU/XPMEM on the kernel, so mmu notifiers will only enabled if
   CONFIG_KVM=m/y.  In the current kernel kvm won't yet take advantage of
   mmu notifiers, but this already allows to compile a KVM external module
   against a kernel with mmu notifiers enabled and from the next pull from
   kvm.git we'll start using them.  And GRU/XPMEM will also be able to
   continue the development by enabling KVM=m in their config, until they
   submit all GRU/XPMEM GPLv2 code to the mainline kernel.  Then they can
   also enable MMU_NOTIFIERS in the same way KVM does it (even if KVM=n).
   This guarantees nobody selects MMU_NOTIFIER=y if KVM and GRU and XPMEM
   are all =n.

The mmu_notifier_register call can fail because mm_take_all_locks may be
interrupted by a signal and return -EINTR.  Because mmu_notifier_reigster
is used when a driver startup, a failure can be gracefully handled.  Here
an example of the change applied to kvm to register the mmu notifiers.
Usually when a driver startups other allocations are required anyway and
-ENOMEM failure paths exists already.

 struct  kvm *kvm_arch_create_vm(void)
 {
        struct kvm *kvm = kzalloc(sizeof(struct kvm), GFP_KERNEL);
+       int err;

        if (!kvm)
                return ERR_PTR(-ENOMEM);

        INIT_LIST_HEAD(&kvm->arch.active_mmu_pages);

+       kvm->arch.mmu_notifier.ops = &kvm_mmu_notifier_ops;
+       err = mmu_notifier_register(&kvm->arch.mmu_notifier, current->mm);
+       if (err) {
+               kfree(kvm);
+               return ERR_PTR(err);
+       }
+
        return kvm;
 }

mmu_notifier_unregister returns void and it's reliable.

The patch also adds a few needed but missing includes that would prevent
kernel to compile after these changes on non-x86 archs (x86 didn't need
them by luck).

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix mm/filemap_xip.c build]
[akpm@linux-foundation.org: fix mm/mmu_notifier.c build]
Signed-off-by: Andrea Arcangeli 
Signed-off-by: Nick Piggin 
Signed-off-by: Christoph Lameter 
Cc: Jack Steiner 
Cc: Robin Holt 
Cc: Nick Piggin 
Cc: Peter Zijlstra 
Cc: Kanoj Sarcar 
Cc: Roland Dreier 
Cc: Steve Wise 
Cc: Avi Kivity 
Cc: Hugh Dickins 
Cc: Rusty Russell 
Cc: Anthony Liguori 
Cc: Chris Wright 
Cc: Marcelo Tosatti 
Cc: Eric Dumazet 
Cc: "Paul E. McKenney" 
Cc: Izik Eidus 
Cc: Anthony Liguori 
Cc: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mmu-notifiers: add mm_take_all_locks() operation

2008-07-28T23:30:21+00:00

mm_take_all_locks holds off reclaim from an entire mm_struct.  This allows
mmu notifiers to register into the mm at any time with the guarantee that
no mmu operation is in progress on the mm.

This operation locks against the VM for all pte/vma/mm related operations
that could ever happen on a certain mm.  This includes vmtruncate,
try_to_unmap, and all page faults.

The caller must take the mmap_sem in write mode before calling
mm_take_all_locks().  The caller isn't allowed to release the mmap_sem
until mm_drop_all_locks() returns.

mmap_sem in write mode is required in order to block all operations that
could modify pagetables and free pages without need of altering the vma
layout (for example populate_range() with nonlinear vmas).  It's also
needed in write mode to avoid new anon_vmas to be associated with existing
vmas.

A single task can't take more than one mm_take_all_locks() in a row or it
would deadlock.

mm_take_all_locks() and mm_drop_all_locks are expensive operations that
may have to take thousand of locks.

mm_take_all_locks() can fail if it's interrupted by signals.

When mmu_notifier_register returns, we must be sure that the driver is
notified if some task is in the middle of a vmtruncate for the 'mm' where
the mmu notifier was registered (mmu_notifier_invalidate_range_start/end
is run around the vmtruncation but mmu_notifier_register can run after
mmu_notifier_invalidate_range_start and before
mmu_notifier_invalidate_range_end).  Same problem for rmap paths.  And
we've to remove page pinning to avoid replicating the tlb_gather logic
inside KVM (and GRU doesn't work well with page pinning regardless of
needing tlb_gather), so without mm_take_all_locks when vmtruncate frees
the page, kvm would have no way to notice that it mapped into sptes a page
that is going into the freelist without a chance of any further
mmu_notifier notification.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Andrea Arcangeli 
Acked-by: Linus Torvalds 
Cc: Christoph Lameter 
Cc: Jack Steiner 
Cc: Robin Holt 
Cc: Nick Piggin 
Cc: Peter Zijlstra 
Cc: Kanoj Sarcar 
Cc: Roland Dreier 
Cc: Steve Wise 
Cc: Avi Kivity 
Cc: Hugh Dickins 
Cc: Rusty Russell 
Cc: Anthony Liguori 
Cc: Chris Wright 
Cc: Marcelo Tosatti 
Cc: Eric Dumazet 
Cc: "Paul E. McKenney" 
Cc: Izik Eidus 
Cc: Anthony Liguori 
Cc: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hugetlb: modular state for hugetlb page size

2008-07-24T17:47:17+00:00

The goal of this patchset is to support multiple hugetlb page sizes.  This
is achieved by introducing a new struct hstate structure, which
encapsulates the important hugetlb state and constants (eg.  huge page
size, number of huge pages currently allocated, etc).

The hstate structure is then passed around the code which requires these
fields, they will do the right thing regardless of the exact hstate they
are operating on.

This patch adds the hstate structure, with a single global instance of it
(default_hstate), and does the basic work of converting hugetlb to use the
hstate.

Future patches will add more hstate structures to allow for different
hugetlbfs mounts to have different page sizes.

[akpm@linux-foundation.org: coding-style fixes]
Acked-by: Adam Litke 
Acked-by: Nishanth Aravamudan 
Signed-off-by: Andi Kleen 
Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds