Pull non-MM updates from Andrew Morton:
- The series "powerpc/crash: use generic crashkernel reservation" from
Sourabh Jain changes powerpc's kexec code to use more of the generic
layers.
- The series "get_maintainer: report subsystem status separately" from
Vlastimil Babka makes some long-requested improvements to the
get_maintainer output.
- The series "ucount: Simplify refcounting with rcuref_t" from
Sebastian Siewior cleans up and optimizing the refcounting in the
ucount code.
- The series "reboot: support runtime configuration of emergency
hw_protection action" from Ahmad Fatoum improves the ability for a
driver to perform an emergency system shutdown or reboot.
- The series "Converge on using secs_to_jiffies() part two" from Easwar
Hariharan performs further migrations from msecs_to_jiffies() to
secs_to_jiffies().
- The series "lib/interval_tree: add some test cases and cleanup" from
Wei Yang permits more userspace testing of kernel library code, adds
some more tests and performs some cleanups.
- The series "hung_task: Dump the blocking task stacktrace" from Masami
Hiramatsu arranges for the hung_task detector to dump the stack of
the blocking task and not just that of the blocked task.
- The series "resource: Split and use DEFINE_RES*() macros" from Andy
Shevchenko provides some cleanups to the resource definition macros.
- Plus the usual shower of singleton patches - please see the
individual changelogs for details.
* tag 'mm-nonmm-stable-2025-03-30-18-23' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (77 commits)
mailmap: consolidate email addresses of Alexander Sverdlin
fs/procfs: fix the comment above proc_pid_wchan()
relay: use kasprintf() instead of fixed buffer formatting
resource: replace open coded variant of DEFINE_RES()
resource: replace open coded variants of DEFINE_RES_*_NAMED()
resource: replace open coded variant of DEFINE_RES_NAMED_DESC()
resource: split DEFINE_RES_NAMED_DESC() out of DEFINE_RES_NAMED()
samples: add hung_task detector mutex blocking sample
hung_task: show the blocker task if the task is hung on mutex
kexec_core: accept unaccepted kexec segments' destination addresses
watchdog/perf: optimize bytes copied and remove manual NUL-termination
lib/interval_tree: fix the comment of interval_tree_span_iter_next_gap()
lib/interval_tree: skip the check before go to the right subtree
lib/interval_tree: add test case for span iteration
lib/interval_tree: add test case for interval_tree_iter_xxx() helpers
lib/rbtree: add random seed
lib/rbtree: split tests
lib/rbtree: enable userland test suite for rbtree related data structure
checkpatch: describe --min-conf-desc-length
scripts/gdb/symbols: determine KASLR offset on s390
...
We currently have $lx_per_cpu() which works fine for stuff that kernel
code would access via per_cpu(). But this doesn't work for stuff that
kernel code accesses via per_cpu_ptr():
(gdb) p $lx_per_cpu(node_data[1].node_zones[2]->per_cpu_pageset)
Cannot access memory at address 0xffff11105fbd6c28
This is because we take the address of the pointer and use that as the
offset, instead of using the stored value.
Add a GDB version that mirrors the kernel API, which uses the pointer
value.
To be consistent with per_cpu_ptr(), we need to return the pointer value
instead of dereferencing it for the user. Therefore, move the existing
dereference out of the per_cpu() Python helper and do that only in the
$lx_per_cpu() implementation.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Brendan Jackman <[email protected]>
Reviewed-by: Jan Kiszka <[email protected]>
Cc: Florian Rommel <[email protected]>
Cc: Kieran Bingham <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Directly read the current CPU number from the kgdb_active variable.
Before, the active CPU was obtained through the current task, which
required searching the task list for the pid of GDB's selected thread.
Obtaining the pid was buggy: GDB may use selected_thread().ptid[1] (LWPID)
instead of .ptid[2] (TID) to store the threads pid; see
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Threads-In-Python.html
As a result, the detection could return the wrong CPU number, leading to
incorrect results for $lx_per_cpu and $lx_current.
As a side effect, the patch significantly speeds up $lx_per_cpu and
$lx_current in KGDB by avoiding the task-list iteration.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Florian Rommel <[email protected]>
Cc: Andrew Jones <[email protected]>
Cc: Deepak Gupta <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Kuan-Ying Lee <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Before, the script tried to get the address by constructing a pointer to
the parameter (by name). However, since GDB now passes the parameter as a
GdbValue, we cannot get its name. Instead, we retrieve the address
through GdbValue's address attribute.
Before:
>>> p $lx_per_cpu(cpu_info)
Traceback (most recent call last):
File "./scripts/gdb/linux/cpus.py", line 152, in invoke
var_ptr = gdb.parse_and_eval("&" + var_name.string())
^^^^^^^^^^^^^^^^^
gdb.error: Trying to read string with inappropriate type `struct cpuinfo_x86'.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Florian Rommel <[email protected]>
Cc: Andrew Jones <[email protected]>
Cc: Deepak Gupta <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Kuan-Ying Lee <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
csr_sscratch CSR holds current task_struct address when hart is in user
space. Trap handler on entry spills csr_sscratch into "tp" (x2) register
and zeroes out csr_sscratch CSR. Trap handler on exit reloads "tp" with
expected user mode value and place current task_struct address again in
csr_sscratch CSR.
This patch assumes "tp" is pointing to task_struct. If value in
csr_sscratch is numerically greater than "tp" then it assumes csr_sscratch
is correct address of current task_struct. This logic holds when
- hart is in user space, "tp" will be less than csr_sscratch.
- hart is in kernel space but not in trap handler, "tp" will be more
than csr_sscratch (csr_sscratch being equal to 0).
- hart is executing trap handler
- "tp" is still pointing to user mode but csr_sscratch contains
ptr to task_struct. Thus numerically higher.
- "tp" is pointing to task_struct but csr_sscratch now contains
either 0 or numerically smaller value (transiently holds
user mode tp)
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Deepak Gupta <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Palmer Dabbelt <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Tested-by: Hsieh-Tseng Shen <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: Glenn Washburn <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Jeff Xie <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Paul Walmsley <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Patch series "scripts/gdb: Support getting current task struct in UML",
v3.
A running x86 UML kernel reports with architecture "i386:x86-64" as it is
a sub-architecture. However, a difference with bare-metal x86 kernels is
in how it manages tasks and the current task struct. To identify that the
inferior is a UML kernel and not bare-metal, check for the existence of
the UML specific symbol "cpu_tasks" which contains the current task
struct.
This patch (of 3):
There is an extra space in a couple blocks in get_current_task. Though
python does not care, let's make the spacing consistent. Also, format
better an if expression, removing unneeded parenthesis.
Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/2e117b82240de6893f27cb6507242ce455ed7b5b.1677469905.git.development@efficientek.com
Signed-off-by: Glenn Washburn <[email protected]>
Reviewed-by: Jan Kiszka <[email protected]>
Cc: Anton Ivanov <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Richard Weinberger <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
When printing the name of the current process, it will report an error:
(gdb) p $lx_current().comm Python Exception <class 'gdb.error'> No symbol
"current_task" in current context.: Error occurred in Python: No symbol
"current_task" in current context.
Because e57ef2ed97 ("x86: Put hot per CPU variables into a struct")
changed it.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: e57ef2ed97 ("x86: Put hot per CPU variables into a struct")
Signed-off-by: Jeff Xie <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
arm64 uses SP_EL0 to save the current task_struct address. While running
in EL0, SP_EL0 is clobbered by userspace. So if the upper bit is not 1
(not TTBR1), the current address is invalid. This patch checks the upper
bit of SP_EL0, if the upper bit is 1, lx_current() of arm64 will return
the derefrence of current task. Otherwise, lx_current() will tell users
they are running in userspace(EL0).
While arm64 is running in EL0, it is actually pointless to print current
task as the memory of kernel space is not accessible in EL0.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Barry Song <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Kieran Bingham <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Patch series "scripts/gdb: clarify the platforms supporting lx_current and add arm64 support", v2.
lx_current depends on per_cpu current_task variable which exists on x86
only. so it actually works on x86 only. the 1st patch documents this
clearly; the 2nd patch adds support for arm64.
This patch (of 2):
x86 is the only architecture which has per_cpu current_task:
arch$ git grep current_task | grep -i per_cpu
x86/include/asm/current.h:DECLARE_PER_CPU(struct task_struct *, current_task);
x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) ____cacheline_aligned =
x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task);
x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) = &init_task;
x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task);
x86/kernel/smpboot.c: per_cpu(current_task, cpu) = idle;
On other architectures, lx_current() will lead to a python exception:
(gdb) p $lx_current().pid
Python Exception <class 'gdb.error'> No symbol "current_task" in current context.:
Error occurred in Python: No symbol "current_task" in current context.
To avoid more people struggling and wasting time in other architectures,
document it.
Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Barry Song <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
I tried to use these scripts in an ubuntu 14.04 host (gdb 7.7 compiled
against python 3.3) but there were several errors.
I believe this patch fixes these issues so that the commands now work (I
tested lx-symbols, lx-dmesg, lx-lsmod).
Main issues that needed to be resolved:
* In python 2 iterators have a "next()" method. In python 3 it is
__next__() instead (so let's just add both).
* In older python versions there was an implicit conversion
in object.__format__() (used when an object is in string.format())
where it was converting the object to str first and then
calling str's __format__(). This has now been removed so
we must explicitly convert to str the objects for which
we need to keep this behavior.
* In dmesg.py: in python 3 log_buf is now a "memoryview" object
which needs to be converted to a string in order to use string
methods like "splitlines()". Luckily memoryview exists in
python 2.7.6 as well, so we can convert log_buf to memoryview
and use the same code in both python 2 and python 3.
This version of the patch has now been tested with gdb 7.7 and both python
3.4 and python 2.7.6 (I think asking for at least python 2.7.6 is a
reasonable requirement instead of complicating the code with version
checks etc).
Signed-off-by: Pantelis Koukousoulas <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Jason Wessel <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Ben Widawsky <[email protected]>
Cc: Borislav Petkov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Illia Ostapyshyn