import CS crash-gcore-command-1.6.4-9.el10
This commit is contained in:
parent
ec59492671
commit
b215d81b25
@ -1 +0,0 @@
|
||||
2c15b78c28ef2e71307e826a5a7912346b4c4d2a SOURCES/crash-gcore-command-1.6.4.tar.gz
|
||||
2
.gitignore
vendored
2
.gitignore
vendored
@ -1 +1 @@
|
||||
SOURCES/crash-gcore-command-1.6.4.tar.gz
|
||||
crash-gcore-command-1.6.4.tar.gz
|
||||
|
||||
@ -0,0 +1,66 @@
|
||||
From b3af265aa60251f282145bb0eee3b83d8a15ebb7 Mon Sep 17 00:00:00 2001
|
||||
From: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
|
||||
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 <d.hatayama@fujitsu.com>
|
||||
---
|
||||
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
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
Summary: Gcore extension module for the crash utility
|
||||
Name: crash-gcore-command
|
||||
Version: 1.6.4
|
||||
Release: 8%{?dist}.1
|
||||
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,8 +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-gcore-update-set_context-with-upstream-counterpart.patch
|
||||
Patch2: 0001-x86-fix-the-issue-that-core-files-for-64-bit-tasks-a.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
|
||||
@ -38,9 +39,8 @@ install -m 0755 -t %{buildroot}%{_libdir}/crash/extensions %{_builddir}/%{repona
|
||||
%license COPYING
|
||||
|
||||
%changelog
|
||||
* Tue Aug 05 2025 Kevin Lyons <kevin.x.lyons@oracle.com> - 1.6.4-8.1
|
||||
- x86: fix the issue that core files for 64-bit tasks are generated in the 32-bit format
|
||||
- gcore: update set_context with upstream counterpart
|
||||
* Mon May 5 2025 Tao Liu <ltao@redhat.com> - 1.6.4-9
|
||||
- rebase to latest upstream e03ff7341a
|
||||
|
||||
* Tue Oct 29 2024 Troy Dawson <tdawson@redhat.com> - 1.6.4-8
|
||||
- Bump release for October 2024 mass rebuild:
|
||||
Loading…
Reference in New Issue
Block a user