Message-Id: <20080126035449.006768254@sgi.com>
User-Agent: quilt/0.46-1
Date: Fri, 25 Jan 2008 19:54:49 -0800
From: Christoph Lameter <clameter@sgi.com>
To: scaling@ils.sgi.com
Subject-Prefix: [patch @num@/@total@]
Subject: [RFC] MMU Notifiers V2 (internal)

[Internal release to figure out how to proceed with the remaining locking issues]

- Locking is still not consistent for invalidate_range. Invalidate_
  range is called in contexts where mmap_sem is not held but should
  be held according to docs.

- In some context we could fallback to individual invalidate_page() calls
  if mmap_sem is not held? F.e. when truncating a file? The imap_lock is still
  held.

- filemap_xip.c: Do not know how relevant it is. No pagelock is taken.

- How important is the ordering of invalidate_range vs. the unmapping
  of ptes? Should not be a problem if mmap_sem is held?

This is a patchset implementing MMU notifier callbacks based on Andrea's
earlier work. These are needed if Linux pages are referenced from something
else than tracked by the rmaps of the kernel.

Andrea's mmu_notifier #4 -> RFC V1

- Merge subsystem rmap based with Linux rmap based approach
- Move Linux rmap based notifiers out of macro
- Try to account for what locks are held while the notifiers are
  called.
- Develop a patch sequence that separates out the different types of
  hooks so that we can review their use.
- Avoid adding include to linux/mm_types.h
- Integrate RCU logic suggested by Peter.

V1->V2:
- Improve RCU support
- Use mmap_sem for mmu_notifier register / unregister
- Drop invalidate_page from COW, mm/fremap.c and mm/rmap.c since we
  already have invalidate_range() callbacks there.
- Clean compile for !MMU_NOTIFIER
- Isolate filemap_xip strangeness into its own diff
- Pass a the flag to invalidate_range to indicate if a spinlock
  is held.

--