Merge branch 'akpm' (patches from Andrew)

		The backing_dev file is read-write and set up backing

		device for zram to write incompressible pages.

		For using, user should enable CONFIG_ZRAM_WRITEBACK.

What:		/sys/block/zram<id>/idle

Date:		November 2018

Contact:	Minchan Kim <minchan@kernel.org>

Description:

		idle file is write-only and mark zram slot as idle.

		If system has mounted debugfs, user can see which slots

		are idle via /sys/kernel/debug/zram/zram<id>/block_state

What:		/sys/block/zram<id>/writeback

Date:		November 2018

Contact:	Minchan Kim <minchan@kernel.org>

Description:

		The writeback file is write-only and trigger idle and/or

		huge page writeback to backing device.

What:		/sys/block/zram<id>/bd_stat

Date:		November 2018

Contact:	Minchan Kim <minchan@kernel.org>

Description:

		The bd_stat file is read-only and represents backing device's

		statistics (bd_count, bd_reads, bd_writes) in a format

		similar to block layer statistics file format.

What:		/sys/block/zram<id>/writeback_limit

Date:		November 2018

Contact:	Minchan Kim <minchan@kernel.org>

Description:

		The writeback_limit file is read-write and specifies the maximum

		amount of writeback ZRAM can do. The limit could be changed

		in run time and "0" means disable the limit.

		No limit is the initial state.

