[PATCH v2] Fix "vm -M" option to properly deal with an invalid argument
by Lianbo Jiang
The help/man page of the "vm" command suggests that the "-M" option
accepts the mm_struct address as a valid argument. However, the "vm
-M" option can accept an invalid argument and always prints the virtual
memory data of the current task by default. For example:
Without the patch:
crash> vm -M 0xh
PID: 92960 TASK: ffff99157976cc80 CPU: 0 COMMAND: "crash"
MM PGD RSS TOTAL_VM
ffff991573bfdf00 ffff9915857f2000 449020k 2427076k
VMA START END FLAGS FILE
ffff99158718d1c8 400000 4de000 8000071 /home/crash/crash
...
The main reasons for this are:
[1] the htoll() can not recognize if the given address is a valid kernel
virtual address, only converts a string to a hexadecimal unsigned long
long value, such as "0xdeadbeef",etc
[2] for the htoll(), the string may begin with a white space or include
a "0x", "0X", "h" prefix, so the "0xh" is a special value to htoll(),
for more details, please refer to the htoll() in tools.c
ulonglong
htoll(char *s, int flags, int *errptr)
{
...
for (n = i = 0; s[i] != 0; i++) {
...
case 'x':
case 'X':
case 'h':
continue;
}
...
[3] when the getopt() is called repeatedly, the variable optind is the
index of the next element to be processed in argv, therefore, for the
"vm -M 0xh", after calling the getopt(), the optind is 3, the args[3] is
definitely null, eventualy it mistakenly enters the following code path:
void
cmd_vm(void)
{
...
if (!args[optind]) {
if (!ref)
print_task_header(fp, CURRENT_CONTEXT(), 0);
vm_area_dump(CURRENT_TASK(), flag, single_vma, ref);
return;
}
...
Let's handle such cases, add documentation and give an error as expected.
With the patch:
crash> vm -M 0xh
vm: invalid mm_struct address: 0xh
Reported-by: Buland Kumar Singh <bsingh(a)redhat.com>
Signed-off-by: Lianbo Jiang <lijiang(a)redhat.com>
---
help.c | 1 +
memory.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/help.c b/help.c
index 56a9d8274525..3006ac9180ae 100644
--- a/help.c
+++ b/help.c
@@ -4695,6 +4695,7 @@ char *help_vm[] = {
" However, if the address can be determined from the kernel stack,",
" it can be entered manually in order to try to resurrect the",
" virtual memory data of the task.",
+" NOTE: this option is only used when the task_struct's mm is NULL.",
" -R reference search for references to this number or filename.",
" -m dump the mm_struct associated with the task.",
" -v dump all of the vm_area_structs associated with the task.",
diff --git a/memory.c b/memory.c
index 592a5ef49d50..0568f18eb9b7 100644
--- a/memory.c
+++ b/memory.c
@@ -3559,6 +3559,8 @@ cmd_vm(void)
case 'M':
pc->curcmd_private = htoll(optarg, FAULT_ON_ERROR, NULL);
pc->curcmd_flags |= MM_STRUCT_FORCE;
+ if (!IS_KVADDR(pc->curcmd_private))
+ error(FATAL, "invalid mm_struct address: %s\n", optarg);
break;
case 'f':
--
2.37.1
1 year, 9 months
[PATCH] Fix "vm -M" option to properly display virtual memory data of the task
by Lianbo Jiang
The help/man page of the "vm" command suggests that the "-M" option
accepts the mm_struct address as a valid argument. However, the "vm
-M" option always prints the virtual memory data of the current
task, regardless of its arguments.
Without the patch:
crash> ps |grep sshd
1159 1 19 ffff9915858a9980 IN 0.1 15820 9020 sshd
47236 1159 21 ffff991572b40000 IN 0.1 18916 11116 sshd
...
crash> vm -M ffff991572b40000
PID: 49647 TASK: ffff991580b39980 CPU: 10 COMMAND: "crash"
...
With the patch:
crash> vm -M ffff991572b40000
PID: 47236 TASK: ffff991572b40000 CPU: 21 COMMAND: "sshd"
...
Reported-by: Buland Kumar Singh <bsingh(a)redhat.com>
Signed-off-by: Lianbo Jiang <lijiang(a)redhat.com>
---
memory.c | 39 +++++++++++++++++++++------------------
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/memory.c b/memory.c
index 592a5ef49d50..c9861dd6d0fb 100644
--- a/memory.c
+++ b/memory.c
@@ -3640,6 +3640,7 @@ cmd_vm(void)
else if (radix == 16)
flag |= PRINT_RADIX_16;
+ optind = 1;
if (!args[optind]) {
if (!ref)
print_task_header(fp, CURRENT_CONTEXT(), 0);
@@ -3650,26 +3651,28 @@ cmd_vm(void)
subsequent = 0;
while (args[optind]) {
- switch (str_to_context(args[optind], &value, &tc))
- {
- case STR_PID:
- for (tc = pid_to_context(value); tc; tc = tc->tc_next) {
- if (!ref)
- print_task_header(fp, tc, subsequent++);
- vm_area_dump(tc->task, flag, single_vma, ref);
- }
- break;
+ if (IS_A_NUMBER(args[optind])) {
+ switch (str_to_context(args[optind], &value, &tc))
+ {
+ case STR_PID:
+ for (tc = pid_to_context(value); tc; tc = tc->tc_next) {
+ if (!ref)
+ print_task_header(fp, tc, subsequent++);
+ vm_area_dump(tc->task, flag, single_vma, ref);
+ }
+ break;
- case STR_TASK:
- if (!ref)
- print_task_header(fp, tc, subsequent++);
- vm_area_dump(tc->task, flag, single_vma, ref);
- break;
+ case STR_TASK:
+ if (!ref)
+ print_task_header(fp, tc, subsequent++);
+ vm_area_dump(tc->task, flag, single_vma, ref);
+ break;
- case STR_INVALID:
- error(INFO, "%sinvalid task or pid value: %s\n",
- subsequent++ ? "\n" : "", args[optind]);
- break;
+ case STR_INVALID:
+ error(INFO, "%sinvalid task or pid value: %s\n",
+ subsequent++ ? "\n" : "", args[optind]);
+ break;
+ }
}
optind++;
--
2.37.1
1 year, 9 months
Re: [Crash-utility] [PATCH v2 0/3] xen: several fixes for newer Xen versions
by lijiang
On Wed, Mar 15, 2023 at 7:19 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Wed, 15 Mar 2023 12:18:47 +0100
> From: Juergen Gross <jgross(a)suse.com>
> To: crash-utility(a)redhat.com
> Cc: Juergen Gross <jgross(a)suse.com>
> Subject: [Crash-utility] [PATCH v2 0/3] xen: several fixes for newer
> Xen versions
> Message-ID: <20230315111850.21395-1-jgross(a)suse.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> When trying to look into a vmcore in Xen mode which was obtained from
> a machine running Xen 4.16, I realized that crash wasn't able to handle
> that.
>
> Looking into the issue I found that crash is lacking several adaptions
> to newer Xen versions (at least 4.13 onwards).
>
> There might be more missing, but it is now at least possible to do
> _some_ debugging.
>
> Changes in V2:
> - addressed comments
>
>
Thank you for the update, Juergen.
For the v2: Ack(with the warning fix).
Thanks.
Lianbo
> Juergen Gross (3):
> xen: fix stacksize
> xen: get stack address via stack_base array if available
> xen: adjust to new scheduler structures
>
> x86_64.c | 2 +-
> xen_hyper.c | 119 +++++++++++++++++++++++++---------------
> xen_hyper_defs.h | 4 +-
> xen_hyper_dump_tables.c | 4 ++
> 4 files changed, 83 insertions(+), 46 deletions(-)
>
> --
> 2.35.3
>
1 year, 9 months
[PATCH v2 0/3] xen: several fixes for newer Xen versions
by Juergen Gross
When trying to look into a vmcore in Xen mode which was obtained from
a machine running Xen 4.16, I realized that crash wasn't able to handle
that.
Looking into the issue I found that crash is lacking several adaptions
to newer Xen versions (at least 4.13 onwards).
There might be more missing, but it is now at least possible to do
_some_ debugging.
Changes in V2:
- addressed comments
Juergen Gross (3):
xen: fix stacksize
xen: get stack address via stack_base array if available
xen: adjust to new scheduler structures
x86_64.c | 2 +-
xen_hyper.c | 119 +++++++++++++++++++++++++---------------
xen_hyper_defs.h | 4 +-
xen_hyper_dump_tables.c | 4 ++
4 files changed, 83 insertions(+), 46 deletions(-)
--
2.35.3
1 year, 9 months
Re: [Crash-utility] [PATCH 3/3] xen: adjust to new scheduler structures
by lijiang
On Mon, Mar 13, 2023 at 9:07 PM <crash-utility-request(a)redhat.com> wrote:
> Send Crash-utility mailing list submissions to
> Date: Mon, 13 Mar 2023 14:01:12 +0100
> From: Juergen Gross <jgross(a)suse.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH 3/3] xen: adjust to new scheduler
> structures
> Message-ID: <20230313130112.15353-4-jgross(a)suse.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> There has been a significant modification regarding scheduler data in
> the Xen hypervisor. Adapt to new structures and removed fields.
>
>
I would suggest adding the related hypervisor commit here.
> Note that this is only the bare minimum to not let crash error out when
> opening a vmcore in Xen mode with a recent Xen version.
>
> Signed-off-by: Juergen Gross <jgross(a)suse.com>
> ---
> xen_hyper.c | 67 +++++++++++++++++++++++++++++++++---------------
> xen_hyper_defs.h | 4 ++-
> 2 files changed, 49 insertions(+), 22 deletions(-)
>
> diff --git a/xen_hyper.c b/xen_hyper.c
> index 72720e2..4c884dd 100644
> --- a/xen_hyper.c
> +++ b/xen_hyper.c
> @@ -417,13 +417,21 @@ void
> xen_hyper_misc_init(void)
> {
> XEN_HYPER_STRUCT_SIZE_INIT(schedule_data, "schedule_data");
> - XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_schedule_lock,
> "schedule_data", "schedule_lock");
> - XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_curr, "schedule_data",
> "curr");
> - if (MEMBER_EXISTS("schedule_data", "idle"))
> - XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_idle,
> "schedule_data", "idle");
> - XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_sched_priv,
> "schedule_data", "sched_priv");
> - XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_s_timer,
> "schedule_data", "s_timer");
> - XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_tick, "schedule_data",
> "tick");
> + XEN_HYPER_STRUCT_SIZE_INIT(sched_resource, "sched_resource");
> + if (XEN_HYPER_VALID_SIZE(schedule_data)) {
> + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_schedule_lock,
> "schedule_data", "schedule_lock");
> + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_curr,
> "schedule_data", "curr");
> + if (MEMBER_EXISTS("schedule_data", "idle"))
> + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_idle,
> "schedule_data", "idle");
> + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_sched_priv,
> "schedule_data", "sched_priv");
> + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_s_timer,
> "schedule_data", "s_timer");
> + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_tick,
> "schedule_data", "tick");
> + } else if (XEN_HYPER_VALID_SIZE(sched_resource)) {
> + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_schedule_lock,
> "sched_resource", "schedule_lock");
> + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_curr,
> "sched_resource", "curr");
> + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_sched_priv,
> "sched_resource", "sched_priv");
> + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_s_timer,
> "sched_resource", "s_timer");
> + }
>
> XEN_HYPER_STRUCT_SIZE_INIT(scheduler, "scheduler");
> XEN_HYPER_MEMBER_OFFSET_INIT(scheduler_name, "scheduler", "name");
> @@ -467,6 +475,7 @@ xen_hyper_schedule_init(void)
> long *schedulers_buf;
> int nr_schedulers;
> struct xen_hyper_sched_context *schc;
> + long buf_size;
> char *buf;
> char opt_name_buf[XEN_HYPER_OPT_SCHED_SIZE];
> int i, cpuid, flag;
> @@ -561,28 +570,43 @@ xen_hyper_schedule_init(void)
> }
> BZERO(xhscht->sched_context_array,
> sizeof(struct xen_hyper_sched_context) *
> XEN_HYPER_MAX_CPUS());
> - buf = GETBUF(XEN_HYPER_SIZE(schedule_data));
> - if (symbol_exists("per_cpu__schedule_data")) {
> + if (symbol_exists("per_cpu__sched_res")) {
> + addr = symbol_value("per_cpu__sched_res");
> + buf_size = XEN_HYPER_SIZE(sched_resource);
> + flag = 0;
> + } else if (symbol_exists("per_cpu__schedule_data")) {
> addr = symbol_value("per_cpu__schedule_data");
> - flag = TRUE;
> + buf_size = XEN_HYPER_SIZE(schedule_data);
> + flag = 1;
> } else {
> addr = symbol_value("schedule_data");
> - flag = FALSE;
> + buf_size = XEN_HYPER_SIZE(schedule_data);
> + flag = 2;
> }
> + buf = GETBUF(buf_size);
> for_cpu_indexes(i, cpuid)
> {
> schc = &xhscht->sched_context_array[cpuid];
> if (flag) {
> - schc->schedule_data =
> - xen_hyper_per_cpu(addr, i);
> + if (flag == 1) {
> + schc->schedule_data =
> + xen_hyper_per_cpu(addr, i);
> + } else {
> + schc->schedule_data = addr +
> + XEN_HYPER_SIZE(schedule_data) * i;
> + }
> + if (!readmem(schc->schedule_data,
> + KVADDR, buf, XEN_HYPER_SIZE(schedule_data),
> + "schedule_data", RETURN_ON_ERROR)) {
> + error(FATAL, "cannot read
> schedule_data.\n");
> + }
>
As we mentioned in patch 2/3, the readmem(..., FAULT_ON_ERROR) looks better
for this case.
} else {
> - schc->schedule_data = addr +
> - XEN_HYPER_SIZE(schedule_data) * i;
> - }
> - if (!readmem(schc->schedule_data,
> - KVADDR, buf, XEN_HYPER_SIZE(schedule_data),
> - "schedule_data", RETURN_ON_ERROR)) {
> - error(FATAL, "cannot read schedule_data.\n");
> + schc->sched_resource = xen_hyper_per_cpu(addr, i);
> + if (!readmem(schc->sched_resource,
> + KVADDR, buf,
> XEN_HYPER_SIZE(sched_resource),
> + "sched_resource", RETURN_ON_ERROR)) {
> + error(FATAL, "cannot read
> sched_resource.\n");
> + }
>
Ditto.
Thanks.
Lianbo
}
> schc->cpu_id = cpuid;
> schc->curr = ULONG(buf +
> XEN_HYPER_OFFSET(schedule_data_curr));
> @@ -1599,7 +1623,8 @@ xen_hyper_store_vcpu_context(struct
> xen_hyper_vcpu_context *vcc,
> vcc->next_in_list = ULONG(vcp +
> XEN_HYPER_OFFSET(vcpu_next_in_list));
> if (XEN_HYPER_VALID_MEMBER(vcpu_sleep_tick))
> vcc->sleep_tick = ULONG(vcp +
> XEN_HYPER_OFFSET(vcpu_sleep_tick));
> - vcc->sched_priv = ULONG(vcp + XEN_HYPER_OFFSET(vcpu_sched_priv));
> + if (XEN_HYPER_VALID_MEMBER(vcpu_sched_priv))
> + vcc->sched_priv = ULONG(vcp +
> XEN_HYPER_OFFSET(vcpu_sched_priv));
> vcc->state = INT(vcp + XEN_HYPER_OFFSET(vcpu_runstate) +
> XEN_HYPER_OFFSET(vcpu_runstate_info_state));
> vcc->state_entry_time = ULONGLONG(vcp +
> diff --git a/xen_hyper_defs.h b/xen_hyper_defs.h
> index acf910a..908b470 100644
> --- a/xen_hyper_defs.h
> +++ b/xen_hyper_defs.h
> @@ -547,6 +547,7 @@ struct xen_hyper_pcpu_table {
> struct xen_hyper_sched_context {
> uint cpu_id;
> ulong schedule_data;
> + ulong sched_resource;
> ulong curr;
> ulong idle;
> ulong sched_priv;
> @@ -595,6 +596,7 @@ struct xen_hyper_size_table {
> #endif
> long note_buf_t; /* elf note v1 */
> long schedule_data;
> + long sched_resource;
> long scheduler;
> long shared_info;
> long timer;
> @@ -692,7 +694,7 @@ struct xen_hyper_offset_table {
> /* mm_struct */
> long mm_struct_pgd;
> #endif
> - /* schedule_data */
> + /* schedule_data or sched_resource */
> long schedule_data_schedule_lock;
> long schedule_data_curr;
> long schedule_data_idle;
> --
> 2.35.3
>
1 year, 9 months
Re: [Crash-utility] [PATCH 2/3] xen: get stack address via stack_base array if available
by lijiang
On Mon, Mar 13, 2023 at 9:07 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Mon, 13 Mar 2023 14:01:11 +0100
> From: Juergen Gross <jgross(a)suse.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH 2/3] xen: get stack address via
> stack_base array if available
> Message-ID: <20230313130112.15353-3-jgross(a)suse.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> Since many years now the stack address of each percpu stack is
> available via the stack_base[] array now. Use that instead of the
> indirect method via the percpu variables tss_init or tss_page,
> especially as the layout of tss_page has changed in Xen 4.16,
> resulting in the stack no longer to be found.
>
>
It should be good to add the hypervisor commit(if any) here.
> Signed-off-by: Juergen Gross <jgross(a)suse.com>
> ---
> xen_hyper.c | 50 ++++++++++++++++++++++++++++++--------------------
> 1 file changed, 30 insertions(+), 20 deletions(-)
>
> diff --git a/xen_hyper.c b/xen_hyper.c
> index 1030c0a..72720e2 100644
> --- a/xen_hyper.c
> +++ b/xen_hyper.c
> @@ -324,7 +324,7 @@ void
> xen_hyper_x86_pcpu_init(void)
> {
> ulong cpu_info;
> - ulong init_tss_base, init_tss;
> + ulong init_tss_base, init_tss, stack_base;
> ulong sp;
> struct xen_hyper_pcpu_context *pcc;
> char *buf, *bp;
> @@ -340,34 +340,44 @@ xen_hyper_x86_pcpu_init(void)
> }
> /* get physical cpu context */
> xen_hyper_alloc_pcpu_context_space(XEN_HYPER_MAX_CPUS());
> - if (symbol_exists("per_cpu__init_tss")) {
> + if (symbol_exists("stack_base")) {
> + stack_base = symbol_value("stack_base");
> + flag = 0;
> + } else if (symbol_exists("per_cpu__init_tss")) {
> init_tss_base = symbol_value("per_cpu__init_tss");
> - flag = TRUE;
> + flag = 1;
> } else if (symbol_exists("per_cpu__tss_page")) {
> init_tss_base = symbol_value("per_cpu__tss_page");
> - flag = TRUE;
> + flag = 1;
> } else {
> init_tss_base = symbol_value("init_tss");
> - flag = FALSE;
> + flag = 2;
> }
> buf = GETBUF(XEN_HYPER_SIZE(tss));
>
The buf is not used in the stack_base code path, is it possible to not call
the GETBUF() in the stack_base code path?
> for_cpu_indexes(i, cpuid)
> {
> - if (flag)
> - init_tss = xen_hyper_per_cpu(init_tss_base, cpuid);
> - else
> - init_tss = init_tss_base +
> - XEN_HYPER_SIZE(tss) * cpuid;
> - if (!readmem(init_tss, KVADDR, buf,
> - XEN_HYPER_SIZE(tss), "init_tss", RETURN_ON_ERROR))
> {
> - error(FATAL, "cannot read init_tss.\n");
> - }
> - if (machine_type("X86")) {
> - sp = ULONG(buf + XEN_HYPER_OFFSET(tss_esp0));
> - } else if (machine_type("X86_64")) {
> - sp = ULONG(buf + XEN_HYPER_OFFSET(tss_rsp0));
> - } else
> - sp = 0;
> + if (flag) {
> + if (flag == 1)
> + init_tss =
> xen_hyper_per_cpu(init_tss_base, cpuid);
> + else
> + init_tss = init_tss_base +
> + XEN_HYPER_SIZE(tss) * cpuid;
> + if (!readmem(init_tss, KVADDR, buf,
> + XEN_HYPER_SIZE(tss), "init_tss",
> RETURN_ON_ERROR)) {
> + error(FATAL, "cannot read init_tss.\n");
> + }
> + if (machine_type("X86")) {
> + sp = ULONG(buf +
> XEN_HYPER_OFFSET(tss_esp0));
> + } else if (machine_type("X86_64")) {
> + sp = ULONG(buf +
> XEN_HYPER_OFFSET(tss_rsp0));
> + } else
> + sp = 0;
> + } else {
> + if (!readmem(stack_base + sizeof(ulong) * cpuid,
> KVADDR, &sp,
> + sizeof(ulong), "stack_base",
> RETURN_ON_ERROR)) {
> + error(FATAL, "cannot read stack_base.\n");
> + }
>
The above if(!readmem()) code can be replaced with:
readmem(stack_base + sizeof(ulong) * cpuid, KVADDR, &sp, sizeof(ulong),
"stack_base", FAULT_ON_ERROR));
It looks more concise.
Thanks.
Lianbo
+ }
> cpu_info = XEN_HYPER_GET_CPU_INFO(sp);
> if (CRASHDEBUG(1)) {
> fprintf(fp, "sp=%lx, cpu_info=%lx\n", sp,
> cpu_info);
> --
> 2.35.3
>
1 year, 9 months
Re: [Crash-utility] [PATCH 1/3] xen: fix stacksize
by lijiang
Hi, Juergen
Thank you for the patchset.
The xen-related code in crash-utility has not been updated for a long time.
That somewhat relies on xen developers.
On Mon, Mar 13, 2023 at 9:07 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Mon, 13 Mar 2023 14:01:10 +0100
> From: Juergen Gross <jgross(a)suse.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH 1/3] xen: fix stacksize
> Message-ID: <20230313130112.15353-2-jgross(a)suse.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> The size of the percpu stack of Xen on x86_64 is 8 pages, not 2.
>
> While not really critical in its current usage, it should be corrected
> nevertheless.
Could you please add the related xen commit(if any) to the patch log? That
can help us quickly review patches, and easily retrace it in the future.
Thanks.
Lianbo
>
Signed-off-by: Juergen Gross <jgross(a)suse.com>
> ---
> Makefile | 14 +++++++-------
> x86_64.c | 2 +-
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/x86_64.c b/x86_64.c
> index 8e3eb89..5019c69 100644
> --- a/x86_64.c
> +++ b/x86_64.c
> @@ -8113,7 +8113,7 @@ x86_64_init_hyper(int when)
> machdep->pageshift = ffs(machdep->pagesize) - 1;
> machdep->pageoffset = machdep->pagesize - 1;
> machdep->pagemask = ~((ulonglong)machdep->pageoffset);
> - machdep->stacksize = machdep->pagesize * 2;
> + machdep->stacksize = machdep->pagesize * 8;
> if ((machdep->pgd = (char *)malloc(PAGESIZE())) == NULL)
> error(FATAL, "cannot malloc pgd space.");
> if ((machdep->pud = (char *)malloc(PAGESIZE())) == NULL)
> --
> 2.35.3
>
1 year, 9 months
[PATCH 0/3] xen: several fixes for newer Xen versions
by Juergen Gross
When trying to look into a vmcore in Xen mode which was obtained from
a machine running Xen 4.16, I realized that crash wasn't able to handle
that.
Looking into the issue I found that crash is lacking several adaptions
to newer Xen versions (at least 4.13 onwards).
There might be more missing, but it is now at least possible to do
_some_ debugging.
Juergen Gross (3):
xen: fix stacksize
xen: get stack address via stack_base array if available
xen: adjust to new scheduler structures
Makefile | 14 +++---
x86_64.c | 2 +-
xen_hyper.c | 117 ++++++++++++++++++++++++++++++-----------------
xen_hyper_defs.h | 4 +-
4 files changed, 87 insertions(+), 50 deletions(-)
--
2.35.3
1 year, 9 months
[PATCH v2] Fix "kmem -n" option to display memory blocks on Linux 6.3-rc1 and later
by HAGIO KAZUHITO(萩尾 一仁)
Kernel commit d2bf38c088e0 ("driver core: remove private pointer from
struct bus_type") removed the bus_type.p member, and the "kmem -n"
option fails with the following error before displaying memory block
information on Linux 6.3-rc1 and later kernels.
kmem: invalid structure member offset: bus_type_p
FILE: memory.c LINE: 17852 FUNCTION: init_memory_block()
Search bus_kset.list instead for subsys_private of memory subsys.
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
defs.h | 2 ++
memory.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++------
symbols.c | 2 ++
3 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/defs.h b/defs.h
index 1f2cf6e0ce01..12ad6aaa0998 100644
--- a/defs.h
+++ b/defs.h
@@ -2214,6 +2214,8 @@ struct offset_table { /* stash of commonly-used offsets */
long inet6_ifaddr_if_list;
long inet6_ifaddr_if_next;
long in6_addr_in6_u;
+ long kset_kobj;
+ long subsys_private_subsys;
};
struct size_table { /* stash of commonly-used sizes */
diff --git a/memory.c b/memory.c
index c4a6ecd18004..592a5ef49d50 100644
--- a/memory.c
+++ b/memory.c
@@ -17822,6 +17822,13 @@ static void
init_memory_block_offset(void)
{
MEMBER_OFFSET_INIT(bus_type_p, "bus_type", "p");
+ if (INVALID_MEMBER(bus_type_p)) {
+ MEMBER_OFFSET_INIT(kset_list, "kset", "list");
+ MEMBER_OFFSET_INIT(kset_kobj, "kset", "kobj");
+ MEMBER_OFFSET_INIT(kobject_name, "kobject", "name");
+ MEMBER_OFFSET_INIT(kobject_entry, "kobject", "entry");
+ MEMBER_OFFSET_INIT(subsys_private_subsys, "subsys_private", "subsys");
+ }
MEMBER_OFFSET_INIT(subsys_private_klist_devices,
"subsys_private", "klist_devices");
MEMBER_OFFSET_INIT(klist_k_list, "klist", "k_list");
@@ -17842,15 +17849,60 @@ init_memory_block_offset(void)
}
static void
-init_memory_block(struct list_data *ld, int *klistcnt, ulong **klistbuf)
+init_memory_block(int *klistcnt, ulong **klistbuf)
{
- ulong memory_subsys = symbol_value("memory_subsys");
ulong private, klist, start;
+ struct list_data list_data, *ld;
+
+ ld = &list_data;
+ private = 0;
init_memory_block_offset();
- readmem(memory_subsys + OFFSET(bus_type_p), KVADDR, &private,
- sizeof(void *), "memory_subsys.private", FAULT_ON_ERROR);
+ /*
+ * v6.3-rc1
+ * d2bf38c088e0 driver core: remove private pointer from struct bus_type
+ */
+ if (INVALID_MEMBER(bus_type_p)) {
+ int i, cnt;
+ char buf[32];
+ ulong bus_kset, list, name;
+
+ BZERO(ld, sizeof(struct list_data));
+
+ get_symbol_data("bus_kset", sizeof(ulong), &bus_kset);
+ readmem(bus_kset + OFFSET(kset_list), KVADDR, &list,
+ sizeof(ulong), "bus_kset.list", FAULT_ON_ERROR);
+
+ ld->flags |= LIST_ALLOCATE;
+ ld->start = list;
+ ld->end = bus_kset + OFFSET(kset_list);
+ ld->list_head_offset = OFFSET(kobject_entry);
+
+ cnt = do_list(ld);
+ for (i = 0; i < cnt; i++) {
+ readmem(ld->list_ptr[i] + OFFSET(kobject_name), KVADDR, &name,
+ sizeof(ulong), "kobject.name", FAULT_ON_ERROR);
+ read_string(name, buf, sizeof(buf)-1);
+ if (CRASHDEBUG(1))
+ fprintf(fp, "kobject: %lx name: %s\n", ld->list_ptr[i], buf);
+ if (STREQ(buf, "memory")) {
+ /* entry is subsys_private.subsys.kobj. See bus_to_subsys(). */
+ private = ld->list_ptr[i] - OFFSET(kset_kobj)
+ - OFFSET(subsys_private_subsys);
+ break;
+ }
+ }
+ FREEBUF(ld->list_ptr);
+ } else {
+ ulong memory_subsys = symbol_value("memory_subsys");
+ readmem(memory_subsys + OFFSET(bus_type_p), KVADDR, &private,
+ sizeof(void *), "memory_subsys.private", FAULT_ON_ERROR);
+ }
+
+ if (!private)
+ error(FATAL, "cannot determine subsys_private for memory.\n");
+
klist = private + OFFSET(subsys_private_klist_devices) +
OFFSET(klist_k_list);
BZERO(ld, sizeof(struct list_data));
@@ -17875,7 +17927,6 @@ dump_memory_blocks(int initialize)
ulong memory_block, device;
ulong *klistbuf;
int klistcnt, i;
- struct list_data list_data;
char mb_hdr[BUFSIZE];
char paddr_hdr[BUFSIZE];
char buf1[BUFSIZE];
@@ -17892,7 +17943,7 @@ dump_memory_blocks(int initialize)
if (initialize)
return;
- init_memory_block(&list_data, &klistcnt, &klistbuf);
+ init_memory_block(&klistcnt, &klistbuf);
if ((symbol_exists("memory_block_size_probed")) ||
(MEMBER_EXISTS("memory_block", "end_section_nr")))
diff --git a/symbols.c b/symbols.c
index 28846d06273c..f0721023816d 100644
--- a/symbols.c
+++ b/symbols.c
@@ -10404,6 +10404,7 @@ dump_offset_table(char *spec, ulong makestruct)
OFFSET(kobject_entry));
fprintf(fp, " kset_list: %ld\n",
OFFSET(kset_list));
+ fprintf(fp, " kset_kobj: %ld\n", OFFSET(kset_kobj));
fprintf(fp, " request_list_count: %ld\n",
OFFSET(request_list_count));
fprintf(fp, " request_cmd_flags: %ld\n",
@@ -10441,6 +10442,7 @@ dump_offset_table(char *spec, ulong makestruct)
fprintf(fp, " blk_mq_tags_rqs: %ld\n",
OFFSET(blk_mq_tags_rqs));
+ fprintf(fp, " subsys_private_subsys: %ld\n", OFFSET(subsys_private_subsys));
fprintf(fp, " subsys_private_klist_devices: %ld\n",
OFFSET(subsys_private_klist_devices));
fprintf(fp, " subsystem_kset: %ld\n",
--
2.31.1
1 year, 9 months
