linux-next.git/Documentation/admin-guide, branch master

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git

2026-09-01T13:26:58+00:00

Merge branch 'docs-next' of git://git.lwn.net/linux.git

2026-09-01T13:26:40+00:00

Merge branch 'fs-next' of linux-next

2026-09-01T13:12:10+00:00

Merge branch 'mm-nonmm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-09-01T12:57:10+00:00

Merge branch 'vfs.all' of https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git

2026-09-01T12:27:35+00:00

hung_task: reset warning budget when problem gets resolved

2026-09-01T05:28:13+00:00

Patch series "hung_task: Improve warning budget handling and task reporting", v10. The hung_task watchdog detects tasks stuck in TASK_UNINTERRUPTIBLE (D) state for longer than CONFIG_DEFAULT_HUNG_TASK_TIMEOUT seconds. To prevent log spam during system spikes, sysctl_hung_task_warnings enforces a budget on the number of logged warnings. However, the current implementation has two major limitations: 1. Permanent exhaustion of warning budget sysctl_hung_task_warnings is decremented directly when printing warnings. Once this budget hits zero, no further warnings are reported until an administrator manually updates the sysctl value or reboots the system. Consequently, a single temporary hang episode permanently blinds the kernel watchdog to any subsequent hung tasks after system recovery. 2. Total log suppression when budget is exhausted Once the warning budget reaches zero, hung_task_info() completely suppresses all output, including the basic single-line alert. While suppressing verbose stack dumps and lock debugging is desirable to prevent dmesg flooding, hiding basic task alerts leaves administrators entirely unaware that tasks are hanging. This patch series resolves both limitations by decoupling the configured warning limit from the active runtime budget, automatically resetting the budget upon system recovery or sysctl updates, and emitting a single aggregate summary line when hung tasks are detected under an exhausted warning budget. Patch 1 separates the configured sysctl hung_task_warnings from the runtime budget, making khungtaskd the sole owner of runtime budget updates. The budget is reloaded directly when a scan finds zero hung tasks, or via an atomic reset request published on sysctl write. Patch 2 prevents dmesg flooding during system-wide hangs by keeping non-panic per-task stack dumps budgeted, while providing ongoing visibility by logging a single aggregate summary line at the end of each scan iteration when the warning budget is exhausted. This patch (of 2): The sysctl hung_task_warnings currently holds both the configured warning limit and the remaining budget. Each detailed report decrements the sysctl, so once it reaches zero, the configured limit is lost and cannot be restored automatically. Keep sysctl_hung_task_warnings as the configured warning limit and make khungtaskd the sole owner of the remaining budget. A check that finds no hung tasks reloads the budget directly from the configured limit. A successful sysctl write publishes an atomic reset request, which khungtaskd consumes at the start of the next check. Link: https://lore.kernel.org/20260829145321.18423-1-atomlin@atomlin.com Link: https://lore.kernel.org/20260829145321.18423-2-atomlin@atomlin.com Signed-off-by: Aaron Tomlin Suggested-by: Petr Mladek Suggested-by: Lance Yang Tested-by: Lance Yang Reviewed-by: Lance Yang Reviewed-by: Bradley Morgan Cc: David Laight Cc: "Masami Hiramatsu (Google)" Signed-off-by: Andrew Morton

docs: cgroup: document empty-write behavior of memory limit knobs

2026-09-01T05:27:08+00:00

A maintenance script on a cluster wrote an unset variable into memory.max of a workload cgroup; the variable expanded to an empty string, the write succeeded, and the workload in the cgroup was OOM-killed. Nothing pointed back at the write, so it took quite some time to trace the OOM kills to that script. The memory controller documentation does not say what an empty write does; the cpuset controller documents its empty-value semantics. The actual behavior is that the empty string is accepted as 0. Reproduced on a k8s cluster (v1.29, cgroup v2, two-container pod, 384M limit): # LIMIT= # echo "$LIMIT" > $CG/memory.max # echo $? 0 m6demo 0/2 OOMKilled 0 Memory cgroup out of memory: Killed process 339529 (sleep) ... anon-rss:32kB State it where the interface files are introduced, alongside the existing notes on units and page rounding. Link: https://lore.kernel.org/all/aoVUlFdZYLFn_gvJ@tiehlicka/ Link: https://lore.kernel.org/20260826021753.197871-1-cui.tao@linux.dev Signed-off-by: Tao Cui Acked-by: Michal Hocko Acked-by: Shakeel Butt Cc: Johannes Weiner Cc: Michal Koutný Cc: Muchun Song Cc: Roman Gushchin Cc: Tejun Heo Signed-off-by: Andrew Morton

mm/ksm: fix advisor_min_pages_to_scan description

2026-09-01T05:27:07+00:00

Both Documentation/admin-guide/mm/ksm.rst and the comment next to the variable definition in mm/ksm.c describe advisor_min_pages_to_scan as a lower limit of the pages_to_scan parameter, but that is not how the scan-time advisor actually uses it. commit 4e5fa4f5eff6 ("mm/ksm: add ksm advisor") only uses it to initialize ksm_thread_pages_to_scan when the scan-time advisor is enabled. ksm_thread_pages_to_scan is adjusted by scan_time_advisor() after a full scan finishes. ksm_thread_pages_to_scan could be increased or decreased depend on the real scan time is longer or shorter than the target scan time. The min value of ksm_thread_pages_to_scan is only limited by KSM_ADVISOR_MIN_CPU, so ksm_thread_pages_to_scan could be smaller than ksm_advisor_min_pages_to_scan. The semantics of advisor_min_pages_to_scan was updated in the v2 patchset [1], but the documentation wasn't updated. Update the documentation and comment to match the semantics of advisor_min_pages_to_scan. Link: https://lore.kernel.org/linux-mm/20231028000945.2428830-2-shr@devkernel.io/ [1] Link: https://lore.kernel.org/20260824061010.3343959-3-tujinjiang@huawei.com Signed-off-by: Jinjiang Tu Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Cc: Chengming Zhou Cc: Jonathan Corbet Cc: Kefeng Wang Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Nanyong Sun Cc: Stefan Roesch Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: xu xin Cc: Randy Dunlap Signed-off-by: Andrew Morton

docs: ksm: fix typos in sysfs knob names

2026-09-01T05:27:06+00:00

Patch series "docs/ksm: fix advisor documentation and comment", v3. This series fixes two problems left in the KSM advisor documentation and code comment: - Patch 1 fixes two typos in sysfs knob names ("adivsor_max_cpu" and "adivsor_max_pages_to_scan") in ksm.rst that don't match the actual knob names. - Patch 2 fixes the description of advisor_min_pages_to_scan: it is described as the lower limit of pages_to_scan, but is actually only used as it's initial value, and the runtime pages_to_scan can drop below advisor_min_pages_to_scan. This patch (of 2): The sysfs knob names in mm/ksm.c are "advisor_max_cpu" and "advisor_max_pages_to_scan", but the ksm.rst documentation spelled both as "adivsor_*", fix the two typos. Link: https://lore.kernel.org/20260824061010.3343959-1-tujinjiang@huawei.com Link: https://lore.kernel.org/20260824061010.3343959-2-tujinjiang@huawei.com Signed-off-by: Jinjiang Tu Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: Randy Dunlap Cc: Chengming Zhou Cc: Jonathan Corbet Cc: Kefeng Wang Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Nanyong Sun Cc: Stefan Roesch Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: xu xin Signed-off-by: Andrew Morton

Merge branch 'master' into mm-hotfixes-stable

2026-09-01T05:23:17+00:00