diff --git a/0001-gcore-update-set_context-with-upstream-counterpart.patch b/0001-gcore-update-set_context-with-upstream-counterpart.patch new file mode 100644 index 0000000..c31a80c --- /dev/null +++ b/0001-gcore-update-set_context-with-upstream-counterpart.patch @@ -0,0 +1,47 @@ +From 62b8d5005eaa9014467db85cfe268e65c6679f4c Mon Sep 17 00:00:00 2001 +From: Tao Liu +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 +--- + 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 + diff --git a/0001-x86-fix-extend-gcore.so-taking-much-time-like-more-t.patch b/0001-x86-fix-extend-gcore.so-taking-much-time-like-more-t.patch new file mode 100644 index 0000000..ddaf607 --- /dev/null +++ b/0001-x86-fix-extend-gcore.so-taking-much-time-like-more-t.patch @@ -0,0 +1,66 @@ +From b3af265aa60251f282145bb0eee3b83d8a15ebb7 Mon Sep 17 00:00:00 2001 +From: HATAYAMA Daisuke +Date: Mon, 18 Sep 2023 20:45:11 -0400 +Subject: [PATCH] x86: fix extend gcore.so taking much time like more than 1 + hour when huge thread group is present + +extend gcore.so command takes lengthy time such as more than 1 hour +when huge thread group is present. + +The root cause of this issue is that we never take into account time +complexity of function gcore_arch_vsyscall_has_vm_alwaysdump_flag() +sufficiently, which iterates the task list and vma lists of each task +to detect existence of VM_ALWAYS flag in a given crash dump and so has +O(nm) where the n is the length of the task list and the m is the +total number of vma among all tasks. + +To fix this issue, skip this process for the kernels whose version is +equal to or larger than v3.4.0. + +Originally, this process was implemented to detect existence of +VM_ALWAYS flag that was removed at the commit +909af768e88867016f427264ae39d27a57b6a8ed (coredump: remove +VM_ALWAYSDUMP flag) included at Linux kernel v3.4. However, the base +kernel version of RHEL7.0 GA is 3.10.0-123.el7. Hence, the kernels for +RHEL7 and later have included the commit. For RHEL7 and later, it's +sufficient to conclude absence of the flag by checking kernel version +of a given crash dump. + +The issue could still remain on RHEL6 and older, but we think it's +acceptable because today we rarely handle crash dump files of RHEL6 +and older. + +Signed-off-by: HATAYAMA Daisuke +--- + src/libgcore/gcore_x86.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +diff --git a/src/libgcore/gcore_x86.c b/src/libgcore/gcore_x86.c +index 8878f79..3ddf510 100644 +--- a/src/libgcore/gcore_x86.c ++++ b/src/libgcore/gcore_x86.c +@@ -2502,6 +2502,21 @@ int gcore_arch_vsyscall_has_vm_alwaysdump_flag(void) + struct task_context *tc; + int i; + ++ /* ++ * The commit 909af768e88867016f427264ae39d27a57b6a8ed ++ * (coredump: remove VM_ALWAYSDUMP flag) of the Linux kernel ++ * was merged at v3.4. We can say VM_ALWAYSDUMP flag doesn't ++ * exist for the version 3.4.0 or later. The base kernel ++ * version of RHEL7.0 GA is 3.10.0-123.el7. Hence, this ++ * condition is expected to match RHEL7 and later RHEL major ++ * versions. On the other hand, the commit ++ * 909af768e88867016f427264ae39d27a57b6a8ed was backported ++ * into the kernel package in RHEL6 and the exploring code is ++ * still needed. ++ */ ++ if (THIS_KERNEL_VERSION >= LINUX(3, 4, 0)) ++ return FALSE; ++ + /* + * For simplicity, consider that VM_ALWAYSDUMP was already not + * present when maple tree was introduced. +-- +2.47.0 + diff --git a/0001-x86-fix-the-issue-that-core-files-for-64-bit-tasks-a.patch b/0001-x86-fix-the-issue-that-core-files-for-64-bit-tasks-a.patch new file mode 100644 index 0000000..c619c11 --- /dev/null +++ b/0001-x86-fix-the-issue-that-core-files-for-64-bit-tasks-a.patch @@ -0,0 +1,85 @@ +From e03ff7341a9a624a46cea4e60ee097606b1687a8 Mon Sep 17 00:00:00 2001 +From: HATAYAMA Daisuke +Date: Sat, 23 Nov 2024 17:30:41 +0900 +Subject: [PATCH] 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 + diff --git a/crash-gcore-command.spec b/crash-gcore-command.spec index bc4a585..78b8fe8 100644 --- a/crash-gcore-command.spec +++ b/crash-gcore-command.spec @@ -3,7 +3,7 @@ Summary: Gcore extension module for the crash utility Name: crash-gcore-command Version: 1.6.4 -Release: 8%{?dist} +Release: 9%{?dist} License: GPL-2.0-only Source0: https://github.com/fujitsu/crash-gcore/archive/v%{version}/%{name}-%{version}.tar.gz URL: https://github.com/fujitsu/crash-gcore @@ -14,6 +14,9 @@ BuildRequires: gcc Requires: crash >= 5.1.5 Patch0: crash-gcore-1.6.4-coredump-fix-building-failure-due-to-undefined-macro.patch +Patch1: 0001-x86-fix-extend-gcore.so-taking-much-time-like-more-t.patch +Patch2: 0001-gcore-update-set_context-with-upstream-counterpart.patch +Patch3: 0001-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 @@ -36,6 +39,9 @@ install -m 0755 -t %{buildroot}%{_libdir}/crash/extensions %{_builddir}/%{repona %license COPYING %changelog +* Mon May 5 2025 Tao Liu - 1.6.4-9 +- rebase to latest upstream e03ff7341a + * Tue Oct 29 2024 Troy Dawson - 1.6.4-8 - Bump release for October 2024 mass rebuild: Resolves: RHEL-64018