Merge branch 'akpm' (aka "Andrew's patch-bomb")

What:           Attribute for calibrating ST-Ericsson AB8500 Real Time Clock

Date:           Oct 2011

KernelVersion:  3.0

Contact:        Mark Godfrey <mark.godfrey@stericsson.com>

Description:    The rtc_calibration attribute allows the userspace to

                calibrate the AB8500.s 32KHz Real Time Clock.

                Every 60 seconds the AB8500 will correct the RTC's value

                by adding to it the value of this attribute.

                The range of the attribute is -127 to +127 in units of

                30.5 micro-seconds (half-parts-per-million of the 32KHz clock)

Users:          The /vendor/st-ericsson/base_utilities/core/rtc_calibration

                daemon uses this interface.

* TI twl RTC

The TWL family (twl4030/6030) contains a RTC.

Required properties:

- compatible : Should be twl4030-rtc

Examples:

rtc@0 {

    compatible = "ti,twl4030-rtc";

};

  3.5	/proc/<pid>/mountinfo - Information about mounts

  3.6	/proc/<pid>/comm  & /proc/<pid>/task/<tid>/comm

  4	Configuring procfs

  4.1	Mount options

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

Preface

is limited in size compared to the cmdline value, so writing anything longer

then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated

comm value.

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

Configuring procfs

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

4.1	Mount options

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

The following mount options are supported:

	hidepid=	Set /proc/<pid>/ access mode.

	gid=		Set the group authorized to learn processes information.

hidepid=0 means classic mode - everybody may access all /proc/<pid>/ directories

(default).

hidepid=1 means users may not access any /proc/<pid>/ directories but their

own.  Sensitive files like cmdline, sched*, status are now protected against

other users.  This makes it impossible to learn whether any user runs

specific program (given the program doesn't reveal itself by its behaviour).

As an additional bonus, as /proc/<pid>/cmdline is unaccessible for other users,

poorly written programs passing sensitive information via program arguments are

now protected against local eavesdroppers.

hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other

users.  It doesn't mean that it hides a fact whether a process with a specific

pid value exists (it can be learned by other means, e.g. by "kill -0 $PID"),

but it hides process' uid and gid, which may be learned by stat()'ing

/proc/<pid>/ otherwise.  It greatly complicates an intruder's task of gathering

information about running processes, whether some daemon runs with elevated

privileges, whether other user runs some sensitive program, whether other users

run any program at all, etc.

gid= defines a group authorized to learn processes information otherwise

prohibited by hidepid=.  If you use some daemon like identd which needs to learn

information about processes information, just add identd to this group.

	no_debug_objects

			[KNL] Disable object debugging

	debug_guardpage_minorder=

			[KNL] When CONFIG_DEBUG_PAGEALLOC is set, this

			parameter allows control of the order of pages that will

			be intentionally kept free (and hence protected) by the

			buddy allocator. Bigger value increase the probability

			of catching random memory corruption, but reduce the

			amount of memory for normal system use. The maximum

			possible value is MAX_ORDER/2.  Setting this parameter

			to 1 or 2 should be enough to identify most random

			memory corruption problems caused by bugs in kernel or

			driver code when a CPU writes to (or reads from) a

			random memory location. Note that there exists a class

			of memory corruptions problems caused by buggy H/W or

			F/W or by drivers badly programing DMA (basically when

			memory is written at bus level and the CPU MMU is

			bypassed) which are not detectable by

			CONFIG_DEBUG_PAGEALLOC, hence this option will not help

			tracking down these problems.

	debugpat	[X86] Enable PAT debugging

	decnet.addr=	[HW,NET]

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

mm_page_alloc		  page=%p pfn=%lu order=%d migratetype=%d gfp_flags=%s

mm_page_alloc_zone_locked page=%p pfn=%lu order=%u migratetype=%d cpu=%d percpu_refill=%d

mm_page_free_direct	  page=%p pfn=%lu order=%d

mm_pagevec_free		  page=%p pfn=%lu order=%d cold=%d

mm_page_free		  page=%p pfn=%lu order=%d

mm_page_free_batched	  page=%p pfn=%lu order=%d cold=%d

These four events deal with page allocation and freeing. mm_page_alloc is

a simple indicator of page allocator activity. Pages may be allocated from

impairs performance by disabling interrupts, dirtying cache lines between

CPUs and serialising many CPUs.

When a page is freed directly by the caller, the mm_page_free_direct event

When a page is freed directly by the caller, the only mm_page_free event

is triggered. Significant amounts of activity here could indicate that the

callers should be batching their activities.

When pages are freed using a pagevec, the mm_pagevec_free is

triggered. Broadly speaking, pages are taken off the LRU lock in bulk and

freed in batch with a pagevec. Significant amounts of activity here could

When pages are freed in batch, the also mm_page_free_batched is triggered.

Broadly speaking, pages are taken off the LRU lock in bulk and

freed in batch with a page list. Significant amounts of activity here could

indicate that the system is under memory pressure and can also indicate

contention on the zone->lru_lock.