Commit 4c48faba authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'akpm' (patches from Andrew) 

Merge misc updates from Andrew Morton:
 "A few small subsystems and some of MM.

  172 patches.

  Subsystems affected by this patch series: hexagon, scripts, ntfs,
  ocfs2, vfs, and mm (slab-generic, slab, slub, debug, pagecache, swap,
  memcg, pagemap, mprotect, mremap, page-reporting, vmalloc, kasan,
  pagealloc, memory-failure, hugetlb, vmscan, z3fold, compaction,
  mempolicy, oom-kill, hugetlbfs, and migration)"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (172 commits)
  mm/migrate: remove unneeded semicolons
  hugetlbfs: remove unneeded return value of hugetlb_vmtruncate()
  hugetlbfs: fix some comment typos
  hugetlbfs: correct some obsolete comments about inode i_mutex
  hugetlbfs: make hugepage size conversion more readable
  hugetlbfs: remove meaningless variable avoid_reserve
  hugetlbfs: correct obsolete function name in hugetlbfs_read_iter()
  hugetlbfs: use helper macro default_hstate in init_hugetlbfs_fs
  hugetlbfs: remove useless BUG_ON(!inode) in hugetlbfs_setattr()
  hugetlbfs: remove special hugetlbfs_set_page_dirty()
  mm/hugetlb: change hugetlb_reserve_pages() to type bool
  mm, oom: fix a comment in dump_task()
  mm/mempolicy: use helper range_in_vma() in queue_pages_test_walk()
  numa balancing: migrate on fault among multiple bound nodes
  mm, compaction: make fast_isolate_freepages() stay within zone
  mm/compaction: fix misbehaviors of fast_find_migrateblock()
  mm/compaction: correct deferral logic for proactive compaction
  mm/compaction: remove duplicated VM_BUG_ON_PAGE !PageLocked
  mm/compaction: remove rcu_read_lock during page compaction
  z3fold: simplify the zhdr initialization code in init_z3fold_page()
  ...
parents 062c84fc a553e3cd

Documentation/admin-guide/cgroup-v2.rst

+4 −0
Original line number Diff line number Diff line
@@ -1299,6 +1299,10 @@ PAGE_SIZE multiple when read back. 
		Amount of cached filesystem data that was modified and

		is currently being written back to disk



	  swapcached

		Amount of swap cached in memory. The swapcache is accounted

		against both memory and swap usage.



	  anon_thp

		Amount of memory used in anonymous mappings backed by

		transparent hugepages

Documentation/admin-guide/kernel-parameters.txt

+0 −8
Original line number Diff line number Diff line
@@ -4904,14 +4904,6 @@ 
			last alloc / free. For more information see

			Documentation/vm/slub.rst.



	slub_memcg_sysfs=	[MM, SLUB]

			Determines whether to enable sysfs directories for

			memory cgroup sub-caches. 1 to enable, 0 to disable.

			The default is determined by CONFIG_SLUB_MEMCG_SYSFS_ON.

			Enabling this can lead to a very high number of	debug

			directories and files being created under

			/sys/kernel/slub.



	slub_max_order= [MM, SLUB]

			Determines the maximum allowed order for slabs.

			A high setting may cause OOMs due to memory

Documentation/admin-guide/sysctl/vm.rst

+5 −5
Original line number Diff line number Diff line
@@ -983,11 +983,11 @@ that benefit from having their data cached, zone_reclaim_mode should be 
left disabled as the caching effect is likely to be more important than

data locality.



zone_reclaim may be enabled if it's known that the workload is partitioned

such that each partition fits within a NUMA node and that accessing remote

memory would cause a measurable performance reduction.  The page allocator

will then reclaim easily reusable pages (those page cache pages that are

currently not used) before allocating off node pages.

Consider enabling one or more zone_reclaim mode bits if it's known that the

workload is partitioned such that each partition fits within a NUMA node

and that accessing remote memory would cause a measurable performance

reduction.  The page allocator will take additional actions before

allocating off node pages.



Allowing zone reclaim to write out pages stops processes that are

writing large amounts of data from dirtying pages on other nodes. Zone

Documentation/core-api/mm-api.rst

+2 −5
Original line number Diff line number Diff line
@@ -19,11 +19,8 @@ User Space Memory Access 
Memory Allocation Controls

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



Functions which need to allocate memory often use GFP flags to express

how that memory should be allocated. The GFP acronym stands for "get

free pages", the underlying memory allocation function. Not every GFP

flag is allowed to every function which may allocate memory. Most

users will want to use a plain ``GFP_KERNEL``.

.. kernel-doc:: include/linux/gfp.h

   :internal:



.. kernel-doc:: include/linux/gfp.h

   :doc: Page mobility and placement hints

Documentation/dev-tools/kasan.rst

+15 −9
Original line number Diff line number Diff line
@@ -147,15 +147,14 @@ negative values to distinguish between different kinds of inaccessible memory 
like redzones or freed memory (see mm/kasan/kasan.h).



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).

the accessed address is partially accessible. For tag-based KASAN modes this

last report section shows the memory tags around the accessed address

(see the `Implementation details`_ section).



Boot parameters

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



Hardware tag-based KASAN mode (see the section about different mode below) is

Hardware tag-based KASAN mode (see the section about various modes below) is

intended for use in production as a security mitigation. Therefore it supports

boot parameters that allow to disable KASAN competely or otherwise control

particular KASAN features.
@@ -289,6 +288,13 @@ reserved to tag freed memory regions. 
Hardware tag-based KASAN currently only supports tagging of

kmem_cache_alloc/kmalloc and page_alloc memory.



If the hardware doesn't support MTE (pre ARMv8.5), hardware tag-based KASAN

won't be enabled. In this case all boot parameters are ignored.



Note, that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being

enabled. Even when kasan.mode=off is provided, or when the hardware doesn't

support MTE (but supports TBI).



What memory accesses are sanitised by KASAN?

--------------------------------------------
@@ -352,17 +358,17 @@ unmapped. This will require changes in arch-specific code. 
This allows ``VMAP_STACK`` support on x86, and can simplify support of

architectures that do not have a fixed module region.



CONFIG_KASAN_KUNIT_TEST & CONFIG_TEST_KASAN_MODULE

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

CONFIG_KASAN_KUNIT_TEST and CONFIG_KASAN_MODULE_TEST

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



KASAN tests consist on two parts:

KASAN tests consist of two parts:



1. Tests that are integrated with the KUnit Test Framework. Enabled with

``CONFIG_KASAN_KUNIT_TEST``. These tests can be run and partially verified

automatically in a few different ways, see the instructions below.



2. Tests that are currently incompatible with KUnit. Enabled with

``CONFIG_TEST_KASAN_MODULE`` and can only be run as a module. These tests can

``CONFIG_KASAN_MODULE_TEST`` and can only be run as a module. These tests can

only be verified manually, by loading the kernel module and inspecting the

kernel log for KASAN reports.