mem_used_max      WO    reset the `mem_used_max' counter (see later)

mem_limit         WO    specifies the maximum amount of memory ZRAM can use

                        to store the compressed data

writeback_limit   WO    specifies the maximum amount of write IO zram can

			write out to backing device as 4KB unit

max_comp_streams  RW    the number of possible concurrent compress operations

comp_algorithm    RW    show and change the compression algorithm

compact           WO    trigger memory compaction

debug_stat        RO    this file is used for zram debugging purposes

backing_dev	  RW	set up backend storage for zram to write out

idle		  WO	mark allocated slot as idle

User space is advised to use the following files to read the device statistics.

 pages_compacted  the number of pages freed during compaction

 huge_pages	  the number of incompressible pages

File /sys/block/zram<id>/bd_stat

The stat file represents device's backing device statistics. It consists of

a single line of text and contains the following stats separated by whitespace:

 bd_count	size of data written in backing device.

		Unit: 4K bytes

 bd_reads	the number of reads from backing device

		Unit: 4K bytes

 bd_writes	the number of writes to backing device

		Unit: 4K bytes

9) Deactivate:

	swapoff /dev/zram0

	umount /dev/zram1

= writeback

With incompressible pages, there is no memory saving with zram.

Instead, with CONFIG_ZRAM_WRITEBACK, zram can write incompressible page

With CONFIG_ZRAM_WRITEBACK, zram can write idle/incompressible page

to backing storage rather than keeping it in memory.

User should set up backing device via /sys/block/zramX/backing_dev

before disksize setting.

To use the feature, admin should set up backing device via

	"echo /dev/sda5 > /sys/block/zramX/backing_dev"

before disksize setting. It supports only partition at this moment.

If admin want to use incompressible page writeback, they could do via

	"echo huge > /sys/block/zramX/write"

To use idle page writeback, first, user need to declare zram pages

as idle.

	"echo all > /sys/block/zramX/idle"

From now on, any pages on zram are idle pages. The idle mark

will be removed until someone request access of the block.

IOW, unless there is access request, those pages are still idle pages.

Admin can request writeback of those idle pages at right timing via

	"echo idle > /sys/block/zramX/writeback"

With the command, zram writeback idle pages from memory to the storage.

If there are lots of write IO with flash device, potentially, it has

flash wearout problem so that admin needs to design write limitation

to guarantee storage health for entire product life.

To overcome the concern, zram supports "writeback_limit".

The "writeback_limit"'s default value is 0 so that it doesn't limit

any writeback. If admin want to measure writeback count in a certain

period, he could know it via /sys/block/zram0/bd_stat's 3rd column.

If admin want to limit writeback as per-day 400M, he could do it

like below.

    MB_SHIFT=20

    4K_SHIFT=12

    echo $((400<<MB_SHIFT>>4K_SHIFT)) > \

	    /sys/block/zram0/writeback_limit.

If admin want to allow further write again, he could do it like below

    echo 0 > /sys/block/zram0/writeback_limit

If admin want to see remaining writeback budget since he set,

    cat /sys/block/zram0/writeback_limit

The writeback_limit count will reset whenever you reset zram(e.g.,

system reboot, echo 1 > /sys/block/zramX/reset) so keeping how many of

writeback happened until you reset the zram to allocate extra writeback

budget in next setting is user's job.

= memory tracking

If you enable the feature, you could see block state via

/sys/kernel/debug/zram/zram0/block_state". The output is as follows,

	  300    75.033841 .wh

	  301    63.806904 s..

	  302    63.806919 ..h

	  300    75.033841 .wh.

	  301    63.806904 s...

	  302    63.806919 ..hi

First column is zram's block index.

Second column is access time since the system was booted

Third column is state of the block.

(s: same page

w: written page to backing store

h: huge page)

h: huge page

i: idle page)

First line of above example says 300th block is accessed at 75.033841sec

and the block's state is huge so it is written back to the backing

Overview

--------

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.

KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to

find out-of-bound and use-after-free bugs. KASAN has two modes: generic KASAN

(similar to userspace ASan) and software tag-based KASAN (similar to userspace

HWASan).

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.

KASAN uses compile-time instrumentation to insert validity checks before every

memory access, and therefore requires a compiler version that supports that.

Currently KASAN is supported only for the x86_64 and arm64 architectures.

Generic KASAN is supported in both GCC and Clang. With GCC it requires version

4.9.2 or later for basic support and version 5.0 or later for detection of

out-of-bounds accesses for stack and global variables and for inline

instrumentation mode (see the Usage section). With Clang it requires version

7.0.0 or later and it doesn't support detection of out-of-bounds accesses for

global variables yet.

Tag-based KASAN is only supported in Clang and requires version 7.0.0 or later.

Currently generic KASAN is supported for the x86_64, arm64, xtensa and s390

architectures, and tag-based KASAN is supported only for arm64.

Usage

-----

	  CONFIG_KASAN = y

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.

and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN) and

CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN).

You also need to choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE.

Outline and inline are compiler instrumentation types. The former produces

smaller binary while the latter is 1.1 - 2 times faster.

KASAN works with both SLUB and SLAB memory allocators.

Both KASAN modes work with both SLUB and SLAB memory allocators.

For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.

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

Error reports

~~~~~~~~~~~~~

A typical out of bounds access report looks like this::

A typical out-of-bounds access generic KASAN report looks like this::

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

    BUG: AddressSanitizer: out of bounds access in kmalloc_oob_right+0x65/0x75 [test_kasan] at addr ffff8800693bc5d3

    Write of size 1 by task modprobe/1689

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

    BUG kmalloc-128 (Not tainted): kasan error

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

    Disabling lock debugging due to kernel taint

    INFO: Allocated in kmalloc_oob_right+0x3d/0x75 [test_kasan] age=0 cpu=0 pid=1689

     __slab_alloc+0x4b4/0x4f0

     kmem_cache_alloc_trace+0x10b/0x190

     kmalloc_oob_right+0x3d/0x75 [test_kasan]

     init_module+0x9/0x47 [test_kasan]

     do_one_initcall+0x99/0x200

     load_module+0x2cb3/0x3b20

     SyS_finit_module+0x76/0x80

     system_call_fastpath+0x12/0x17

    INFO: Slab 0xffffea0001a4ef00 objects=17 used=7 fp=0xffff8800693bd728 flags=0x100000000004080

    INFO: Object 0xffff8800693bc558 @offset=1368 fp=0xffff8800693bc720

    Bytes b4 ffff8800693bc548: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  ........ZZZZZZZZ

    Object ffff8800693bc558: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc568: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc5a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc5b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc5c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  kkkkkkkkkkkkkkk.

    Redzone ffff8800693bc5d8: cc cc cc cc cc cc cc cc                          ........

    Padding ffff8800693bc718: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ

    CPU: 0 PID: 1689 Comm: modprobe Tainted: G    B          3.18.0-rc1-mm1+ #98

    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014

     ffff8800693bc000 0000000000000000 ffff8800693bc558 ffff88006923bb78

     ffffffff81cc68ae 00000000000000f3 ffff88006d407600 ffff88006923bba8

     ffffffff811fd848 ffff88006d407600 ffffea0001a4ef00 ffff8800693bc558

    BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan]

    Write of size 1 at addr ffff8801f44ec37b by task insmod/2760

    CPU: 1 PID: 2760 Comm: insmod Not tainted 4.19.0-rc3+ #698

    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014

    Call Trace:

     [<ffffffff81cc68ae>] dump_stack+0x46/0x58

     [<ffffffff811fd848>] print_trailer+0xf8/0x160

     [<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan]

     [<ffffffff811ff0f5>] object_err+0x35/0x40

     [<ffffffffa0002065>] ? kmalloc_oob_right+0x65/0x75 [test_kasan]

     [<ffffffff8120b9fa>] kasan_report_error+0x38a/0x3f0

     [<ffffffff8120a79f>] ? kasan_poison_shadow+0x2f/0x40

     [<ffffffff8120b344>] ? kasan_unpoison_shadow+0x14/0x40

     [<ffffffff8120a79f>] ? kasan_poison_shadow+0x2f/0x40

     [<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan]

     [<ffffffff8120a995>] __asan_store1+0x75/0xb0

     [<ffffffffa0002601>] ? kmem_cache_oob+0x1d/0xc3 [test_kasan]

     [<ffffffffa0002065>] ? kmalloc_oob_right+0x65/0x75 [test_kasan]

     [<ffffffffa0002065>] kmalloc_oob_right+0x65/0x75 [test_kasan]

     [<ffffffffa00026b0>] init_module+0x9/0x47 [test_kasan]

     [<ffffffff810002d9>] do_one_initcall+0x99/0x200

     [<ffffffff811e4e5c>] ? __vunmap+0xec/0x160

     [<ffffffff81114f63>] load_module+0x2cb3/0x3b20

     [<ffffffff8110fd70>] ? m_show+0x240/0x240

     [<ffffffff81115f06>] SyS_finit_module+0x76/0x80

     [<ffffffff81cd3129>] system_call_fastpath+0x12/0x17

     dump_stack+0x94/0xd8

     print_address_description+0x73/0x280

     kasan_report+0x144/0x187

     __asan_report_store1_noabort+0x17/0x20

     kmalloc_oob_right+0xa8/0xbc [test_kasan]

     kmalloc_tests_init+0x16/0x700 [test_kasan]

     do_one_initcall+0xa5/0x3ae

     do_init_module+0x1b6/0x547

     load_module+0x75df/0x8070

     __do_sys_init_module+0x1c6/0x200

     __x64_sys_init_module+0x6e/0xb0

     do_syscall_64+0x9f/0x2c0

     entry_SYSCALL_64_after_hwframe+0x44/0xa9

    RIP: 0033:0x7f96443109da

    RSP: 002b:00007ffcf0b51b08 EFLAGS: 00000202 ORIG_RAX: 00000000000000af

    RAX: ffffffffffffffda RBX: 000055dc3ee521a0 RCX: 00007f96443109da

    RDX: 00007f96445cff88 RSI: 0000000000057a50 RDI: 00007f9644992000

    RBP: 000055dc3ee510b0 R08: 0000000000000003 R09: 0000000000000000

    R10: 00007f964430cd0a R11: 0000000000000202 R12: 00007f96445cff88

    R13: 000055dc3ee51090 R14: 0000000000000000 R15: 0000000000000000

    Allocated by task 2760:

     save_stack+0x43/0xd0

     kasan_kmalloc+0xa7/0xd0

     kmem_cache_alloc_trace+0xe1/0x1b0

     kmalloc_oob_right+0x56/0xbc [test_kasan]

     kmalloc_tests_init+0x16/0x700 [test_kasan]

     do_one_initcall+0xa5/0x3ae

     do_init_module+0x1b6/0x547

     load_module+0x75df/0x8070

     __do_sys_init_module+0x1c6/0x200

     __x64_sys_init_module+0x6e/0xb0

     do_syscall_64+0x9f/0x2c0

     entry_SYSCALL_64_after_hwframe+0x44/0xa9

    Freed by task 815:

     save_stack+0x43/0xd0

     __kasan_slab_free+0x135/0x190

     kasan_slab_free+0xe/0x10

     kfree+0x93/0x1a0

     umh_complete+0x6a/0xa0

     call_usermodehelper_exec_async+0x4c3/0x640

     ret_from_fork+0x35/0x40

    The buggy address belongs to the object at ffff8801f44ec300

     which belongs to the cache kmalloc-128 of size 128

    The buggy address is located 123 bytes inside of

     128-byte region [ffff8801f44ec300, ffff8801f44ec380)

    The buggy address belongs to the page:

    page:ffffea0007d13b00 count:1 mapcount:0 mapping:ffff8801f7001640 index:0x0

    flags: 0x200000000000100(slab)

    raw: 0200000000000100 ffffea0007d11dc0 0000001a0000001a ffff8801f7001640

    raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000

    page dumped because: kasan: bad access detected

    Memory state around the buggy address:

     ffff8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

     ffff8800693bc380: fc fc 00 00 00 00 00 00 00 00 00 00 00 00 00 fc

     ffff8800693bc400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

     ffff8800693bc480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

     ffff8800693bc500: fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00

    >ffff8800693bc580: 00 00 00 00 00 00 00 00 00 00 03 fc fc fc fc fc

     ffff8801f44ec200: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb

     ffff8801f44ec280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc

    >ffff8801f44ec300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03

                                                                    ^

     ffff8800693bc600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

     ffff8800693bc680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

     ffff8800693bc700: fc fc fc fc fb fb fb fb fb fb fb fb fb fb fb fb

     ffff8800693bc780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

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

     ffff8801f44ec380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb

     ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc

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

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.rst for details) and

the description of the accessed memory page.

The header of the report provides a short summary of what kind of bug happened

and what kind of access caused it. It's followed by a stack trace of the bad

access, a stack trace of where the accessed memory was allocated (in case bad

access happens on a slab object), and a stack trace of where the object was

freed (in case of a use-after-free bug report). Next comes a description of

the accessed slab object and information about the accessed memory page.

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

Reading this part requires some understanding of how KASAN works.

In the report above the arrows point to the shadow byte 03, which means that

the accessed address is partially accessible.

For tag-based KASAN this last report section shows the memory tags around the

accessed address (see Implementation details section).

Implementation details

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

Generic KASAN

~~~~~~~~~~~~~

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

to access, and use compile-time instrumentation to check shadow memory on each

memory access.

to access, and use compile-time instrumentation to insert checks of shadow

memory on each memory access.

AddressSanitizer dedicates 1/8 of kernel memory to its shadow memory

(e.g. 16TB to cover 128TB on x86_64) and uses direct mapping with a scale and

offset to translate a memory address to its corresponding shadow address.

Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (e.g. 16TB

to cover 128TB on x86_64) and uses direct mapping with a scale and offset to

translate a memory address to its corresponding shadow address.

Here is the function which translates an address to its corresponding shadow

address::

where ``KASAN_SHADOW_SCALE_SHIFT = 3``.

Compile-time instrumentation used for checking memory accesses. Compiler inserts

function calls (__asan_load*(addr), __asan_store*(addr)) before each memory

access of size 1, 2, 4, 8 or 16. These functions check whether memory access is

valid or not by checking corresponding shadow memory.

Compile-time instrumentation is used to insert memory access checks. Compiler

inserts function calls (__asan_load*(addr), __asan_store*(addr)) before each

memory access of size 1, 2, 4, 8 or 16. These functions check whether memory

access is valid or not by checking corresponding shadow memory.

GCC 5.0 has possibility to perform inline instrumentation. Instead of making

function calls GCC directly inserts the code to check the shadow memory.

This option significantly enlarges kernel but it gives x1.1-x2 performance

boost over outline instrumented kernel.

Software tag-based KASAN

~~~~~~~~~~~~~~~~~~~~~~~~

Tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64 CPUs to

store a pointer tag in the top byte of kernel pointers. Like generic KASAN it

uses shadow memory to store memory tags associated with each 16-byte memory

cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).

On each memory allocation tag-based KASAN generates a random tag, tags the

allocated memory with this tag, and embeds this tag into the returned pointer.

Software tag-based KASAN uses compile-time instrumentation to insert checks

before each memory access. These checks make sure that tag of the memory that

is being accessed is equal to tag of the pointer that is used to access this

memory. In case of a tag mismatch tag-based KASAN prints a bug report.

Software tag-based KASAN also has two instrumentation modes (outline, that

emits callbacks to check memory accesses; and inline, that performs the shadow

memory checks inline). With outline instrumentation mode, a bug report is

simply printed from the function that performs the access check. With inline

instrumentation a brk instruction is emitted by the compiler, and a dedicated

brk handler is used to print bug reports.

A potential expansion of this mode is a hardware tag-based mode, which would

use hardware memory tagging support instead of compiler instrumentation and

manual shadow memory manipulation.

  VmSwap:        0 kB

  HugetlbPages:          0 kB

  CoreDumping:    0

  THP_enabled:	  1

  Threads:        1

  SigQ:   0/28578

  SigPnd: 0000000000000000

 HugetlbPages                size of hugetlb memory portions

 CoreDumping                 process's memory is currently being dumped

                             (killing the process may lead to a corrupted core)

 THP_enabled		     process is allowed to use THP (returns 0 when

			     PR_SET_THP_DISABLE is set on the process

 Threads                     number of threads

 SigQ                        number of signals queued/max. number for queue

 SigPnd                      bitmap of pending signals for the thread

KernelPageSize:        4 kB

MMUPageSize:           4 kB

Locked:                0 kB

THPeligible:           0

VmFlags: rd ex mr mw me dw

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

"SwapPss" shows proportional swap share of this mapping. Unlike "Swap", this

does not take into account swapped out page of underlying shmem objects.

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

"THPeligible" indicates whether the mapping is eligible for THP pages - 1 if

true, 0 otherwise.

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

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

Note that there is no guarantee that every flag and associated mnemonic will

be present in all further kernel releases. Things get changed, the flags may

be vanished or the reverse -- new added.

be vanished or the reverse -- new added. Interpretation of their meaning

might change in future as well. So each consumer of these flags has to

follow each specific kernel version for the exact semantic.

This file is only present if the CONFIG_MMU kernel configuration option is

enabled.

- swappiness

- user_reserve_kbytes

- vfs_cache_pressure

- watermark_boost_factor

- watermark_scale_factor

- zone_reclaim_mode

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

watermark_boost_factor:

This factor controls the level of reclaim when memory is being fragmented.

It defines the percentage of the high watermark of a zone that will be

reclaimed if pages of different mobility are being mixed within pageblocks.

The intent is that compaction has less work to do in the future and to

increase the success rate of future high-order allocations such as SLUB

allocations, THP and hugetlbfs pages.

To make it sensible with respect to the watermark_scale_factor parameter,

the unit is in fractions of 10,000. The default value of 15,000 means

that up to 150% of the high watermark will be reclaimed in the event of

a pageblock being mixed due to fragmentation. The level of reclaim is

determined by the number of fragmentation events that occurred in the

recent past. If this value is smaller than a pageblock then a pageblocks

worth of pages will be reclaimed (e.g.  2MB on 64-bit x86). A boost factor

of 0 will disable the feature.

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

watermark_scale_factor:

This factor controls the aggressiveness of kswapd. It defines the