Linus Torvalds d9d332e087 anon_vma_prepare: properly lock even newly allocated entries ...

The anon_vma code is very subtle, and we end up doing optimistic lookups
of anon_vmas under RCU in page_lock_anon_vma() with no locking.  Other
CPU's can also see the newly allocated entry immediately after we've
exposed it by setting "vma->anon_vma" to the new value.

We protect against the anon_vma being destroyed by having the SLAB
marked as SLAB_DESTROY_BY_RCU, so the RCU lookup can depend on the
allocation not being destroyed - but it might still be free'd and
re-allocated here to a new vma.

As a result, we should not do the anon_vma list ops on a newly allocated
vma without proper locking.

Acked-by: Nick Piggin <npiggin@suse.de>
Acked-by: Hugh Dickins <hugh@veritas.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2008-10-19 11:50:35 -07:00

..

allocpercpu.c

…

backing-dev.c

…

bootmem.c

…

bounce.c

…

dmapool.c

…

fadvise.c

…

filemap_xip.c

…

filemap.c

…

fremap.c

…

highmem.c

…

hugetlb.c

…

internal.h

…

Kconfig

…

maccess.c

…

madvise.c

…

Makefile

…

memcontrol.c

…

memory_hotplug.c

…

memory.c

…

mempolicy.c

…

mempool.c

…

migrate.c

…

mincore.c

…

mlock.c

…

mm_init.c

…

mmap.c

…

mmu_notifier.c

…

mmzone.c

…

mprotect.c

…

mremap.c

…

msync.c

…

nommu.c

…

oom_kill.c

…

page_alloc.c

…

page_io.c

…

page_isolation.c

…

page-writeback.c

…

pagewalk.c

…

pdflush.c

…

prio_tree.c

…

quicklist.c

…

readahead.c

…

rmap.c

anon_vma_prepare: properly lock even newly allocated entries

2008-10-19 11:50:35 -07:00

shmem_acl.c

…

shmem.c

Export shmem_file_setup for DRM-GEM

2008-10-18 07:10:11 +10:00

slab.c

…

slob.c

…

slub.c

…

sparse-vmemmap.c

…

sparse.c

…

swap_state.c

…

swap.c

…

swapfile.c

…

thrash.c

…

tiny-shmem.c

…

truncate.c

…

util.c

…

vmalloc.c

…

vmscan.c

…

vmstat.c

…