Merge branch 'akpm' (patches from Andrew)

The hardware KASAN mode (#3) relies on hardware to perform the checks but

still requires a compiler version that supports memory tagging instructions.

This mode is supported in GCC 10+ and Clang 11+.

This mode is supported in GCC 10+ and Clang 12+.

Both software KASAN modes work with SLUB and SLAB memory allocators,

while the hardware tag-based KASAN currently only supports SLUB.

  Asymmetric mode: a bad access is detected synchronously on reads and

  asynchronously on writes.

- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc

  allocations (default: ``on``).

- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack

  traces collection (default: ``on``).

pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently

reserved to tag freed memory regions.

Software tag-based KASAN currently only supports tagging of slab and page_alloc

memory.

Software tag-based KASAN currently only supports tagging of slab, page_alloc,

and vmalloc memory.

Hardware tag-based KASAN

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

pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently

reserved to tag freed memory regions.

Hardware tag-based KASAN currently only supports tagging of slab and page_alloc

memory.

Hardware tag-based KASAN currently only supports tagging of slab, page_alloc,

and VM_ALLOC-based vmalloc memory.

If the hardware does not support MTE (pre ARMv8.5), hardware tag-based KASAN

will not be enabled. In this case, all KASAN boot parameters are ignored.

Shadow memory

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

The contents of this section are only applicable to software KASAN modes.

The kernel maps memory in several different parts of the address space.

The range of kernel virtual addresses is large: there is not enough real

memory to support a real shadow region for every address that could be

With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the

cost of greater memory usage. Currently, this is supported on x86,

riscv, s390, and powerpc.

arm64, riscv, s390, and powerpc.

This works by hooking into vmalloc and vmap and dynamically

allocating real shadow memory to back the mappings.

2) Enable page owner: add "page_owner=on" to boot cmdline.

3) Do the job what you want to debug

3) Do the job that you want to debug.

4) Analyze information from page owner::

   The ``page_owner_sort`` tool ignores ``PFN`` rows, puts the remaining rows

   in buf, uses regexp to extract the page order value, counts the times

   and pages of buf, and finally sorts them according to the times.

   and pages of buf, and finally sorts them according to the parameter(s).

   See the result about who allocated each page

   in the ``sorted_page_owner.txt``. General output::

	// Detailed stack

   By default, ``page_owner_sort`` is sorted according to the times of buf.

   If you want to sort by the pages nums of buf, use the ``-m`` parameter.

   If you want to sort by the page nums of buf, use the ``-m`` parameter.

   The detailed parameters are:

   fundamental function:

	Sort:

		-a		Sort by memory allocation time.

		-m		Sort by total memory.

		-p		Sort by pid.

		-P		Sort by tgid.

		-n		Sort by task command name.

		-r		Sort by memory release time.

		-s		Sort by stack trace.

		-t		Sort by times (default).

   additional function:

	Cull:

		-c		Cull by comparing stacktrace instead of total block.

		--cull <rules>

				Specify culling rules.Culling syntax is key[,key[,...]].Choose a

				multi-letter key from the **STANDARD FORMAT SPECIFIERS** section.

		<rules> is a single argument in the form of a comma-separated list,

		which offers a way to specify individual culling rules.  The recognized

		keywords are described in the **STANDARD FORMAT SPECIFIERS** section below.

		<rules> can be specified by the sequence of keys k1,k2, ..., as described in

		the STANDARD SORT KEYS section below. Mixed use of abbreviated and

		complete-form of keys is allowed.

		Examples:

				./page_owner_sort <input> <output> --cull=stacktrace

				./page_owner_sort <input> <output> --cull=st,pid,name

				./page_owner_sort <input> <output> --cull=n,f

	Filter:

		-f		Filter out the information of blocks whose memory has been released.

	Select:

		--pid <PID>		Select by pid.

		--tgid <TGID>		Select by tgid.

		--name <command>	Select by task command name.

STANDARD FORMAT SPECIFIERS

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

	KEY		LONG		DESCRIPTION

	p		pid		process ID

	tg		tgid		thread group ID

	n		name		task command name

	f		free		whether the page has been released or not

	st		stacktrace	stace trace of the page allocation

#define MADV_POPULATE_READ	22	/* populate (prefault) page tables readable */

#define MADV_POPULATE_WRITE	23	/* populate (prefault) page tables writable */

#define MADV_DONTNEED_LOCKED	24	/* like DONTNEED, but drop locked pages too */

/* compatibility flags */

#define MAP_FILE	0

	select IOMMU_DMA if IOMMU_SUPPORT

	select IRQ_DOMAIN

	select IRQ_FORCED_THREADING

	select KASAN_VMALLOC if KASAN_GENERIC

	select KASAN_VMALLOC if KASAN

	select MODULES_USE_ELF_RELA

	select NEED_DMA_MAP_STATE

	select NEED_SG_DMA_LENGTH

#endif

#define arch_vmap_pgprot_tagged arch_vmap_pgprot_tagged

static inline pgprot_t arch_vmap_pgprot_tagged(pgprot_t prot)

{

	return pgprot_tagged(prot);

}

#endif /* _ASM_ARM64_VMALLOC_H */