Re: [Crash-utility] [PATCH] filesys.c: add debian vmlinux loc to default search dirs
by lijiang
Hi, Chunguang
Thank you for the improvement.
On Thu, Aug 25, 2022 at 2:52 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Thu, 25 Aug 2022 12:07:20 +0800
> From: brookxu <brookxu.cn(a)gmail.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH] filesys.c: add debian vmlinux loc to
> default search dirs
> Message-ID: <20220825040720.108590-1-brookxu.cn(a)gmail.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> From: "Chunguang.Xu" <chunguang.xu(a)shopee.com>
>
> Now crash cannnot found debian/ubuntu kernel vmlinux, we need
> to explicitly specify the path to vmlinux. Try to add the debian
> vmlinux location to default search dirs.
>
> Signed-off-by: Chunguang Xu <chunguang.xu(a)shopee.com>
> ---
> filesys.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/filesys.c b/filesys.c
> index a863f04..c2ea78d 100644
> --- a/filesys.c
> +++ b/filesys.c
> @@ -319,7 +319,7 @@ match_proc_version(void)
>
> #define CREATE 1
> #define DESTROY 0
> -#define DEFAULT_SEARCHDIRS 5
> +#define DEFAULT_SEARCHDIRS 6
>
Given that the remote.c module is basically deprecated, this change should
be fine for now. So: Ack.
Thanks.
Lianbo
> #define EXTRA_SEARCHDIRS 5
>
> static char **
> @@ -336,6 +336,7 @@ build_searchdirs(int create, int *preferred)
> "/boot/",
> "/boot/efi/redhat",
> "/boot/efi/EFI/redhat",
> + "/usr/lib/debug/boot/",
> "/",
> NULL
> };
> --
> 2.25.1
>
1 year, 10 months
[PATCH v2] Fix kmem failing to print task context when address is vmalloced stack
by Tao Liu
When kernel enabled CONFIG_VMAP_STACK, stack can be allocated to
vmalloced area. Currently crash didn't handle the case, as a result,
kmem will not print the task context as expected. This patch fix the
bug by checking if the address is a vmalloced stack first.
Before:
crash> kmem ffffb7efce9bbe28
VMAP_AREA VM_STRUCT ADDRESS RANGE SIZE
ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000 20480
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffdd28220dc000 1883700000 0 0 1 50000000000000
After:
crash> kmem ffffb7efce9bbe28
PID: 847
COMMAND: "khungtaskd"
TASK: ffff94f8038f4000 [THREAD_INFO: ffff94f8038f4000]
CPU: 72
STATE: TASK_RUNNING (PANIC)
VMAP_AREA VM_STRUCT ADDRESS RANGE SIZE
ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000 20480
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffdd28220dc000 1883700000 0 0 1 50000000000000
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
v1 -> v2: 1) Remove goto to print task context and vmlist.
2) Update commit log to show the change.
---
memory.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/memory.c b/memory.c
index 7339f0c..9ab5781 100644
--- a/memory.c
+++ b/memory.c
@@ -13477,6 +13477,10 @@ kmem_search(struct meminfo *mi)
* Check for a valid mapped address.
*/
if ((mi->memtype == KVADDR) && IS_VMALLOC_ADDR(mi->spec_addr)) {
+ if ((task = stkptr_to_task(vaddr)) && (tc = task_to_context(task))) {
+ show_context(tc);
+ fprintf(fp, "\n");
+ }
if (kvtop(NULL, mi->spec_addr, &paddr, 0)) {
mi->flags = orig_flags | VMLIST_VERIFY;
dump_vmlist(mi);
--
2.33.1
1 year, 10 months
Re: [Crash-utility] [PATCH v2] Add ending identifier for union when parsing task structure
by lijiang
On Mon, Aug 29, 2022 at 3:21 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Mon, 29 Aug 2022 07:15:15 +0000
> From: HAGIO KAZUHITO(?????) <k-hagio-ab(a)nec.com>
> To: "Discussion list for crash utility usage, maintenance and
> development" <crash-utility(a)redhat.com>, Tao Liu <ltao(a)redhat.com>
> Subject: Re: [Crash-utility] [PATCH v2] Add ending identifier for
> union when parsing task structure
> Message-ID: <b5f22630-9649-20a2-6233-f229f76353dc(a)nec.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 2022/08/25 15:39, Tao Liu wrote:
> > Previously, the start and end identifier for union is " {\n"
> > and " }, \n". However the end identifier is not always as
> > expected. " },\n" can also be the end identifier. As a result,
> > variable "randomized" is in incorrect state after union, and
> > fails to identify the later struct members. For example, we can
> > reproduce the issue as follows:
> >
> > crash> task
> > PID: 847 TASK: ffff94f8038f4000 CPU: 72 COMMAND:
> "khungtaskd"
> > struct task_struct {
> > thread_info = {
> > flags = 2148024320,
> > status = 0,
> > preempt_lazy_count = 0
> > },
> > {
> > <the union>
> > },
> > ...
> > wake_entry = {
> > next = 0x0
> > },
> > ...
> >
> > Before patch:
> >
> > crash> task -R wake_entry
> > PID: 847 TASK: ffff94f8038f4000 CPU: 72 COMMAND:
> "khungtaskd"
> >
> > After patch:
> >
> > crash> task -R wake_entry
> > PID: 847 TASK: ffff94f8038f4000 CPU: 72 COMMAND:
> "khungtaskd"
> > wake_entry = {
> > next = 0x0
> > },
> >
> > Signed-off-by: Tao Liu <ltao(a)redhat.com>
> > ---
> >
> > v1 -> v2: Rewrite the commit log.
>
> Thanks for the update.
>
> I will add "with gdb-10.2" to the commit log when applying.
>
>
This is indeed a specific gdb-10.2 issue. They have different output styles
between gdb-7.6 and gdb-10.2.
> Acked-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
>
> Thanks,
> Kazu
>
>
> >
> > ---
> > task.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/task.c b/task.c
> > index 071c787..db2abc8 100644
> > --- a/task.c
> > +++ b/task.c
> > @@ -3436,7 +3436,8 @@ parse_task_thread(int argcnt, char *arglist[],
> struct task_context *tc) {
> > while (fgets(buf, BUFSIZE, pc->tmpfile)) {
> > if (STREQ(buf, " {\n"))
> > randomized = TRUE;
> > - else if (randomized && STREQ(buf, " }, \n"))
> > + else if (randomized &&
> > + (STREQ(buf, " }, \n") || STREQ(buf, " },\n")))
>
This change looks good, and the test is ok. So for the v2: Ack.
Thanks.
Lianbo
> randomized = FALSE;
> >
> > if (strlen(lookfor2)) {
>
1 year, 10 months
[PATCH v3 1/2] Let gdb get kernel module symbols info from crash
by Tao Liu
Gdb will try to resolve an address to its corresponding symbol name such as
when printing a structure. It works fine for kernel symbols, because gdb can
find them through vmlinux. However as for kernel modules symbols, crash
resolves them by dig into "struct module", which gdb don't know. As a
results, gdb fails to translate an kernel modules address to it's symbolic
name. For example we can reproduce the issue as follows.
crash> timer
....
4331308176 336 ffff94ea24240860 ffffffffc03762c0 <estimation_timer>
....
crash> sym 0xffffffffc03762c0
ffffffffc03762c0 (t) estimation_timer [ip_vs]
Before patch:
crash> timer_list ffff94ea24240860
struct timer_list {
....
function = 0xffffffffc03762c0,
....
}
After patch:
crash> timer_list ffff94ea24240860
struct timer_list {
....
function = 0xffffffffc03762c0 <estimation_timer>,
....
}
In this patch, we add an interface for gdb, when gdb trying to build kernel
module's address symbolic, the info can be get from crash.
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
v1 -> v2: Append the modification hunk at the end of gdb-10.2.patch
v2 -> v3: Add printcmd.c to "tar xvzmf"
---
defs.h | 2 ++
gdb-10.2.patch | 35 +++++++++++++++++++++++++++++++++++
gdb_interface.c | 12 ++++++++++++
3 files changed, 49 insertions(+)
diff --git a/defs.h b/defs.h
index 9d6d891..afdcf6c 100644
--- a/defs.h
+++ b/defs.h
@@ -4874,6 +4874,7 @@ extern "C" int patch_kernel_symbol(struct gnu_request *);
struct syment *symbol_search(char *);
int gdb_line_number_callback(ulong, ulong, ulong);
int gdb_print_callback(ulong);
+char *gdb_lookup_module_symbol(ulong, ulong *);
extern "C" int same_file(char *, char *);
#endif
@@ -7284,6 +7285,7 @@ int gdb_pass_through(char *, FILE *, ulong);
int gdb_readmem_callback(ulong, void *, int, int);
int gdb_line_number_callback(ulong, ulong, ulong);
int gdb_print_callback(ulong);
+char *gdb_lookup_module_symbol(ulong, ulong *);
void gdb_error_hook(void);
void restore_gdb_sanity(void);
int is_gdb_command(int, ulong);
diff --git a/gdb-10.2.patch b/gdb-10.2.patch
index f0034ed..642cd6a 100644
--- a/gdb-10.2.patch
+++ b/gdb-10.2.patch
@@ -9,6 +9,7 @@
# to all subsequent patch applications.
tar xvzmf gdb-10.2.tar.gz \
+ gdb-10.2/gdb/printcmd.c \
gdb-10.2/gdb/symfile.c \
gdb-10.2/gdb/Makefile.in
@@ -1661,3 +1662,37 @@ exit 0
+ return name_copy ? std::string (name_copy) : std::string ();
}
#endif
+
+--- gdb-10.2/gdb/printcmd.c.orig
++++ gdb-10.2/gdb/printcmd.c
+@@ -576,6 +576,10 @@ print_address_symbolic (struct gdbarch *gdbarch, CORE_ADDR addr,
+
+ /* See valprint.h. */
+
++#ifdef CRASH_MERGE
++extern "C" char *gdb_lookup_module_symbol(unsigned long, unsigned long *);
++#endif
++
+ int
+ build_address_symbolic (struct gdbarch *gdbarch,
+ CORE_ADDR addr, /* IN */
+@@ -682,7 +686,19 @@ build_address_symbolic (struct gdbarch *gdbarch,
+ }
+ }
+ if (symbol == NULL && msymbol.minsym == NULL)
++#ifdef CRASH_MERGE
++ {
++ char *name_ptr = gdb_lookup_module_symbol(addr, (unsigned long *)offset);
++ if (name_ptr) {
++ *name = name_ptr;
++ return 0;
++ } else {
++ return 1;
++ }
++ }
++#else
+ return 1;
++#endif
+
+ /* If the nearest symbol is too far away, don't print anything symbolic. */
+
diff --git a/gdb_interface.c b/gdb_interface.c
index 3a7fcc9..b14319c 100644
--- a/gdb_interface.c
+++ b/gdb_interface.c
@@ -935,6 +935,18 @@ gdb_print_callback(ulong addr)
return IS_KVADDR(addr);
}
+char *
+gdb_lookup_module_symbol(ulong addr, ulong *offset)
+{
+ struct syment *sp;
+
+ if ((sp = value_search_module(addr, offset))) {
+ return sp->name;
+ } else {
+ return NULL;
+ }
+}
+
/*
* Used by gdb_interface() to catch gdb-related errors, if desired.
*/
--
2.33.1
1 year, 10 months
Re: [Crash-utility] [PATCH v3 1/2] Let gdb get kernel module symbols info from crash
by lijiang
Hi, Tao
Thank you for the update.
On Wed, Aug 31, 2022 at 11:58 AM <crash-utility-request(a)redhat.com> wrote:
> Date: Wed, 31 Aug 2022 11:54:13 +0800
> From: Tao Liu <ltao(a)redhat.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH v3 1/2] Let gdb get kernel module
> symbols info from crash
> Message-ID: <20220831035413.10831-1-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> Gdb will try to resolve an address to its corresponding symbol name such as
> when printing a structure. It works fine for kernel symbols, because gdb
> can
> find them through vmlinux. However as for kernel modules symbols, crash
> resolves them by dig into "struct module", which gdb don't know. As a
> results, gdb fails to translate an kernel modules address to it's symbolic
> name. For example we can reproduce the issue as follows.
>
> crash> timer
> ....
> 4331308176 336 ffff94ea24240860 ffffffffc03762c0
> <estimation_timer>
> ....
> crash> sym 0xffffffffc03762c0
> ffffffffc03762c0 (t) estimation_timer [ip_vs]
>
> Before patch:
> crash> timer_list ffff94ea24240860
> struct timer_list {
> ....
> function = 0xffffffffc03762c0,
> ....
> }
>
> After patch:
> crash> timer_list ffff94ea24240860
> struct timer_list {
> ....
> function = 0xffffffffc03762c0 <estimation_timer>,
> ....
> }
>
> In this patch, we add an interface for gdb, when gdb trying to build kernel
> module's address symbolic, the info can be get from crash.
>
> Signed-off-by: Tao Liu <ltao(a)redhat.com>
> ---
> v1 -> v2: Append the modification hunk at the end of gdb-10.2.patch
> v2 -> v3: Add printcmd.c to "tar xvzmf"
>
For the v3 patchset: Ack.
Thanks.
Lianbo
---
> defs.h | 2 ++
> gdb-10.2.patch | 35 +++++++++++++++++++++++++++++++++++
> gdb_interface.c | 12 ++++++++++++
> 3 files changed, 49 insertions(+)
>
> diff --git a/defs.h b/defs.h
> index 9d6d891..afdcf6c 100644
> --- a/defs.h
> +++ b/defs.h
> @@ -4874,6 +4874,7 @@ extern "C" int patch_kernel_symbol(struct
> gnu_request *);
> struct syment *symbol_search(char *);
> int gdb_line_number_callback(ulong, ulong, ulong);
> int gdb_print_callback(ulong);
> +char *gdb_lookup_module_symbol(ulong, ulong *);
> extern "C" int same_file(char *, char *);
> #endif
>
> @@ -7284,6 +7285,7 @@ int gdb_pass_through(char *, FILE *, ulong);
> int gdb_readmem_callback(ulong, void *, int, int);
> int gdb_line_number_callback(ulong, ulong, ulong);
> int gdb_print_callback(ulong);
> +char *gdb_lookup_module_symbol(ulong, ulong *);
> void gdb_error_hook(void);
> void restore_gdb_sanity(void);
> int is_gdb_command(int, ulong);
> diff --git a/gdb-10.2.patch b/gdb-10.2.patch
> index f0034ed..642cd6a 100644
> --- a/gdb-10.2.patch
> +++ b/gdb-10.2.patch
> @@ -9,6 +9,7 @@
> # to all subsequent patch applications.
>
> tar xvzmf gdb-10.2.tar.gz \
> + gdb-10.2/gdb/printcmd.c \
> gdb-10.2/gdb/symfile.c \
> gdb-10.2/gdb/Makefile.in
>
> @@ -1661,3 +1662,37 @@ exit 0
> + return name_copy ? std::string (name_copy) : std::string ();
> }
> #endif
> +
> +--- gdb-10.2/gdb/printcmd.c.orig
> ++++ gdb-10.2/gdb/printcmd.c
> +@@ -576,6 +576,10 @@ print_address_symbolic (struct gdbarch *gdbarch,
> CORE_ADDR addr,
> +
> + /* See valprint.h. */
> +
> ++#ifdef CRASH_MERGE
> ++extern "C" char *gdb_lookup_module_symbol(unsigned long, unsigned long
> *);
> ++#endif
> ++
> + int
> + build_address_symbolic (struct gdbarch *gdbarch,
> + CORE_ADDR addr, /* IN */
> +@@ -682,7 +686,19 @@ build_address_symbolic (struct gdbarch *gdbarch,
> + }
> + }
> + if (symbol == NULL && msymbol.minsym == NULL)
> ++#ifdef CRASH_MERGE
> ++ {
> ++ char *name_ptr = gdb_lookup_module_symbol(addr, (unsigned long
> *)offset);
> ++ if (name_ptr) {
> ++ *name = name_ptr;
> ++ return 0;
> ++ } else {
> ++ return 1;
> ++ }
> ++ }
> ++#else
> + return 1;
> ++#endif
> +
> + /* If the nearest symbol is too far away, don't print anything
> symbolic. */
> +
> diff --git a/gdb_interface.c b/gdb_interface.c
> index 3a7fcc9..b14319c 100644
> --- a/gdb_interface.c
> +++ b/gdb_interface.c
> @@ -935,6 +935,18 @@ gdb_print_callback(ulong addr)
> return IS_KVADDR(addr);
> }
>
> +char *
> +gdb_lookup_module_symbol(ulong addr, ulong *offset)
> +{
> + struct syment *sp;
> +
> + if ((sp = value_search_module(addr, offset))) {
> + return sp->name;
> + } else {
> + return NULL;
> + }
> +}
> +
> /*
> * Used by gdb_interface() to catch gdb-related errors, if desired.
> */
> --
> 2.33.1
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://listman.redhat.com/mailman/listinfo/crash-utility
>
>
> ------------------------------
>
> End of Crash-utility Digest, Vol 203, Issue 48
> **********************************************
>
>
1 year, 10 months