Merge branch 'origin'

D: Fixed the shm swap deallocation at swapoff time (try_to_unuse message)

D: VM hacker

D: Various other kernel hacks

S: Via Cicalini 26

S: Imola 40026

S: Italy

S: Australia

N: Stephen Smalley

E: sds@epoch.ncsc.mil

E: sds@tycho.nsa.gov

D: portions of the Linux Security Module (LSM) framework and security modules

N: Chris Smith

S: England

N: Chris Wright

E: chrisw@osdl.org

E: chrisw@sous-sol.org

D: hacking on LSM framework and security modules.

S: c/o OSDL

S: 12725 SW Millikan Way, Suite 400

S: Beaverton, OR 97005

S: Portland, OR

S: USA

N: Michal Wronski

following year [McKenney02a], and use of RCU in dcache was first

described that same year [Linder02a].

Also in 2002, Michael [Michael02b,Michael02a] presented techniques

that defer the destruction of data structures to simplify non-blocking

synchronization (wait-free synchronization, lock-free synchronization,

and obstruction-free synchronization are all examples of non-blocking

synchronization).  In particular, this technique eliminates locking,

reduces contention, reduces memory latency for readers, and parallelizes

pipeline stalls and memory latency for writers.  However, these

techniques still impose significant read-side overhead in the form of

memory barriers.  Researchers at Sun worked along similar lines in the

same timeframe [HerlihyLM02,HerlihyLMS03].

Also in 2002, Michael [Michael02b,Michael02a] presented "hazard-pointer"

techniques that defer the destruction of data structures to simplify

non-blocking synchronization (wait-free synchronization, lock-free

synchronization, and obstruction-free synchronization are all examples of

non-blocking synchronization).  In particular, this technique eliminates

locking, reduces contention, reduces memory latency for readers, and

parallelizes pipeline stalls and memory latency for writers.  However,

these techniques still impose significant read-side overhead in the

form of memory barriers.  Researchers at Sun worked along similar lines

in the same timeframe [HerlihyLM02,HerlihyLMS03].  These techniques

can be thought of as inside-out reference counts, where the count is

represented by the number of hazard pointers referencing a given data

structure (rather than the more conventional counter field within the

data structure itself).

In 2003, the K42 group described how RCU could be used to create

hot-pluggable implementations of operating-system functions.  Later that

describing how to make RCU safe for soft-realtime applications [Sarma04c],

and a paper describing SELinux performance with RCU [JamesMorris04b].

2005 has seen further adaptation of RCU to realtime use, permitting

preemption of RCU realtime critical sections [PaulMcKenney05a,

PaulMcKenney05b].

	If you want to wait for some of these other things, you might

	instead need to use synchronize_irq() or synchronize_sched().

12.	Any lock acquired by an RCU callback must be acquired elsewhere

	with irq disabled, e.g., via spin_lock_irqsave().  Failing to

	disable irq on a given acquisition of that lock will result in

	deadlock as soon as the RCU callback happens to interrupt that

	acquisition's critical section.

	{

		struct audit_entry  *e;

		/* Do not use the _rcu iterator here, since this is the only

		 * deletion routine. */

		/* Do not need to use the _rcu iterator here, since this

		 * is the only deletion routine. */

		list_for_each_entry(e, list, list) {

			if (!audit_compare_rule(rule, &e->rule)) {

				spin_lock(&e->lock);

Answer to Quick Quiz

If the search function drops the per-entry lock before returning, then

the caller will be processing stale data in any case.  If it is really

OK to be processing stale data, then you don't need a "deleted" flag.

If processing stale data really is a problem, then you need to hold the

per-entry lock across all of the code that uses the value looked up.

	Why does the search function need to return holding the per-entry

	lock for this deleted-flag technique to be helpful?

	If the search function drops the per-entry lock before returning,

	then the caller will be processing stale data in any case.  If it

	is really OK to be processing stale data, then you don't need a

	"deleted" flag.  If processing stale data really is a problem,

	then you need to hold the per-entry lock across all of the code

	that uses the value that was returned.

		You are reading it!

	rcuref.txt

		Describes how to combine use of reference counts

		with RCU.

	whatisRCU.txt

		Overview of how the RCU implementation works.  Along