| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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]>
|
|
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.
Link: https://lkml.kernel.org/r/b839d611e2906ccef2725c34d8e353fab35fe75e.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]>
|
|
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 e57ef2ed97c1 ("x86: Put hot per CPU variables into a struct")
changed it.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: e57ef2ed97c1 ("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]>
|
|
These scripts have some pep8 style warnings. Fix them up so that this
directory is all pep8 clean.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Stephen Boyd <[email protected]>
Cc: Douglas Anderson <[email protected]>
Cc: Nikolay Borisov <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Jackie Liu <[email protected]>
Cc: Jason Wessel <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
We won't see more than 2 billion CPUs any time soon, and having cpu_list
return long makes the output of lx-cpus a bit ugly.
Link: http://lkml.kernel.org/r/dcb45c3b0a59e0fd321fa56ff7aa398458c689b3.1462865983.git.jan.kiszka@siemens.com
Signed-off-by: Jan Kiszka <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The linux kernel provides macro's for iterating against values from the
cpu_list masks. By providing some commonly used masks, we can mirror
the kernels helper macros with easy to use generators.
Link: http://lkml.kernel.org/r/d045c6599771ada1999d49612ee30fd2f9acf17f.1462865983.git.jan.kiszka@siemens.com
Signed-off-by: Kieran Bingham <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Yet another code simplification.
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]>
|
|
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]>
|
|
Will be used first to count module references. It is optimized to read
the mask only once per stop.
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]>
|
|
This is a shorthand for *$lx_per_cpu("current_task"), i.e. a convenience
function to retrieve the currently running task of the active context.
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]>
|
|
This function allows to obtain a per-cpu variable, either of the current
or an explicitly specified CPU.
Note: sparc64 version is untested.
Signed-off-by: Jan Kiszka <[email protected]>
Cc: "David S. Miller" <[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]>
|