8:59 p.m.
There are a few failing cases observed on v6.14-rc kernel. This patchset
will fix these.
For the NO.1 patch, Anderson used "vtop" cmd as the test case [1], which I
cannot reproduce because I didn't find a suitable value for vtop to
trigger the failing. So I switched to "files" cmd.
[1]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01356.html
Tao Liu (3):
Fix the failing of cmd "files" for v6.14-rc1 kernel
Fix the failing of cmd "runq -g" for v6.14-rc1 kernel
Sort the symtable at the end of store_symbols()
filesys.c | 3 +++
symbols.c | 3 +++
task.c | 3 +++
3 files changed, 9 insertions(+)
--
2.47.0
8:59 p.m.
New subject: [PATCH 1/3] Fix the failing of cmd "files" for v6.14-rc1 kernel
Kernel commit [1] renamed "unsigned char d_iname" into "union
shortname_store
d_shortname", the same change should be integrated into crash.
Without the patch:
crash> files
files: invalid structure member offset: dentry_d_iname
FILE: filesys.c LINE: 3243 FUNCTION: get_pathname_component()
[./crash] error trace: 55e532 => 55ea57 => 5f1f31 => 5f1eb3
PID: 1490 TASK: ffff8dd00c4c2900 CPU: 0 COMMAND: "bash"
5f1eb3: OFFSET_verify.part.40+51
5f1f31: OFFSET_verify+49
55ea57: get_pathname_component+69
55e532: get_pathname+636
files: invalid structure member offset: dentry_d_iname
FILE: filesys.c LINE: 3243 FUNCTION: get_pathname_component()
[1]: https://github.com/torvalds/linux/commit/58cf9c383c5c686668082f83f7e0f3e0...
Signed-off-by: Tao Liu <ltao(a)redhat.com>
Reported-by: Anderson Nascimento <andersonc0d3(a)gmail.com>
---
filesys.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/filesys.c b/filesys.c
index 406ebb2..8d13807 100644
--- a/filesys.c
+++ b/filesys.c
@@ -2051,6 +2051,9 @@ vfs_init(void)
MEMBER_OFFSET_INIT(dentry_d_covers, "dentry", "d_covers");
MEMBER_OFFSET_INIT(dentry_d_name, "dentry", "d_name");
MEMBER_OFFSET_INIT(dentry_d_iname, "dentry", "d_iname");
+ if (INVALID_MEMBER(dentry_d_iname)) {
+ MEMBER_OFFSET_INIT(dentry_d_iname, "dentry", "d_shortname");
+ }
MEMBER_OFFSET_INIT(dentry_d_sb, "dentry", "d_sb");
MEMBER_OFFSET_INIT(inode_i_mode, "inode", "i_mode");
MEMBER_OFFSET_INIT(inode_i_op, "inode", "i_op");
--
2.47.0
8:59 p.m.
New subject: [PATCH 2/3] Fix the failing of cmd "runq -g" for v6.14-rc1 kernel
Kernel commit [1] renamed cfs_rq.h_nr_running into cfs_rq.h_nr_queued.
Without the patch:
crash> runq -g
...
runq: invalid structure member offset: cfs_rq_nr_running
FILE: task.c LINE: 9480 FUNCTION: dump_tasks_in_lower_dequeued_cfs_rq()
[./crash] error trace: 580934 => 580090 => 5f1f31 => 5f1eb3
5f1eb3: OFFSET_verify.part.40+51
5f1f31: OFFSET_verify+49
580090: dump_tasks_in_lower_dequeued_cfs_rq+444
580934: dump_tasks_in_task_group_cfs_rq+1229
runq: invalid structure member offset: cfs_rq_nr_running
FILE: task.c LINE: 9480 FUNCTION: dump_tasks_in_lower_dequeued_cfs_rq()
[1]: https://github.com/torvalds/linux/commit/7b8a702d943827130cc00ae36075eff5...
Signed-off-by: Tao Liu <ltao(a)redhat.com>
Reported-by: Anderson Nascimento <andersonc0d3(a)gmail.com>
---
task.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/task.c b/task.c
index 869f584..4e3b71f 100644
--- a/task.c
+++ b/task.c
@@ -9739,6 +9739,9 @@ cfs_rq_offset_init(void)
ASSIGN_OFFSET(cfs_rq_rb_leftmost) = OFFSET(cfs_rq_tasks_timeline) +
MEMBER_OFFSET("rb_root_cached", "rb_leftmost");
MEMBER_OFFSET_INIT(cfs_rq_nr_running, "cfs_rq", "nr_running");
+ if (INVALID_MEMBER(cfs_rq_nr_running)) {
+ MEMBER_OFFSET_INIT(cfs_rq_nr_running, "cfs_rq", "nr_queued");
+ }
MEMBER_OFFSET_INIT(cfs_rq_curr, "cfs_rq", "curr");
MEMBER_OFFSET_INIT(rt_rq_active, "rt_rq", "active");
MEMBER_OFFSET_INIT(task_struct_run_list, "task_struct",
--
2.47.0
8:59 p.m.
New subject: [PATCH 3/3] Sort the symtable at the end of store_symbols()
The st->symtable might be unsorted after store_symbols(), which is
unexpected. According to the code comment of store_symbols(), the st->
symtable should be increasing numerical order sorted, which should be
done by gnu_qsort(). The reason for unsuccessful sort is unclear, because
I didn't figure out the details of (non_)numeric_forward/gnu_sort. Anyway
this can be fixed by given another sort at the end of store_symbols().
Without the patch:
crash> sym schedule
ffffffff973ffb30 (T) schedule /root/linux-6.14-rc3/kernel/sched/core.c: 6848
crash> sym 0xffffffff973ffb30
sym: invalid address: 0xffffffff973ffb30
With the patch:
crash> sym schedule
ffffffff973ffb30 (T) schedule /root/linux-6.14-rc3/kernel/sched/core.c: 6848
crash> sym 0xffffffff973ffb30
ffffffff973ffb30 (T) schedule /root/linux-6.14-rc3/kernel/sched/core.c: 6848
The root cause for the above error, is crash fail to determine
if 0xffffffff973ffb30 is within kernel range by in_ksymbol_range(),
since the st->symtable is not sorted and the kernel start/end addrs
are incorrect.
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
symbols.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/symbols.c b/symbols.c
index 6385d02..4e58fc2 100644
--- a/symbols.c
+++ b/symbols.c
@@ -833,6 +833,9 @@ store_symbols(bfd *abfd, int dynamic, void *minisyms, long symcount,
namespace_ctl(NAMESPACE_COMPLETE, &st->kernel_namespace,
st->symtable, st->symend);
+
+ qsort(st->symtable, st->symcnt, sizeof(struct syment),
+ compare_syms);
}
/*
--
2.47.0
63
days inactive
63
days old
devel@lists.crash-utility.osci.io
3 comments
1 participants
participants (1)
-
Tao Liu