AlmaLinux changes

This commit is contained in:
eabdullin 2022-04-08 12:14:47 +03:00
commit 53d3e2f22e
11 changed files with 751 additions and 2 deletions

View File

@ -0,0 +1,59 @@
From 70a27ae9f2b45d6dba56ee4240b6adf79c544ee1 Mon Sep 17 00:00:00 2001
From: Lianbo Jiang <lijiang@redhat.com>
Date: Thu, 6 Jan 2022 22:34:26 +0800
Subject: [PATCH 01/10] Fix for "timer -r" option to display all the per-CPU
clocks
Currently, the hrtimer_max_clock_bases is hard-coded to 3, which
makes that crash only prints three clocks, and the rest of clocks
are not displayed.
Without the patch:
crash> timer -r -C 11
CPU: 11 HRTIMER_CPU_BASE: ffff9a775f95ee00
CLOCK: 0 HRTIMER_CLOCK_BASE: ffff9a775f95ee80 [ktime_get]
(empty)
CLOCK: 1 HRTIMER_CLOCK_BASE: ffff9a775f95ef00 [ktime_get_real]
(empty)
CLOCK: 2 HRTIMER_CLOCK_BASE: ffff9a775f95ef80 [ktime_get_boottime]
(empty)
With the patch:
crash> timer -r -C 11
CPU: 11 HRTIMER_CPU_BASE: ffff9a775f95ee00
CLOCK: 0 HRTIMER_CLOCK_BASE: ffff9a775f95ee80 [ktime_get]
(empty)
CLOCK: 1 HRTIMER_CLOCK_BASE: ffff9a775f95ef00 [ktime_get_real]
(empty)
CLOCK: 2 HRTIMER_CLOCK_BASE: ffff9a775f95ef80 [ktime_get_boottime]
(empty)
...
CLOCK: 7 HRTIMER_CLOCK_BASE: ffff9a775f95f200 [ktime_get_clocktai]
(empty)
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
kernel.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel.c b/kernel.c
index 37b7af74ed2e..36c57ed501ad 100644
--- a/kernel.c
+++ b/kernel.c
@@ -7675,7 +7675,8 @@ dump_hrtimer_data(const ulong *cpus)
if (VALID_STRUCT(hrtimer_clock_base)) {
hrtimer_max_clock_bases = 2;
if (symbol_exists("ktime_get_boottime"))
- hrtimer_max_clock_bases = 3;
+ hrtimer_max_clock_bases = MEMBER_SIZE("hrtimer_cpu_base", "clock_base") /
+ SIZE(hrtimer_clock_base);
} else if (VALID_STRUCT(hrtimer_base)) {
max_hrtimer_bases = 2;
} else
--
2.20.1

View File

@ -0,0 +1,69 @@
From 0d3d80b47d69c5d303b48c0463a026e60633cae2 Mon Sep 17 00:00:00 2001
From: Lianbo Jiang <lijiang@redhat.com>
Date: Thu, 6 Jan 2022 12:01:17 +0800
Subject: [PATCH 02/10] Fix for "bt -v" option to display the stack-end address
correctly
The "bt -v" command prints incorrect stack-end address when the
"CONFIG_THREAD_INFO_IN_TASK=y" is enabled in kernel, the "bt -v"
command output shows that the value stored at 0xffff8dee0312c198
is 0xffffffffc076400a, however, the value stored actually at
0xffff8dee0312c198 is NULL(0x0000000000000000), the stack-end
address is incorrect.
Without the patch:
crash> bt -v
PID: 28642 TASK: ffff8dee0312c180 CPU: 0 COMMAND: "insmod"
possible stack overflow: ffff8dee0312c198: ffffffffc076400a != STACK_END_MAGIC
^^^^^^^^^^^^^^^^
crash> rd 0xffff8dee0312c198
ffff8dee0312c198: 0000000000000000 ........
^^^^^^^^^^^^^^^^
With the patch:
crash> bt -v
PID: 28642 TASK: ffff8dee0312c180 CPU: 0 COMMAND: "insmod"
possible stack overflow: ffff991340bc0000: ffffffffc076400a != STACK_END_MAGIC
crash> rd 0xffff991340bc0000
ffff991340bc0000: ffffffffc076400a .@v.....
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
task.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/task.c b/task.c
index bb6a5da8ad33..b5ddc88e0acb 100644
--- a/task.c
+++ b/task.c
@@ -11202,7 +11202,7 @@ check_stack_overflow(void)
{
int i, overflow, cpu_size, cpu, total;
char buf[BUFSIZE];
- ulong magic, task, stackbase;
+ ulong magic, task, stackbase, location;
struct task_context *tc;
if (!tt->stack_end_magic &&
@@ -11286,9 +11286,15 @@ check_stack_end_magic:
if (magic != STACK_END_MAGIC) {
if (!overflow)
print_task_header(fp, tc, 0);
+
+ if (tt->flags & THREAD_INFO_IN_TASK)
+ location = task_to_stackbase(tc->task);
+ else
+ location = tc->thread_info + SIZE(thread_info);
+
fprintf(fp,
" possible stack overflow: %lx: %lx != STACK_END_MAGIC\n",
- tc->thread_info + SIZE(thread_info), magic);
+ location, magic);
overflow++, total++;
}
--
2.20.1

View File

@ -0,0 +1,35 @@
From b9dc76e232e0226a14ae3089e3be5c915f2bb981 Mon Sep 17 00:00:00 2001
From: Lianbo Jiang <lijiang@redhat.com>
Date: Mon, 10 Jan 2022 17:25:06 +0800
Subject: [PATCH 03/10] Fix for HZ calculation on Linux 5.14 and later
Kernel commit 3e9a99eba058 ("block/mq-deadline: Rename dd_init_queue()
and dd_exit_queue()") renamed dd_init_queue to dd_init_sched. Without
the patch, the 'help -m' may print incorrect hz value as follows:
crash> help -m | grep hz
hz: 1000 <---The correct hz value on ppc64le machine is 100.
^^^^
Fixes: b93027ce5c75 ("Add alternate HZ calculation using write_expire")
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
task.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/task.c b/task.c
index b5ddc88e0acb..76e184ae70b1 100644
--- a/task.c
+++ b/task.c
@@ -440,6 +440,8 @@ task_init(void)
}
} else if ((symbol_exists("dd_init_queue") &&
gdb_set_crash_scope(symbol_value("dd_init_queue"), "dd_init_queue")) ||
+ (symbol_exists("dd_init_sched") &&
+ gdb_set_crash_scope(symbol_value("dd_init_sched"), "dd_init_sched")) ||
(symbol_exists("deadline_init_queue") &&
gdb_set_crash_scope(symbol_value("deadline_init_queue"), "deadline_init_queue"))) {
char buf[BUFSIZE];
--
2.20.1

View File

@ -0,0 +1,39 @@
From 14f8c460473c8613553b5defd174ca2af812ddcb Mon Sep 17 00:00:00 2001
From: Alexander Egorenkov <egorenar@linux.ibm.com>
Date: Mon, 6 Dec 2021 16:04:19 +0100
Subject: [PATCH 04/10] memory: Handle struct slab changes on Linux 5.17-rc1
and later
Since kernel commit d122019bf061 ("mm: Split slab into its own type"),
the struct slab is used for both SLAB and SLUB. Therefore, don't depend
on the non-presence of the struct slab to decide whether SLAB implementation
should be chosen and use the member variable "cpu_slab" of the struct
kmem_cache instead, it should be present only in SLUB.
Without the patch, crash fails to start with the error message:
crash: invalid structure member offset: kmem_cache_s_num
FILE: memory.c LINE: 9619 FUNCTION: kmem_cache_init()
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
---
memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/memory.c b/memory.c
index 86c02c132890..5af45fd7d834 100644
--- a/memory.c
+++ b/memory.c
@@ -576,7 +576,8 @@ vm_init(void)
STRUCT_SIZE_INIT(cpucache_s, "cpucache_s");
} else if (!VALID_STRUCT(kmem_slab_s) &&
- !VALID_STRUCT(slab_s) &&
+ !VALID_STRUCT(slab_s) &&
+ !MEMBER_EXISTS("kmem_cache", "cpu_slab") &&
(VALID_STRUCT(slab) || (vt->flags & SLAB_OVERLOAD_PAGE))) {
vt->flags |= PERCPU_KMALLOC_V2;
--
2.20.1

View File

@ -0,0 +1,75 @@
From d16dc6fff0260ec26002046fae4aeb546d6b9a0e Mon Sep 17 00:00:00 2001
From: Lianbo Jiang <lijiang@redhat.com>
Date: Mon, 17 Jan 2022 15:14:00 +0800
Subject: [PATCH 05/10] Move the initialization of "boot_date" to task_init()
The "boot_date" is initialized conditionally in the cmd_log(), which may
display incorrect "boot_date" value with the following command before
running the "log -T" command:
crash> help -k | grep date
date: Wed Dec 22 13:39:29 IST 2021
boot_date: Thu Jan 1 05:30:00 IST 1970
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The calculation of "boot_date" depends on the HZ value, and the HZ will
be calculated in task_init() at the latest, so let's move it here.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
kernel.c | 18 +++---------------
task.c | 10 ++++++++++
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/kernel.c b/kernel.c
index 36c57ed501ad..094fe9b2efad 100644
--- a/kernel.c
+++ b/kernel.c
@@ -5025,21 +5025,9 @@ cmd_log(void)
if (argerrs)
cmd_usage(pc->curcmd, SYNOPSIS);
- if (msg_flags & SHOW_LOG_CTIME) {
- if (pc->flags & MINIMAL_MODE) {
- error(WARNING, "the option '-T' is not available in minimal mode\n");
- return;
- }
-
- if (kt->boot_date.tv_sec == 0) {
- ulonglong uptime_jiffies;
- ulong uptime_sec;
-
- get_uptime(NULL, &uptime_jiffies);
- uptime_sec = (uptime_jiffies)/(ulonglong)machdep->hz;
- kt->boot_date.tv_sec = kt->date.tv_sec - uptime_sec;
- kt->boot_date.tv_nsec = 0;
- }
+ if (msg_flags & SHOW_LOG_CTIME && pc->flags & MINIMAL_MODE) {
+ error(WARNING, "the option '-T' is not available in minimal mode\n");
+ return;
}
if (msg_flags & SHOW_LOG_AUDIT) {
diff --git a/task.c b/task.c
index 76e184ae70b1..263a8344dd94 100644
--- a/task.c
+++ b/task.c
@@ -692,6 +692,16 @@ task_init(void)
stack_overflow_check_init();
+ if (machdep->hz) {
+ ulonglong uptime_jiffies;
+ ulong uptime_sec;
+
+ get_uptime(NULL, &uptime_jiffies);
+ uptime_sec = (uptime_jiffies)/(ulonglong)machdep->hz;
+ kt->boot_date.tv_sec = kt->date.tv_sec - uptime_sec;
+ kt->boot_date.tv_nsec = 0;
+ }
+
tt->flags |= TASK_INIT_DONE;
}
--
2.20.1

View File

@ -0,0 +1,78 @@
From 2ebd8c5ecf1f077975b82325a38dd777b594d0a9 Mon Sep 17 00:00:00 2001
From: Kazuhito Hagio <k-hagio-ab@nec.com>
Date: Wed, 19 Jan 2022 16:24:49 +0900
Subject: [PATCH 06/10] Remove ptype command from "ps -t" option to reduce
memory and time
With some vmlinux e.g. RHEL9 ones, the first execution of the gdb ptype
command heavily consumes memory and time. The "ps -t" option uses it in
start_time_timespec(), and it can be replaced with the crash macros.
This can reduce about 1.4 GB memory and 6 seconds time comsumption in
the following test:
$ echo "ps -t" | time crash vmlinux vmcore
Without the patch:
11.60user 0.43system 0:11.94elapsed 100%CPU (0avgtext+0avgdata 1837964maxresident)k
0inputs+400outputs (0major+413636minor)pagefaults 0swaps
With the patch:
5.40user 0.16system 0:05.46elapsed 101%CPU (0avgtext+0avgdata 417896maxresident)k
0inputs+384outputs (0major+41528minor)pagefaults 0swaps
Although the ptype command and similar ones cannot be fully removed,
but removing some of them will make the use of crash safer, especially
for an automatic crash reporter.
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
---
task.c | 25 +++++--------------------
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/task.c b/task.c
index 263a8344dd94..a79ed0d96fb5 100644
--- a/task.c
+++ b/task.c
@@ -4662,8 +4662,6 @@ show_task_times(struct task_context *tcp, ulong flags)
static int
start_time_timespec(void)
{
- char buf[BUFSIZE];
-
switch(tt->flags & (TIMESPEC | NO_TIMESPEC | START_TIME_NSECS))
{
case TIMESPEC:
@@ -4677,24 +4675,11 @@ start_time_timespec(void)
tt->flags |= NO_TIMESPEC;
- open_tmpfile();
- sprintf(buf, "ptype struct task_struct");
- if (!gdb_pass_through(buf, NULL, GNU_RETURN_ON_ERROR)) {
- close_tmpfile();
- return FALSE;
- }
-
- rewind(pc->tmpfile);
- while (fgets(buf, BUFSIZE, pc->tmpfile)) {
- if (strstr(buf, "start_time;")) {
- if (strstr(buf, "struct timespec")) {
- tt->flags &= ~NO_TIMESPEC;
- tt->flags |= TIMESPEC;
- }
- }
- }
-
- close_tmpfile();
+ if (VALID_MEMBER(task_struct_start_time) &&
+ STREQ(MEMBER_TYPE_NAME("task_struct", "start_time"), "timespec")) {
+ tt->flags &= ~NO_TIMESPEC;
+ tt->flags |= TIMESPEC;
+ }
if ((tt->flags & NO_TIMESPEC) && (SIZE(task_struct_start_time) == 8)) {
tt->flags &= ~NO_TIMESPEC;
--
2.20.1

View File

@ -0,0 +1,73 @@
From ce92e458506aec5bc5516a771e26b0f907ce0db4 Mon Sep 17 00:00:00 2001
From: Lianbo Jiang <lijiang@redhat.com>
Date: Wed, 26 Jan 2022 20:32:35 +0800
Subject: [PATCH 07/10] GDB: fix completion related libstdc++ assert
Currently crash built with some specific flags (-D_GLIBCXX_ASSERTIONS
and etc.) may abort and print the following error when running the gdb
list command or tab-completion of symbols. For example:
crash> l panic
/usr/include/c++/11/string_view:234: ...
Aborted (core dumped)
crash> p "TAB completion"
crash> p /usr/include/c++/11/string_view:234: ...
Aborted (core dumped)
When the name string is null (the length of name is zero), there are
multiple places where array access is out of bounds in the gdb/ada-lang.c
(see ada_fold_name() and ada_lookup_name_info()).
The patch backports these gdb patches:
6a780b676637 ("Fix completion related libstdc++ assert when using -D_GLIBCXX_DEBUG")
2ccee230f830 ("Fix off-by-one error in ada_fold_name")
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
---
gdb-10.2.patch | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/gdb-10.2.patch b/gdb-10.2.patch
index 1332b6638028..f5e4c06e6f97 100644
--- a/gdb-10.2.patch
+++ b/gdb-10.2.patch
@@ -1591,3 +1591,34 @@
max += 2;
limit = cols / max;
if (limit != 1 && (limit * max == cols))
+--- gdb-10.2/gdb/ada-lang.c.orig
++++ gdb-10.2/gdb/ada-lang.c
+@@ -997,7 +997,7 @@ ada_fold_name (gdb::string_view name)
+ int len = name.size ();
+ GROW_VECT (fold_buffer, fold_buffer_size, len + 1);
+
+- if (name[0] == '\'')
++ if (!name.empty () && name[0] == '\'')
+ {
+ strncpy (fold_buffer, name.data () + 1, len - 2);
+ fold_buffer[len - 2] = '\000';
+@@ -1006,8 +1006,9 @@ ada_fold_name (gdb::string_view name)
+ {
+ int i;
+
+- for (i = 0; i <= len; i += 1)
++ for (i = 0; i < len; i += 1)
+ fold_buffer[i] = tolower (name[i]);
++ fold_buffer[i] = '\0';
+ }
+
+ return fold_buffer;
+@@ -13596,7 +13597,7 @@ ada_lookup_name_info::ada_lookup_name_info (const lookup_name_info &lookup_name)
+ {
+ gdb::string_view user_name = lookup_name.name ();
+
+- if (user_name[0] == '<')
++ if (!user_name.empty () && user_name[0] == '<')
+ {
+ if (user_name.back () == '>')
+ m_encoded_name
--
2.20.1

View File

@ -0,0 +1,149 @@
From e389667cf62ef5db82f9796cdbc0134ec38612dc Mon Sep 17 00:00:00 2001
From: Tao Liu <ltao@redhat.com>
Date: Fri, 21 Jan 2022 13:43:09 +0800
Subject: [PATCH 08/10] Improve the ps performance for vmcores with large
number of threads
Previously, the ps command will iterate over all threads which
have the same tgid, to accumulate their rss value, in order to
get a thread/process's final rss value as part of the final output.
For non-live systems, the rss accumulation values are identical for
threads which have the same tgid, so there is no need to do the
iteration and accumulation repeatly, thus a lot of readmem calls are
skipped. Otherwise it will be the performance bottleneck if the
vmcores have a large number of threads.
In this patch, the rss accumulation value will be stored in a cache,
next time a thread with the same tgid will take it directly without
the iteration.
For example, we can monitor the performance issue when a vmcore has
~65k processes, most of which are threads for several specific
processes. Without the patch, it will take ~7h for ps command
to finish. With the patch, ps command will finish in 1min.
Signed-off-by: Tao Liu <ltao@redhat.com>
---
defs.h | 1 +
memory.c | 70 +++++++++++++++++++++++++++++++-------------------------
task.c | 1 +
3 files changed, 41 insertions(+), 31 deletions(-)
diff --git a/defs.h b/defs.h
index b63741c7d78b..55600d56ef1c 100644
--- a/defs.h
+++ b/defs.h
@@ -829,6 +829,7 @@ struct task_context { /* context stored for each task */
struct tgid_context { /* tgid and task stored for each task */
ulong tgid;
ulong task;
+ long rss_cache;
};
struct task_table { /* kernel/local task table data */
diff --git a/memory.c b/memory.c
index 5af45fd7d834..e80c59ea4534 100644
--- a/memory.c
+++ b/memory.c
@@ -4665,7 +4665,7 @@ void
get_task_mem_usage(ulong task, struct task_mem_usage *tm)
{
struct task_context *tc;
- long rss = 0;
+ long rss = 0, rss_cache = 0;
BZERO(tm, sizeof(struct task_mem_usage));
@@ -4730,38 +4730,46 @@ get_task_mem_usage(ulong task, struct task_mem_usage *tm)
(last->tgid == (last + 1)->tgid))
last++;
- while (first <= last)
- {
- /* count 0 -> filepages */
- if (!readmem(first->task +
- OFFSET(task_struct_rss_stat) +
- OFFSET(task_rss_stat_count), KVADDR,
- &sync_rss,
- sizeof(int),
- "task_struct rss_stat MM_FILEPAGES",
- RETURN_ON_ERROR))
- continue;
-
- rss += sync_rss;
-
- /* count 1 -> anonpages */
- if (!readmem(first->task +
- OFFSET(task_struct_rss_stat) +
- OFFSET(task_rss_stat_count) +
- sizeof(int),
- KVADDR, &sync_rss,
- sizeof(int),
- "task_struct rss_stat MM_ANONPAGES",
- RETURN_ON_ERROR))
- continue;
-
- rss += sync_rss;
-
- if (first == last)
- break;
- first++;
+ /*
+ * Using rss cache for dumpfile is more beneficial than live debug
+ * because its value never changes in dumpfile.
+ */
+ if (ACTIVE() || last->rss_cache == UNINITIALIZED) {
+ while (first <= last)
+ {
+ /* count 0 -> filepages */
+ if (!readmem(first->task +
+ OFFSET(task_struct_rss_stat) +
+ OFFSET(task_rss_stat_count), KVADDR,
+ &sync_rss,
+ sizeof(int),
+ "task_struct rss_stat MM_FILEPAGES",
+ RETURN_ON_ERROR))
+ continue;
+
+ rss_cache += sync_rss;
+
+ /* count 1 -> anonpages */
+ if (!readmem(first->task +
+ OFFSET(task_struct_rss_stat) +
+ OFFSET(task_rss_stat_count) +
+ sizeof(int),
+ KVADDR, &sync_rss,
+ sizeof(int),
+ "task_struct rss_stat MM_ANONPAGES",
+ RETURN_ON_ERROR))
+ continue;
+
+ rss_cache += sync_rss;
+
+ if (first == last)
+ break;
+ first++;
+ }
+ last->rss_cache = rss_cache;
}
+ rss += last->rss_cache;
tt->last_tgid = last;
}
}
diff --git a/task.c b/task.c
index a79ed0d96fb5..864c838637ee 100644
--- a/task.c
+++ b/task.c
@@ -2947,6 +2947,7 @@ add_context(ulong task, char *tp)
tg = tt->tgid_array + tt->running_tasks;
tg->tgid = *tgid_addr;
tg->task = task;
+ tg->rss_cache = UNINITIALIZED;
if (do_verify && !verify_task(tc, do_verify)) {
error(INFO, "invalid task address: %lx\n", tc->task);
--
2.20.1

View File

@ -0,0 +1,58 @@
From dd35cf6fc5463ff31206fbb27238b4c3802c063d Mon Sep 17 00:00:00 2001
From: Kazuhito Hagio <k-hagio-ab@nec.com>
Date: Wed, 26 Jan 2022 06:07:00 +0000
Subject: [PATCH 09/10] arm64: Fix segfault by "bt" command with offline cpus
Currently on arm64, NT_PRSTATUS notes in dumpfile are not mapped to
online cpus and machine_specific->panic_task_regs correctly. As a
result, the "bt" command can cause a segmentation fault.
crash> bt -c 0
PID: 0 TASK: ffff8000117fa240 CPU: 0 COMMAND: "swapper/0"
Segmentation fault (core dumped)
To fix this,
1) make map_cpus_to_prstatus_kdump_cmprs() map the notes to
dd->nt_prstatus_percpu also on arm64, and
2) move arm64_get_crash_notes() to machdep_init(POST_INIT) in order
to apply the mapping to machine_specific->panic_task_regs.
Resolves: https://github.com/crash-utility/crash/issues/105
Reported-by: xuchunmei000 <xuchunmei@linux.alibaba.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Tested-by: David Wysochanski <dwysocha@redhat.com>
---
arm64.c | 2 +-
diskdump.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arm64.c b/arm64.c
index 23c3d75d85aa..4f2c2b5104a1 100644
--- a/arm64.c
+++ b/arm64.c
@@ -472,7 +472,7 @@ arm64_init(int when)
arm64_stackframe_init();
break;
- case POST_VM:
+ case POST_INIT:
/*
* crash_notes contains machine specific information about the
* crash. In particular, it contains CPU registers at the time
diff --git a/diskdump.c b/diskdump.c
index 3e1cfd548c96..d5674276e1fd 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -111,8 +111,7 @@ map_cpus_to_prstatus_kdump_cmprs(void)
if (pc->flags2 & QEMU_MEM_DUMP_COMPRESSED) /* notes exist for all cpus */
goto resize_note_pointers;
- if (!(online = get_cpus_online()) || (online == kt->cpus) ||
- machine_type("ARM64"))
+ if (!(online = get_cpus_online()) || (online == kt->cpus))
goto resize_note_pointers;
if (CRASHDEBUG(1))
--
2.20.1

View File

@ -0,0 +1,88 @@
From 5f390ed811b00753ce7d5ceec5717280df16fd28 Mon Sep 17 00:00:00 2001
From: Kazuhito Hagio <k-hagio-ab@nec.com>
Date: Wed, 2 Feb 2022 02:14:56 +0000
Subject: [PATCH 10/10] Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
Since the following kernel commits split slab info from struct page
into struct slab, crash cannot get several slab related offsets from
struct page.
d122019bf061 ("mm: Split slab into its own type")
07f910f9b729 ("mm: Remove slab from struct page")
Without the patch, "kmem -s|-S" and "bt -F[F]" options cannot work
correctly with the following errors:
crash> kmem -s kmem_cache
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
kmem: page_to_nid: invalid page: ffff9454afc35020
kmem: kmem_cache: cannot gather relevant slab data
ffff945140042000 216 ? ? ? 8k kmem_cache
crash> bt -F
...
bt: invalid structure member offset: page_slab
FILE: memory.c LINE: 9477 FUNCTION: vaddr_to_kmem_cache()
Signed-by: Kazuhito Hagio <k-hagio-ab@nec.com>
---
memory.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/memory.c b/memory.c
index e80c59ea4534..8448ddc3a16c 100644
--- a/memory.c
+++ b/memory.c
@@ -421,6 +421,8 @@ vm_init(void)
MEMBER_OFFSET_INIT(page_prev, "page", "prev");
if (INVALID_MEMBER(page_next))
ANON_MEMBER_OFFSET_INIT(page_next, "page", "next");
+ if (INVALID_MEMBER(page_next))
+ MEMBER_OFFSET_INIT(page_next, "slab", "next");
MEMBER_OFFSET_INIT(page_list, "page", "list");
if (VALID_MEMBER(page_list)) {
@@ -747,11 +749,15 @@ vm_init(void)
MEMBER_OFFSET_INIT(kmem_cache_random, "kmem_cache", "random");
MEMBER_OFFSET_INIT(kmem_cache_cpu_freelist, "kmem_cache_cpu", "freelist");
MEMBER_OFFSET_INIT(kmem_cache_cpu_page, "kmem_cache_cpu", "page");
+ if (INVALID_MEMBER(kmem_cache_cpu_page))
+ MEMBER_OFFSET_INIT(kmem_cache_cpu_page, "kmem_cache_cpu", "slab");
MEMBER_OFFSET_INIT(kmem_cache_cpu_node, "kmem_cache_cpu", "node");
MEMBER_OFFSET_INIT(kmem_cache_cpu_partial, "kmem_cache_cpu", "partial");
MEMBER_OFFSET_INIT(page_inuse, "page", "inuse");
if (INVALID_MEMBER(page_inuse))
ANON_MEMBER_OFFSET_INIT(page_inuse, "page", "inuse");
+ if (INVALID_MEMBER(page_inuse))
+ MEMBER_OFFSET_INIT(page_inuse, "slab", "inuse");
MEMBER_OFFSET_INIT(page_offset, "page", "offset");
if (INVALID_MEMBER(page_offset))
ANON_MEMBER_OFFSET_INIT(page_offset, "page", "offset");
@@ -763,6 +769,9 @@ vm_init(void)
if (INVALID_MEMBER(page_slab))
ANON_MEMBER_OFFSET_INIT(page_slab, "page", "slab_cache");
}
+ if (INVALID_MEMBER(page_slab))
+ MEMBER_OFFSET_INIT(page_slab, "slab", "slab_cache");
+
MEMBER_OFFSET_INIT(page_slab_page, "page", "slab_page");
if (INVALID_MEMBER(page_slab_page))
ANON_MEMBER_OFFSET_INIT(page_slab_page, "page", "slab_page");
@@ -772,10 +781,14 @@ vm_init(void)
MEMBER_OFFSET_INIT(page_freelist, "page", "freelist");
if (INVALID_MEMBER(page_freelist))
ANON_MEMBER_OFFSET_INIT(page_freelist, "page", "freelist");
+ if (INVALID_MEMBER(page_freelist))
+ MEMBER_OFFSET_INIT(page_freelist, "slab", "freelist");
if (INVALID_MEMBER(kmem_cache_objects)) {
MEMBER_OFFSET_INIT(kmem_cache_oo, "kmem_cache", "oo");
/* NOTE: returns offset of containing bitfield */
ANON_MEMBER_OFFSET_INIT(page_objects, "page", "objects");
+ if (INVALID_MEMBER(page_objects))
+ ANON_MEMBER_OFFSET_INIT(page_objects, "slab", "objects");
}
if (VALID_MEMBER(kmem_cache_node)) {
ARRAY_LENGTH_INIT(len, NULL, "kmem_cache.node", NULL, 0);
--
2.20.1

View File

@ -4,7 +4,7 @@
Summary: Kernel analysis utility for live systems, netdump, diskdump, kdump, LKCD or mcore dumpfiles
Name: crash
Version: 8.0.0
Release: 4%{?dist}.alma
Release: 5%{?dist}.alma
License: GPLv3
Source0: https://github.com/crash-utility/crash/archive/crash-%{version}.tar.gz
Source1: http://ftp.gnu.org/gnu/gdb/gdb-10.2.tar.gz
@ -24,6 +24,16 @@ Patch3: 0002-defs.h-fix-breakage-of-compatibility-of-struct-machd.patch
Patch4: 0003-defs.h-fix-breakage-of-compatibility-of-struct-symbo.patch
Patch5: 0001-Fix-pvops-Xen-detection-for-arm-machine.patch
Patch6: 0002-Handle-blk_mq_ctx-member-changes-for-kernels-5.16-rc.patch
Patch7: 0001-Fix-for-timer-r-option-to-display-all-the-per-CPU-cl.patch
Patch8: 0002-Fix-for-bt-v-option-to-display-the-stack-end-address.patch
Patch9: 0003-Fix-for-HZ-calculation-on-Linux-5.14-and-later.patch
Patch10: 0004-memory-Handle-struct-slab-changes-on-Linux-5.17-rc1-.patch
Patch11: 0005-Move-the-initialization-of-boot_date-to-task_init.patch
Patch12: 0006-Remove-ptype-command-from-ps-t-option-to-reduce-memo.patch
Patch13: 0007-GDB-fix-completion-related-libstdc-assert.patch
Patch14: 0008-Improve-the-ps-performance-for-vmcores-with-large-nu.patch
Patch15: 0009-arm64-Fix-segfault-by-bt-command-with-offline-cpus.patch
Patch16: 0010-Fix-for-kmem-s-S-and-bt-F-F-on-Linux-5.17-rc1.patch
%description
The core analysis suite is a self-contained tool that can be used to
@ -50,6 +60,16 @@ offered by Mission Critical Linux, or the LKCD kernel patch.
%patch4 -p1
%patch5 -p1
%patch6 -p1
%patch7 -p1
%patch8 -p1
%patch9 -p1
%patch10 -p1
%patch11 -p1
%patch12 -p1
%patch13 -p1
%patch14 -p1
%patch15 -p1
%patch16 -p1
%build
@ -75,9 +95,15 @@ cp -p defs.h %{buildroot}%{_includedir}/crash
%{_includedir}/*
%changelog
* Mon Jan 17 2022 Eduard Abdullin <eabdullin@almalinux.org> - 8.0.0-4.alma
* Mon Apr 08 2022 Eduard Abdullin <eabdullin@almalinux.org> - 8.0.0-5.alma
- Debrand for AlmaLinux
* Mon Feb 07 2022 Lianbo Jiang <lijiang@redhat.com> - 8.0.0-5
- Fix segfault on aarch64 for "bt -a|-c" command
- Fix segfault for the "l" command of gdb
- Fix HZ calculation on Linux 5.14 and later
- Fix for other issues
* Wed Dec 29 2021 Lianbo Jiang <lijiang@redhat.com> - 8.0.0-4
- Handle blk_mq_ctx member changes for kernels 5.16-rc1 and later