Release 1.6.4-2

Resolves: RHEL-73069

Signed-off-by: Tao Liu <ltao@redhat.com>
This commit is contained in:
Tao Liu 2025-05-05 15:57:18 +12:00
parent b4a0382349
commit 8b31c045ac
3 changed files with 138 additions and 1 deletions

View File

@ -0,0 +1,47 @@
From 62b8d5005eaa9014467db85cfe268e65c6679f4c Mon Sep 17 00:00:00 2001
From: Tao Liu <ltao@redhat.com>
Date: Mon, 4 Nov 2024 17:11:19 +1300
Subject: [PATCH 1/2] gcore: update set_context with upstream counterpart
With the introduction of upstream commit "Preparing for gdb stack unwind
support" [1], the function set_context() is added by a 3rd parameter. Without
this patch, the compiliation of gcore will fail.
The 3rd parameter of set_context() is used to sync the context of crash and
gdb, so gdb can hold the the value of registers of current crash's task
context, and gdb can output the stack unwinding for current task.
This have nothing to do with gcore, so simply set the 3rd parameter as FALSE.
[1]: https://github.com/lian-bo/crash/commit/d75d15d31b92f8882ccb15c960665e2c8a8d1c28
Signed-off-by: Tao Liu <ltao@redhat.com>
---
src/gcore.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gcore.c b/src/gcore.c
index 47a9c0d..a79f69b 100644
--- a/src/gcore.c
+++ b/src/gcore.c
@@ -306,7 +306,7 @@ static void do_gcore(char *arg)
if (tc != CURRENT_CONTEXT()) {
gcore->orig_task = CURRENT_TASK();
- (void) set_context(tc->task, NO_PID);
+ (void) set_context(tc->task, NO_PID, FALSE);
}
snprintf(gcore->corename, CORENAME_MAX_SIZE + 1, "core.%lu.%s",
@@ -340,7 +340,7 @@ static void do_gcore(char *arg)
}
if (gcore->orig_task)
- (void)set_context(gcore->orig_task, NO_PID);
+ (void)set_context(gcore->orig_task, NO_PID, FALSE);
}
--
2.47.0

View File

@ -0,0 +1,85 @@
From e03ff7341a9a624a46cea4e60ee097606b1687a8 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Date: Sat, 23 Nov 2024 17:30:41 +0900
Subject: [PATCH 2/2] x86: fix the issue that core files for 64-bit tasks are
generated in the 32-bit format
Core files for 64-bit tasks are falsely generated in the 32-bit
formats.
The root cause of this issue is that location of saving register
values on kernel stacks is changed by the kernel commit
65c9cc9e2c14602d98f1ca61c51ac954e9529303 (x86/fred: Reserve space for
the FRED stack frame) in Linux kernel 6.9-rc1 to add some reserved
area for FRED feature and gcore doesn't take this into
consideration. Hence, the value of CS register retrieved from kernel
stacks based on the existing logic is wrong and thus checking
execution mode of a given task based on the value also works wrong.
To fix this issue, let's take the FRED feature into account. If FRED
data structure is defined, retrieve register values from the address
next to the reserved for the FRED feature.
This logic is borrowed from the commit
48764a14bc5856f0b0bb30685336c68b832154fc (x86_64: fix for adding
top_of_kernel_stack_padding for kernel stack) and the commit
196c4b79c13d1c0e6d7b21c8321eca07d3838d6a (X86 64: fix a regression
issue about kernel stack padding) of crash utility.
---
src/libgcore/gcore_x86.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/libgcore/gcore_x86.c b/src/libgcore/gcore_x86.c
index 3ddf510..4f43956 100644
--- a/src/libgcore/gcore_x86.c
+++ b/src/libgcore/gcore_x86.c
@@ -514,10 +514,11 @@ convert_from_fxsr(struct user_i387_ia32_struct *env, struct task_context *target
char *pt_regs_buf;
uint16_t ds;
struct machine_specific *ms = machdep->machspec;
+ ulong padding_size = VALID_SIZE(fred_frame) > 0 ? (2 * 8) : 0;
pt_regs_buf = GETBUF(SIZE(pt_regs));
- readmem(machdep->get_stacktop(target->task) - SIZE(pt_regs),
+ readmem(machdep->get_stacktop(target->task) - padding_size - SIZE(pt_regs),
KVADDR, pt_regs_buf, SIZE(pt_regs),
"convert_from_fxsr: regs",
gcore_verbose_error_handle());
@@ -1837,6 +1838,7 @@ static int genregs_get(struct task_context *target,
struct user_regs_struct active_regs;
const int active = is_task_active(target->task);
struct machine_specific *ms = machdep->machspec;
+ ulong padding_size = VALID_SIZE(fred_frame) > 0 ? (2 * 8) : 0;
BZERO(regs, sizeof(*regs));
@@ -1854,7 +1856,7 @@ static int genregs_get(struct task_context *target,
*/
pt_regs_buf = GETBUF(SIZE(pt_regs));
- readmem(machdep->get_stacktop(target->task) - SIZE(pt_regs), KVADDR,
+ readmem(machdep->get_stacktop(target->task) - padding_size - SIZE(pt_regs), KVADDR,
pt_regs_buf, SIZE(pt_regs), "genregs_get: pt_regs",
gcore_verbose_error_handle());
@@ -2188,6 +2190,7 @@ static int genregs_get32(struct task_context *target,
struct user_regs_struct *regs = (struct user_regs_struct *)buf;
char *pt_regs_buf;
ulonglong pt_regs_addr;
+ ulong padding_size = VALID_SIZE(fred_frame) > 0 ? (2 * 8) : 0;
if (is_task_active(target->task) && KVMDUMP_DUMPFILE()) {
get_regs_from_kvmdump_notes(target, regs);
@@ -2198,7 +2201,7 @@ static int genregs_get32(struct task_context *target,
pt_regs_buf = GETBUF(SIZE(pt_regs));
- pt_regs_addr = machdep->get_stacktop(target->task) - SIZE(pt_regs);
+ pt_regs_addr = machdep->get_stacktop(target->task) - padding_size - SIZE(pt_regs);
/*
* The commit 07b047fc2466249aff7cdb23fa0b0955a7a00d48
--
2.47.0

View File

@ -3,7 +3,7 @@
Summary: Gcore extension module for the crash utility
Name: crash-gcore-command
Version: 1.6.4
Release: 1%{?dist}
Release: 2%{?dist}
License: GPLv2
Source0: https://github.com/fujitsu/crash-gcore/archive/v%{version}/%{name}-%{version}.tar.gz
URL: https://github.com/fujitsu/crash-gcore
@ -15,6 +15,8 @@ Requires: crash >= 5.1.5
Patch0: 0001-coredump-fix-building-failure-due-to-undefined-macro.patch
Patch1: 0002-x86-fix-extend-gcore.so-taking-much-time-like-more-t.patch
Patch2: 0001-gcore-update-set_context-with-upstream-counterpart.patch
Patch3: 0002-x86-fix-the-issue-that-core-files-for-64-bit-tasks-a.patch
%description
Command for creating a core dump file of a user-space task that was
@ -37,6 +39,9 @@ install -m 0755 -t %{buildroot}%{_libdir}/crash/extensions %{_builddir}/%{repona
%license COPYING
%changelog
* Mon May 05 2025 Lianbo Jiang <lijiang@redhat.com> - 1.6.4-2
- Rebase to latest upstream e03ff7341a9a
* Fri Jul 05 2024 Lianbo Jiang <lijiang@redhat.com> - 1.6.4-1
- Rebase to upstream 1.6.4