Merge branch 'akpm' (patches from Andrew)

  VmLib:      1412 kB

  VmPTE:        20 kb

  VmSwap:        0 kB

  HugetlbPages:          0 kB

  Threads:        1

  SigQ:   0/28578

  SigPnd: 0000000000000000

 VmPTE                       size of page table entries

 VmPMD                       size of second level page tables

 VmSwap                      size of swap usage (the number of referred swapents)

 HugetlbPages                size of hugetlb memory portions

 Threads                     number of threads

 SigQ                        number of signals queued/max. number for queue

 SigPnd                      bitmap of pending signals for the thread

Private_Dirty:         0 kB

Referenced:          892 kB

Anonymous:             0 kB

AnonHugePages:         0 kB

Shared_Hugetlb:        0 kB

Private_Hugetlb:       0 kB

Swap:                  0 kB

SwapPss:               0 kB

KernelPageSize:        4 kB

MMUPageSize:           4 kB

Locked:              374 kB

VmFlags: rd ex mr mw me de

Locked:                0 kB

VmFlags: rd ex mr mw me dw

the first of these lines shows the same information as is displayed for the

mapping in /proc/PID/maps.  The remaining lines show the size of the mapping

"Anonymous" shows the amount of memory that does not belong to any file.  Even

a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE

and a page is modified, the file page is replaced by a private anonymous copy.

"Swap" shows how much would-be-anonymous memory is also used, but out on

swap.

"AnonHugePages" shows the ammount of memory backed by transparent hugepage.

"Shared_Hugetlb" and "Private_Hugetlb" show the ammounts of memory backed by

hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical

reasons. And these are not included in {Shared,Private}_{Clean,Dirty} field.

"Swap" shows how much would-be-anonymous memory is also used, but out on swap.

"SwapPss" shows proportional swap share of this mapping.

"Locked" indicates whether the mapping is locked in memory or not.

"VmFlags" field deserves a separate description. This member represents the kernel

flags associated with the particular virtual memory area in two letter encoded

manner. The codes are the following:

    ac  - area is accountable

    nr  - swap space is not reserved for the area

    ht  - area uses huge tlb pages

    nl  - non-linear mapping

    ar  - architecture specific flag

    dd  - do not include area into core dump

    sd  - soft-dirty flag

> cat /proc/meminfo

The "Locked" indicates whether the mapping is locked in memory or not.

MemTotal:     16344972 kB

MemFree:      13634064 kB

MemAvailable: 14836172 kB

Kernel address sanitizer

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

KernelAddressSanitizer (KASAN)

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

0. Overview

===========

Kernel Address sanitizer (KASan) is a dynamic memory error detector. It provides

KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It provides

a fast and comprehensive solution for finding use-after-free and out-of-bounds

bugs.

KASan uses compile-time instrumentation for checking every memory access,

therefore you will need a gcc version of 4.9.2 or later. KASan could detect out

of bounds accesses to stack or global variables, but only if gcc 5.0 or later was

used to built the kernel.

KASAN uses compile-time instrumentation for checking every memory access,

therefore you will need a GCC version 4.9.2 or later. GCC 5.0 or later is

required for detection of out-of-bounds accesses to stack or global variables.

Currently KASan is supported only for x86_64 architecture and requires that the

kernel be built with the SLUB allocator.

Currently KASAN is supported only for x86_64 architecture and requires the

kernel to be built with the SLUB allocator.

1. Usage

=========

========

To enable KASAN configure kernel with:

	  CONFIG_KASAN = y

and choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. Outline/inline

is compiler instrumentation types. The former produces smaller binary the

latter is 1.1 - 2 times faster. Inline instrumentation requires a gcc version

of 5.0 or later.

and choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. Outline and

inline are compiler instrumentation types. The former produces smaller binary

the latter is 1.1 - 2 times faster. Inline instrumentation requires a GCC

version 5.0 or later.

Currently KASAN works only with the SLUB memory allocator.

For better bug detection and nicer report, enable CONFIG_STACKTRACE and put

at least 'slub_debug=U' in the boot cmdline.

For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.

To disable instrumentation for specific files or directories, add a line

similar to the following to the respective kernel Makefile:

                KASAN_SANITIZE := n

1.1 Error reports

==========

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

A typical out of bounds access report looks like this:

 ffff8800693bc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

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

First sections describe slub object where bad access happened.

See 'SLUB Debug output' section in Documentation/vm/slub.txt for details.

The header of the report discribe what kind of bug happened and what kind of

access caused it. It's followed by the description of the accessed slub object

(see 'SLUB Debug output' section in Documentation/vm/slub.txt for details) and

the description of the accessed memory page.

In the last section the report shows memory state around the accessed address.

Reading this part requires some more understanding of how KASAN works.

Reading this part requires some understanding of how KASAN works.

Each 8 bytes of memory are encoded in one shadow byte as accessible,

partially accessible, freed or they can be part of a redzone.

The state of each 8 aligned bytes of memory is encoded in one shadow byte.

Those 8 bytes can be accessible, partially accessible, freed or be a redzone.

We use the following encoding for each shadow byte: 0 means that all 8 bytes

of the corresponding memory region are accessible; number N (1 <= N <= 7) means

that the first N bytes are accessible, and other (8 - N) bytes are not;

2. Implementation details

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

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

From a high level, our approach to memory error detection is similar to that

of kmemcheck: use shadow memory to record whether each byte of memory is safe

			Format: <unsigned int> such that (rxsize & ~0x1fffc0) == 0.

			Default: 1024

	hardlockup_all_cpu_backtrace=

			[KNL] Should the hard-lockup detector generate

			backtraces on all cpus.

			Format: <integer>

	hashdist=	[KNL,NUMA] Large hashes allocated during boot

			are distributed across NUMA nodes.  Defaults on

			for 64-bit NUMA, off otherwise.

details), without letting other interrupts have a chance to run.

Similarly to the softlockup case, the current stack trace is displayed

upon detection and the system will stay locked up unless the default

behavior is changed, which can be done through a compile time knob,

"BOOTPARAM_HARDLOCKUP_PANIC", and a kernel parameter, "nmi_watchdog"

behavior is changed, which can be done through a sysctl,

'hardlockup_panic', a compile time knob, "BOOTPARAM_HARDLOCKUP_PANIC",

and a kernel parameter, "nmi_watchdog"

(see "Documentation/kernel-parameters.txt" for details).

The panic option can be used in combination with panic_timeout (this

- domainname

- hostname

- hotplug

- hardlockup_all_cpu_backtrace

- hung_task_panic

- hung_task_check_count

- hung_task_timeout_secs

domain names are in general different. For a detailed discussion

see the hostname(1) man page.

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

hardlockup_all_cpu_backtrace:

This value controls the hard lockup detector behavior when a hard

lockup condition is detected as to whether or not to gather further

debug information. If enabled, arch-specific all-CPU stack dumping

will be initiated.

0: do nothing. This is the default behavior.

1: on detection capture more debug information.

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

hotplug: