Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

			lsm:	[[subj_user=] [subj_role=] [subj_type=]

				 [obj_user=] [obj_role=] [obj_type=]]

		base: 	func:= [BPRM_CHECK][FILE_MMAP][INODE_PERMISSION]

		base: 	func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK]

			mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]

			fsmagic:= hex value

			uid:= decimal value

			measure func=BPRM_CHECK

			measure func=FILE_MMAP mask=MAY_EXEC

			measure func=INODE_PERM mask=MAY_READ uid=0

			measure func=FILE_CHECK mask=MAY_READ uid=0

		The default policy measures all executables in bprm_check,

		all files mmapped executable in file_mmap, and all files

		open for read by root in inode_permission.

		open for read by root in do_filp_open.

		Examples of LSM specific definitions:

			dont_measure obj_type=var_log_t

			dont_measure obj_type=auditd_log_t

			measure subj_user=system_u func=INODE_PERM mask=MAY_READ

			measure subj_role=system_r func=INODE_PERM mask=MAY_READ

			measure subj_user=system_u func=FILE_CHECK mask=MAY_READ

			measure subj_role=system_r func=FILE_CHECK mask=MAY_READ

		Smack:

			measure subj_user=_ func=INODE_PERM mask=MAY_READ

			measure subj_user=_ func=FILE_CHECK mask=MAY_READ

up_threshold: defines what the average CPU usage between the samplings

of 'sampling_rate' needs to be for the kernel to make a decision on

whether it should increase the frequency.  For example when it is set

to its default value of '80' it means that between the checking

intervals the CPU needs to be on average more than 80% in use to then

to its default value of '95' it means that between the checking

intervals the CPU needs to be on average more than 95% in use to then

decide that the CPU frequency needs to be increased.  

ignore_nice_load: this parameter takes a value of '0' or '1'. When

  failslab, fail_page_alloc, and fail_make_request use this way.

  Helper functions:

	init_fault_attr_entries(entries, attr, name);

	void cleanup_fault_attr_entries(entries);

	init_fault_attr_dentries(entries, attr, name);

	void cleanup_fault_attr_dentries(entries);

- module parameters

A set of ABS_MT events with the desired properties is defined. The events

are divided into categories, to allow for partial implementation.  The

minimum set consists of ABS_MT_TOUCH_MAJOR, ABS_MT_POSITION_X and

ABS_MT_POSITION_Y, which allows for multiple fingers to be tracked.  If the

device supports it, the ABS_MT_WIDTH_MAJOR may be used to provide the size

of the approaching finger. Anisotropy and direction may be specified with

ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION.  The

ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a

minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which

allows for multiple fingers to be tracked.  If the device supports it, the

ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size

of the contact area and approaching finger, respectively.

The TOUCH and WIDTH parameters have a geometrical interpretation; imagine

looking through a window at someone gently holding a finger against the

glass.  You will see two regions, one inner region consisting of the part

of the finger actually touching the glass, and one outer region formed by

the perimeter of the finger. The diameter of the inner region is the

ABS_MT_TOUCH_MAJOR, the diameter of the outer region is

ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder

against the glass. The inner region will increase, and in general, the

ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than

unity, is related to the finger pressure. For pressure-based devices,

ABS_MT_PRESSURE may be used to provide the pressure on the contact area

instead.

In addition to the MAJOR parameters, the oval shape of the finger can be

described by adding the MINOR parameters, such that MAJOR and MINOR are the

major and minor axis of an ellipse. Finally, the orientation of the oval

shape can be describe with the ORIENTATION parameter.

The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a

finger or a pen or something else.  Devices with more granular information

may specify general shapes as blobs, i.e., as a sequence of rectangular

shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices

Here is what a minimal event sequence for a two-finger touch would look

like:

   ABS_MT_TOUCH_MAJOR

   ABS_MT_POSITION_X

   ABS_MT_POSITION_Y

   SYN_MT_REPORT

   ABS_MT_TOUCH_MAJOR

   ABS_MT_POSITION_X

   ABS_MT_POSITION_Y

   SYN_MT_REPORT

the notion of pressure. The fingers of the hand and the palm all have

different characteristic widths [1].

ABS_MT_PRESSURE

The pressure, in arbitrary units, on the contact area. May be used instead

of TOUCH and WIDTH for pressure-based devices or any device with a spatial

signal intensity distribution.

ABS_MT_ORIENTATION

The orientation of the ellipse. The value should describe a signed quarter

make use of these native identifiers to reduce bandwidth and cpu usage.

Gestures

--------

In the specific application of creating gesture events, the TOUCH and WIDTH

parameters can be used to, e.g., approximate finger pressure or distinguish

between index finger and thumb. With the addition of the MINOR parameters,

one can also distinguish between a sweeping finger and a pointing finger,

and with ORIENTATION, one can detect twisting of fingers.

Notes

-----

		function tracer guts

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

		By Mike Frysinger

Introduction

------------

	unsigned long *frompc = &...;

	unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE;

	prepare_ftrace_return(frompc, selfpc);

	/* passing frame pointer up is optional -- see below */

	prepare_ftrace_return(frompc, selfpc, frame_pointer);

	/* restore all state needed by the ABI */

}

#endif

For information on how to implement prepare_ftrace_return(), simply look at

the x86 version.  The only architecture-specific piece in it is the setup of

For information on how to implement prepare_ftrace_return(), simply look at the

x86 version (the frame pointer passing is optional; see the next section for

more information).  The only architecture-specific piece in it is the setup of

the fault recovery table (the asm(...) code).  The rest should be the same

across architectures.

#endif

HAVE_FUNCTION_GRAPH_FP_TEST

---------------------------

An arch may pass in a unique value (frame pointer) to both the entering and

exiting of a function.  On exit, the value is compared and if it does not

match, then it will panic the kernel.  This is largely a sanity check for bad

code generation with gcc.  If gcc for your port sanely updates the frame

pointer under different opitmization levels, then ignore this option.

However, adding support for it isn't terribly difficult.  In your assembly code

that calls prepare_ftrace_return(), pass the frame pointer as the 3rd argument.

Then in the C version of that function, do what the x86 port does and pass it

along to ftrace_push_return_trace() instead of a stub value of 0.

Similarly, when you call ftrace_return_to_handler(), pass it the frame pointer.

HAVE_FTRACE_NMI_ENTER

---------------------