[PATCH v4 0/1] Filter ps output by scheduling policy
by Oleksandr Natalenko
While analyzing vmcores from customers sometimes we want
to filter tasks by scheduling policy, for instance, to identify
if customer runs realtime tasks. Doing this via foreach grepping
and then feeding back pointers to task_struct and grepping it again
is very slow, especially if customer runs thousands of tasks.
So, let's add another option for ps to filter tasks by scheduling
policy.
Changes in v4:
* apply Dave's modifications:
* throw fatal error instead of defaulting to NORMAL policy
* re-word and re-structure help entry
* relocate task_struct_policy members to the end of structs
* show task_struct_policy info in "help -o"
* replace strdup/calloc/free with wrappers
* allow using hex values to specify policy
Changes in v3:
* fix snprintf format specifier for ulong
* fix snprintf block indentation
* add one more comma to help output
Changes in v2:
* handle task_struct.policy member size correctly
* accept comma-separated list of policies
instead of requiring multiple -y arguments
* policy can be specified as a number too
* policy name is case-insensitive now
* warn about incorrect policy name
* fix help message formatting
* mark upper_case() source string pointer as a const
(minor cleanup)
Oleksandr Natalenko (1):
task: also filter ps output by ->policy
defs.h | 15 ++++++-
help.c | 14 +++++-
symbols.c | 3 ++
task.c | 143 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
tools.c | 5 ++-
5 files changed, 170 insertions(+), 10 deletions(-)
--
2.14.2
6 years, 8 months
[PATCH v3 0/1] Filter ps output by scheduling policy
by Oleksandr Natalenko
While analyzing vmcores from customers sometimes we want
to filter tasks by scheduling policy, for instance, to identify
if customer runs realtime tasks. Doing this via foreach grepping
and then feeding back pointers to task_struct and grepping it again
is very slow, especially if customer runs thousands of tasks.
So, let's add another option for ps to filter tasks by scheduling
policy.
Changes in v3:
* fix snprintf format specifier for ulong
* fix snprintf block indentation
* add one more comma to help output
Changes in v2:
* handle task_struct.policy member size correctly
* accept comma-separated list of policies
instead of requiring multiple -y arguments
* policy can be specified as a number too
* policy name is case-insensitive now
* warn about incorrect policy name
* fix help message formatting
* mark upper_case() source string pointer as a const
(minor cleanup)
Oleksandr Natalenko (1):
task: also filter ps output by ->policy
defs.h | 15 +++++++-
help.c | 7 +++-
task.c | 135 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
tools.c | 5 ++-
4 files changed, 152 insertions(+), 10 deletions(-)
--
2.14.2
6 years, 8 months
[PATCH v2 0/1] Filter ps output by scheduling policy
by Oleksandr Natalenko
In CEE we often analyze vmcores from customers and sometimes want
to filter tasks by scheduling policy, for instance, to identify
if customer runs realtime tasks. Doing this via foreach grepping
and then feeding back pointers to task_struct and grepping it again
is very slow, especially if customer runs thousands of tasks.
So, let's add another option for ps to filter tasks by scheduling
policy.
Changes in v2:
* handle task_struct.policy member size correctly
* accept comma-separated list of policies
instead of requiring multiple -y arguments
* policy can be specified as a number too
* policy name is case-insensitive now
* warn about incorrect policy name
* fix help message formatting
* mark upper_case() source string pointer as a const
(minor cleanup)
Oleksandr Natalenko (1):
task: also filter ps output by ->policy
defs.h | 15 +++++++-
help.c | 7 +++-
task.c | 135 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
tools.c | 5 ++-
4 files changed, 152 insertions(+), 10 deletions(-)
--
2.14.2
6 years, 8 months
[PATCH v3 0/2] Fix KASLR problem on sadump
by Takao Indoh
Hi Dave, Hatayama-san,
These patch series fix a problem that crash cannot open a dumpfile which is
captured by sadump on KASLR enabled kernel.
When KASLR feature is enabled, a kernel is placed on the memory randomly and
therefore crash cannot open a dumpfile because addresses of kernel symbols in
vmlinux are different from actual addresses. In the case of kdump, information
to get actual address is included in the vmcoreinfo, but dumpfile of sadump does
not have such a information.
These patches calculate kaslr offset and phys_base to solve this problem. The
basic idea is getting register (IDTR and CR3) from dump header, and calculate
kaslr_offset/phys_base using them.
changelog:
v3:
- Rebase on the latest branch
- Fix to get rid of compile warnings except x86_64
- Implement patch 1/2 without adding new function into x86_64.c
v2:
https://www.redhat.com/archives/crash-utility/2017-October/msg00018.html
- Remove virsh-dump part
- Change get_vec0_addr style
- Some tiny fixes
v1:
https://www.redhat.com/archives/crash-utility/2017-October/msg00004.html
Takao Indoh (2):
Call x86_64_kvtop during symtab_init() for sadump
Fix a KASLR problem of sadump
defs.h | 4 +
sadump.c | 465 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
sadump.h | 1 +
symbols.c | 34 +++++
x86_64.c | 21 +++
5 files changed, 524 insertions(+), 1 deletion(-)
--
2.9.5
6 years, 8 months
Problem in bt for ARM64
by Karlsson, Jan
Hi Dave
I have experienced some problems in the bt command for ARM64. It seems that the test in arm64_print_exception_frame in arm64.c if the task is running in 32 or 64-bit mode in userland does not work. It "always" becomes 32-bit mode. Example:
crash> bt 1
PID: 1 TASK: ffffffe1f90f8000 CPU: 2 COMMAND: "init"
#0 [ffffffe1f9103c80] __switch_to at ffffff85b6a862f8
#1 [ffffffe1f9103ca0] __schedule at ffffff85b7b0d9b0
#2 [ffffffe1f9103d00] schedule at ffffff85b7b0df28
#3 [ffffffe1f9103d20] schedule_hrtimeout_range_clock at ffffff85b7b11308
#4 [ffffffe1f9103da0] schedule_hrtimeout_range at ffffff85b7b11320
#5 [ffffffe1f9103db0] sys_epoll_wait at ffffff85b6c394c8
#6 [ffffffe1f9103e70] sys_epoll_pwait at ffffff85b6c396fc
#7 [ffffffe1f9103ed0] el0_svc_naked at ffffff85b6a8312c
PC: 00000004 LR: 00000000 SP: 00000000 PSTATE: 00000016
X12: 00546694 X11: 3431206c616e6769 X10: 00546338 X9: 00000000
X8: 00000112 X7: dfdab819254dd1e8 X6: 00000016 X5: 0000000a
X4: 00000031 X3: 00000008 X2: 00000000 X1: ffffffff
X0: 00000001
The register values are:
r0: 4 r1: 7ff0b27f90
r2: 1 r3: ffffffff
r4: 0 r5: 8
r6: 31 r7: a
r8: 16 r9: dfdab819254dd1e8
r10: 112 r11: 0
r12: 546338 r13: 3431206c616e6769
r14: 546694 r15: 0
r16: 0 r17: f04245b7
r18: 51f2a993 r19: 5783c0
r20: 415254 r21: 527a5c
r22: 527e04 r23: ffffffff
r24: ffffffff r25: 576000
r26: 578000 r27: 578000
r28: 3e8 fp: 7ff0b27ec0
lr: 4f4f24 sp: 7ff0b27eb0
pc: 4fb8d4 psr: 40000000
I have unfortunately not had the time to look for a solution, so I just want to report what I have seen. The kernel running in the example above is 4.4.74 and I have seen the same problem for a 4.9.40 kernel.
Jan
6 years, 8 months
[PATCH RFC 0/1] Filter ps output by scheduling policy
by Oleksandr Natalenko
In CEE we often analyze vmcores from customers and sometimes want
to filter tasks by scheduling policy, for instance, to identify
if customer runs realtime tasks. Doing this via foreach grepping
and then feeding back pointers to task_struct and grepping it again
is very slow, especially if customer runs thousands of tasks.
So, let's add another option for ps to filter tasks by scheduling
policy.
Oleksandr Natalenko (1):
task: also filter ps output by ->policy
defs.h | 12 ++++++++++
help.c | 7 ++++--
task.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
3 files changed, 98 insertions(+), 7 deletions(-)
--
2.14.2
6 years, 8 months
[PATCH] search: Introduce -T option
by Aaron Tomlin
Like the -t option, except consider only the "active" task
on each CPU and cannot be used on a live system or dump.
The -t and -T options are mutually exclusive.
Signed-off-by: Aaron Tomlin <atomlin(a)redhat.com>
---
help.c | 4 +++-
memory.c | 52 ++++++++++++++++++++++++++++++++++++++++------------
2 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/help.c b/help.c
index 2d80202..5b3e89c 100644
--- a/help.c
+++ b/help.c
@@ -2862,7 +2862,7 @@ NULL
char *help_search[] = {
"search",
"search memory",
-"[-s start] [ -[kKV] | -u | -p | -t ] [-e end | -l length] [-m mask]\n"
+"[-s start] [ -[kKV] | -u | -p | -t|-T ] [-e end | -l length] [-m mask]\n"
" [-x count] -[cwh] [value | (expression) | symbol | string] ...",
" This command searches for a given value within a range of user virtual, kernel",
" virtual, or physical memory space. If no end nor length value is entered, ",
@@ -2893,6 +2893,8 @@ char *help_search[] = {
" -t Search only the kernel stack pages of every task. If one or more",
" matches are found in a task's kernel stack, precede the output",
" with a task-identifying header.",
+" -T Same as -t, except only the active task(s) are considered.",
+" This option cannot be used on a live system or dump.",
" -e end Stop the search at this hexadecimal user or kernel virtual",
" address, kernel symbol, or physical address. The end address",
" must be appropriate for the memory type specified.",
diff --git a/memory.c b/memory.c
index 8efe0b2..573b670 100644
--- a/memory.c
+++ b/memory.c
@@ -227,6 +227,7 @@ static ulonglong search_ushort_p(ulong *, ulonglong, int, struct searchinfo *);
static ulonglong search_chars_p(ulong *, ulonglong, int, struct searchinfo *);
static void search_virtual(struct searchinfo *);
static void search_physical(struct searchinfo *);
+static void prepare_searchinfo_for_task_search(struct searchinfo *, struct task_context *);
static int next_upage(struct task_context *, ulong, ulong *);
static int next_kpage(ulong, ulong *);
static int next_physpage(ulonglong, ulonglong *);
@@ -13864,7 +13865,15 @@ generic_get_kvaddr_ranges(struct vaddr_range *rp)
return cnt;
}
-
+static void
+prepare_searchinfo_for_task_search(struct searchinfo *si, struct task_context *tc)
+{
+ si->tasks_found = 0;
+ si->vaddr_start = GET_STACKBASE(tc->task);
+ si->vaddr_end = GET_STACKTOP(tc->task);
+ si->task_context = tc;
+ si->do_task_header = TRUE;
+}
/*
* Search for a given value between a starting and ending address range,
* applying an optional mask for "don't care" bits. As an alternative
@@ -13882,7 +13891,7 @@ cmd_search(void)
ulong value, mask, len;
ulong uvaddr_start, uvaddr_end;
ulong kvaddr_start, kvaddr_end, range_end;
- int sflag, Kflag, Vflag, pflag, tflag;
+ int sflag, Kflag, Vflag, pflag, Tflag, tflag;
struct searchinfo searchinfo;
struct syment *sp;
struct node_table *nt;
@@ -13896,7 +13905,7 @@ cmd_search(void)
context = max = 0;
start = end = 0;
- value = mask = sflag = pflag = Kflag = Vflag = memtype = len = tflag = 0;
+ value = mask = sflag = pflag = Kflag = Vflag = memtype = len = Tflag = tflag = 0;
kvaddr_start = kvaddr_end = 0;
uvaddr_start = UNINITIALIZED;
uvaddr_end = COMMON_VADDR_SPACE() ? (ulong)(-1) : machdep->kvbase;
@@ -13933,7 +13942,7 @@ cmd_search(void)
searchinfo.mode = SEARCH_ULONG; /* default search */
- while ((c = getopt(argcnt, args, "tl:ukKVps:e:v:m:hwcx:")) != EOF) {
+ while ((c = getopt(argcnt, args, "Ttl:ukKVps:e:v:m:hwcx:")) != EOF) {
switch(c)
{
case 'u':
@@ -14038,6 +14047,10 @@ cmd_search(void)
context = dtoi(optarg, FAULT_ON_ERROR, NULL);
break;
+ case 'T':
+ Tflag++;
+ break;
+
case 't':
if (XEN_HYPER_MODE())
error(FATAL,
@@ -14052,10 +14065,20 @@ cmd_search(void)
}
}
- if (tflag && (memtype || start || end || len))
+ if ((tflag || Tflag) && (memtype || start || end || len))
+ error(FATAL,
+ "-%s option cannot be used with other "
+ "memory-selection options\n",
+ tflag ? "t" : "T");
+
+ if (Tflag && LIVE())
+ error(FATAL,
+ "-T option cannot be used on a live "
+ "system or live dump\n");
+
+ if (tflag && Tflag)
error(FATAL,
- "-t option cannot be used with other "
- "memory-selection options\n");
+ "-t and -T options are mutually exclusive\n");
if (XEN_HYPER_MODE()) {
memtype = KVADDR;
@@ -14328,14 +14351,19 @@ cmd_search(void)
break;
}
+ if (Tflag) {
+ for (c = 0; c < NR_CPUS; c++)
+ if ((tc = task_to_context(tt->panic_threads[c]))) {
+ prepare_searchinfo_for_task_search(&searchinfo, tc);
+ search_virtual(&searchinfo);
+ }
+ break;
+ }
+
if (tflag) {
- searchinfo.tasks_found = 0;
tc = FIRST_CONTEXT();
for (i = 0; i < RUNNING_TASKS(); i++, tc++) {
- searchinfo.vaddr_start = GET_STACKBASE(tc->task);
- searchinfo.vaddr_end = GET_STACKTOP(tc->task);
- searchinfo.task_context = tc;
- searchinfo.do_task_header = TRUE;
+ prepare_searchinfo_for_task_search(&searchinfo, tc);
search_virtual(&searchinfo);
}
break;
--
2.9.4
6 years, 8 months
[PATCH v2 0/2] Fix KASLR problem on sadump
by Takao Indoh
Hi Dave, Hatayama-san,
Hatayama-san, thanks for your review, I updated may patch.
These patch series fix a problem that crash cannot open a dumpfile which is
captured by sadump on KASLR enabled kernel.
When KASLR feature is enabled, a kernel is placed on the memory randomly and
therefore crash cannot open a dumpfile because addresses of kernel symbols in
vmlinux are different from actual addresses. In the case of kdump, information
to get actual address is included in the vmcoreinfo, but dumpfile of sadump does
not have such a information.
These patches calculate kaslr offset and phys_base to solve this problem. The
basic idea is getting register (IDTR and CR3) from dump header, and calculate
kaslr_offset/phys_base using them.
changelog:
v2:
- Remove virsh-dump part
- Change get_vec0_addr style
- Some tiny fixes
v1:
https://www.redhat.com/archives/crash-utility/2017-October/msg00004.html
Takao Indoh (2):
Introduce x86_64_kvtop_pagetable
Fix a KASLR problem of sadump
defs.h | 5 +
sadump.c | 458 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
sadump.h | 1 +
symbols.c | 34 +++++
x86_64.c | 26 +++-
5 files changed, 522 insertions(+), 2 deletions(-)
--
2.9.5
6 years, 8 months
[PATCH 0/3] Fix KASLR problem on virsh dump and sadump
by Takao Indoh
Hi Dave, Hatayama-san,
These patch series fix a problem that crash cannot open a dumpfile which is
captured by "virsh dump --memory-only" or sadump on KASLR enabled kernel.
When KASLR feature is enabled, a kernel is placed on the memory randomly and
therefore crash cannot open a dumpfile because addresses of kernel symbols in
vmlinux are different from actual addresses. In the case of kdump, information
to get actual address is included in the vmcoreinfo, but dumpfile of virsh dump
or sadump does not have such a information.
These patches calculate kaslr offset and phys_base to solve this problem. The
basic idea is getting register (IDTR and CR3) from dump header, and calculate
kaslr_offset/phys_base using them.
Takao Indoh (3):
Introduce x86_64_kvtop_pagetable
Fix a KASLR problem of virsh dump
Fix a KASLR problem of sadump
defs.h | 11 ++
netdump.c | 505 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
netdump.h | 1 +
sadump.c | 60 +++++++-
sadump.h | 4 +
symbols.c | 38 +++++
x86_64.c | 35 ++++-
7 files changed, 652 insertions(+), 2 deletions(-)
--
2.9.5
6 years, 8 months