[PATCH RFC] sys: Display livepatch transition status in KERNEL line
by Motomasa Suzuki
This commit enhances the 'sys' command to show if a kernel livepatch is
currently in a transition phase, directly within the KERNEL output line.
Currently, diagnosing system state during or immediately after livepatch
operations can be ambiguous. While 'livepatch' is indicated by
'[LIVEPATCH]', there's no direct indicator within 'crash' itself to show
if a livepatch is actively applying, reverting, or in some other
transient state. This lack of immediate visibility can complicate crash
analysis, as the system might be in an inconsistent state due to an
ongoing patch application/reversion.
This change introduces a new '[TRANSITION]' flag which appears next to
'[LIVEPATCH]' and '[TAINTED]' in the 'sys' command output. This flag is
set if the livepatch subsystem indicates an in-progress transition
(e.g., as exposed via '/sys/kernel/livepatch/<patch_name>/transition').
Example 'sys' output with this change:
KERNEL: /usr/lib/debug/lib/modules/<version_name>/vmlinux [LIVEPATCH]
[TRANSITION] [TAINTED]
This enhancement provides critical, at-a-glance information for
developers and administrators, allowing them to quickly ascertain if
ongoing livepatch activity might be influencing a system's behavior
during crash investigations. It directly leverages existing kernel
livepatch status infrastructure to enrich the crash utility's diagnostic
capabilities.
Signed-off-by: Motomasa Suzuki <suzuki.motomasa(a)fujitsu.com>
---
defs.h | 1 +
kernel.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/defs.h b/defs.h
index ab4aee8..b459d4d 100644
--- a/defs.h
+++ b/defs.h
@@ -2280,6 +2280,7 @@ struct offset_table { /* stash of commonly-used offsets */
long bpf_ringbuf_map_rb;
long bpf_ringbuf_consumer_pos;
long bpf_ringbuf_nr_pages;
+ long klp_patch_list;
};
struct size_table { /* stash of commonly-used sizes */
diff --git a/kernel.c b/kernel.c
index 13f3374..1ca18e4 100644
--- a/kernel.c
+++ b/kernel.c
@@ -461,7 +461,10 @@ kernel_init()
error(WARNING,
"list_head.next offset: %ld: list command may fail\n",
OFFSET(list_head_next));
-
+ if (STRUCT_EXISTS("klp_patch")) {
+ if (MEMBER_EXISTS("klp_patch", "list"))
+ MEMBER_OFFSET_INIT(klp_patch_list, "klp_patch", "list");
+ }
MEMBER_OFFSET_INIT(hlist_node_next, "hlist_node", "next");
MEMBER_OFFSET_INIT(hlist_node_pprev, "hlist_node", "pprev");
STRUCT_SIZE_INIT(hlist_head, "hlist_head");
@@ -5681,6 +5684,48 @@ is_livepatch(void)
return FALSE;
}
+#define KLP_PATCH_ITER_LIMIT 1024
+
+static int
+is_livepatch_transition(void)
+{
+ struct kernel_list_head head;
+ struct kernel_list_head node;
+ ulong transition_patch;
+ ulong list_addr;
+ ulong current;
+ ulong patch_addr;
+ int loops;
+
+ if (!try_get_symbol_data("klp_transition_patch", sizeof(ulong),
+ &transition_patch) || !transition_patch)
+ return FALSE;
+
+ if (!kernel_symbol_exists("klp_patches") || !VALID_MEMBER(klp_patch_list))
+ return FALSE;
+
+ list_addr = symbol_value("klp_patches");
+ if (!readmem(list_addr, KVADDR, &head, sizeof(head), "klp_patches",
+ RETURN_ON_ERROR | QUIET))
+ return FALSE;
+
+ for (current = (ulong)head.next, loops = 0;
+ current && current != list_addr && loops < KLP_PATCH_ITER_LIMIT;
+ current = (ulong)node.next, loops++) {
+
+ if (!readmem(list_addr, KVADDR, &head, sizeof(head),
+ "klp_patch list entry", RETURN_ON_ERROR | QUIET))
+ return FALSE;
+
+ patch_addr = current - (ulong)OFFSET(klp_patch_list);
+
+ if (patch_addr == transition_patch)
+ return TRUE;
+ }
+
+ return FALSE;
+}
+
/*
* Display system stats at init-time or for the sys command.
*/
@@ -5724,17 +5769,19 @@ display_sys_stats(void)
}
} else {
if (pc->system_map) {
- fprintf(fp, " SYSTEM MAP: %s%s%s\n", pc->system_map,
+ fprintf(fp, " SYSTEM MAP: %s%s%s%s\n", pc->system_map,
is_livepatch() ? " [LIVEPATCH]" : "",
+ is_livepatch_transition() ? " [TRANSITION]" : "",
is_kernel_tainted() ? " [TAINTED]" : "");
fprintf(fp, "DEBUG KERNEL: %s %s\n",
pc->namelist_orig ?
pc->namelist_orig : pc->namelist,
debug_kernel_version(pc->namelist));
} else
- fprintf(fp, " KERNEL: %s%s%s\n", pc->namelist_orig ?
+ fprintf(fp, " KERNEL: %s%s%s%s\n", pc->namelist_orig ?
pc->namelist_orig : pc->namelist,
is_livepatch() ? " [LIVEPATCH]" : "",
+ is_livepatch_transition() ? " [TRANSITION]" : "",
is_kernel_tainted() ? " [TAINTED]" : "");
}
--
2.47.3
6 days, 7 hours
[PATCH v3] ppc64: Fix bt printing error stack trace
by Tao Liu
A error stack trace of bt cmd observed:
crash> bt 1
PID: 1 TASK: c000000003714b80 CPU: 2 COMMAND: "systemd"
#0 [c0000000037735c0] _end at c0000000037154b0 (unreliable)
#1 [c000000003773770] __switch_to at c00000000001fa9c
#2 [c0000000037737d0] __schedule at c00000000112e4ec
#3 [c0000000037738b0] schedule at c00000000112ea80
...
The #0 stack trace is incorrect, the function address shouldn't exceed _end.
The reason is for kernel commit cd52414d5a6c ("powerpc/64: ELFv2 use
minimal stack frames in int and switch frame sizes"), the offset of pt_regs
to sp changed from STACK_FRAME_OVERHEAD, i.e 112, to STACK_SWITCH_FRAME_REGS.
For CONFIG_PPC64_ELF_ABI_V1, it's 112, for ABI_V2, it's 48. So the nip will
read a wrong value from stack when ABI_V2 enabled.
After the patch:
crash> bt 1
PID: 1 TASK: c000000003714b80 CPU: 2 COMMAND: "systemd"
#0 [c0000000037737d0] __schedule at c00000000112e4ec
#1 [c0000000037738b0] schedule at c00000000112ea80
...
Signed-off-by: Tao Liu <ltao(a)redhat.com>
Suggested-by: Aditya Gupta <adityag(a)linux.ibm.com>
---
v1 Discussion: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01181.html
v2 No discussion: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01170.html
v3 -> v2: Rebase to top-most of upstream patch
Regarding to v1's discussion, we cannot run abiv1 program on abiv2
kernel, it's because abiv1 is big-endian and abiv2 is little-endian, and
abiv2, or ppc64le kernel doesn't support big-endian, or abiv1 program
cannot run upon it, see the following:
$ file blkid
blkid: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, Power ELF V1 ABI, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=b36e8a2a5e4d27039591a35fca38fa48735f5540, stripped
$ ~/qemu-10.1.2/build/qemu-ppc64 ./blkid
/dev/mapper/root: UUID="..." TYPE="xfs"
/dev/sda3: UUID="..." TYPE="LVM2_member" PARTUUID="..."
/dev/sda2: UUID="..." TYPE="xfs" PARTUUID="..."
/dev/mapper/swap: UUID="..." TYPE="swap"
/dev/mapper/home: UUID="..." TYPE="xfs"
/dev/sda1: PARTUUID="..."
$ ./blkid
-bash: ./blkid: cannot execute binary file: Exec format error
$ uname -a
Linux 6.12.0-150.el10.ppc64le #1 SMP Fri Oct 31 06:58:14 EDT 2025 ppc64le GNU/Linux
$ file /bin/bash
/bin/bash: ELF 64-bit LSB pie executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, BuildID[sha1]=9ab800028ced16c5974f5b19cb6ed754178802a8, for GNU/Linux 3.10.0, stripped
The abiv1 program blkid cannot be run on this machine, except with the
help of qemu. So from my view, we don't need to consider the case that abiv2
kernel might containing a abiv1 program or .ko.
Please feel free to correct me if I'm wrong. @Aditya Gupta
---
defs.h | 3 ++-
netdump.c | 14 ++++++++++----
ppc64.c | 34 +++++++++++++++++++++++++++++++---
symbols.c | 5 +++--
4 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/defs.h b/defs.h
index ab4aee8..19dff88 100644
--- a/defs.h
+++ b/defs.h
@@ -4699,6 +4699,7 @@ struct efi_memory_desc_t {
#define MSR_PR_LG 14 /* Problem State / Privilege Level */
/* Used to find the user or kernel-mode frame*/
+#define STACK_SWITCH_FRAME_REGS 48
#define STACK_FRAME_OVERHEAD 112
#define EXCP_FRAME_MARKER 0x7265677368657265
@@ -5820,7 +5821,7 @@ void dump_offset_table(char *, ulong);
int is_elf_file(char *);
int is_kernel(char *);
int is_shared_object(char *);
-int file_elf_version(char *);
+int file_elf_header(char *, char *);
int is_system_map(char *);
int is_compressed_kernel(char *, char **);
int select_namelist(char *);
diff --git a/netdump.c b/netdump.c
index 69100a9..9806ce9 100644
--- a/netdump.c
+++ b/netdump.c
@@ -665,11 +665,11 @@ resize_elf_header(int fd, char *file, char **eheader_ptr, char **sect0_ptr,
}
/*
- * Return the e_version number of an ELF file
+ * Return the e_version or e_flags number of an ELF file
* (or -1 if its not readable ELF file)
*/
int
-file_elf_version(char *file)
+file_elf_header(char *file, char *member)
{
int fd, size;
Elf32_Ehdr *elf32;
@@ -699,11 +699,17 @@ file_elf_version(char *file)
(elf32->e_ident[EI_CLASS] == ELFCLASS32) &&
(elf32->e_ident[EI_DATA] == ELFDATA2LSB) &&
(elf32->e_ident[EI_VERSION] == EV_CURRENT)) {
- return (elf32->e_version);
+ if (STRNEQ(member, "e_version"))
+ return (elf32->e_version);
+ else if (STRNEQ(member, "e_flags"))
+ return (elf32->e_flags);
} else if (STRNEQ(elf64->e_ident, ELFMAG) &&
(elf64->e_ident[EI_CLASS] == ELFCLASS64) &&
(elf64->e_ident[EI_VERSION] == EV_CURRENT)) {
- return (elf64->e_version);
+ if (STRNEQ(member, "e_version"))
+ return (elf64->e_version);
+ else if (STRNEQ(member, "e_flags"))
+ return (elf64->e_flags);
}
return -1;
diff --git a/ppc64.c b/ppc64.c
index d1a5067..213ce90 100644
--- a/ppc64.c
+++ b/ppc64.c
@@ -74,6 +74,7 @@ static ulong pud_page_vaddr_l4(ulong pud);
static ulong pmd_page_vaddr_l4(ulong pmd);
static int is_opal_context(ulong sp, ulong nip);
void opalmsg(void);
+static bool is_ppc64_elf_abi_v2(void);
struct user_regs_bitmap_struct {
struct ppc64_pt_regs ur;
@@ -3035,6 +3036,25 @@ ppc64_get_sp(ulong task)
return sp;
}
+static bool
+is_ppc64_elf_abi_v2(void)
+{
+ static bool ret = false;
+ static bool checked = false;
+
+ if (checked)
+ return ret;
+ switch (file_elf_header(pc->namelist, "e_flags")) {
+ case 2:
+ ret = true;
+ case 1:
+ break;
+ default:
+ error(WARNING, "Unknown e_flags for v1/v2 elf_abi detection.\n");
+ }
+ checked = true;
+ return ret;
+}
/*
* get the SP and PC values for idle tasks.
@@ -3056,9 +3076,17 @@ get_ppc64_frame(struct bt_info *bt, ulong *getpc, ulong *getsp)
sp = ppc64_get_sp(task);
if (!INSTACK(sp, bt))
goto out;
- readmem(sp+STACK_FRAME_OVERHEAD, KVADDR, ®s,
- sizeof(struct ppc64_pt_regs),
- "PPC64 pt_regs", FAULT_ON_ERROR);
+
+ if (THIS_KERNEL_VERSION >= LINUX(6,2,0) && is_ppc64_elf_abi_v2()) {
+ readmem(sp+STACK_SWITCH_FRAME_REGS, KVADDR, ®s,
+ sizeof(struct ppc64_pt_regs),
+ "PPC64 pt_regs", FAULT_ON_ERROR);
+ } else {
+ readmem(sp+STACK_FRAME_OVERHEAD, KVADDR, ®s,
+ sizeof(struct ppc64_pt_regs),
+ "PPC64 pt_regs", FAULT_ON_ERROR);
+ }
+
ip = regs.nip;
closest = closest_symbol(ip);
if (STREQ(closest, ".__switch_to") || STREQ(closest, "__switch_to")) {
diff --git a/symbols.c b/symbols.c
index 480fdb6..0a11c2f 100644
--- a/symbols.c
+++ b/symbols.c
@@ -217,7 +217,7 @@ symtab_init(void)
* Check whether the namelist is a kerntypes file built by
* dwarfextract, which places a magic number in e_version.
*/
- if (file_elf_version(pc->namelist) == EV_DWARFEXTRACT)
+ if (file_elf_header(pc->namelist, "e_version") == EV_DWARFEXTRACT)
pc->flags |= KERNTYPES;
if (pc->flags & SYSMAP) {
@@ -13149,7 +13149,8 @@ load_module_symbols(char *modref, char *namelist, ulong base_addr)
error(FATAL, "cannot determine object file format: %s\n",
namelist);
- if (LKCD_KERNTYPES() && (file_elf_version(namelist) == EV_DWARFEXTRACT))
+ if (LKCD_KERNTYPES() &&
+ (file_elf_header(namelist, "e_version") == EV_DWARFEXTRACT))
goto add_symbols; /* no symbols, add the debuginfo */
if (!(bfd_get_file_flags(mbfd) & HAS_SYMS))
--
2.47.0
3 weeks
Decoding Consumer Minds: Fresh Ideas for Marketing Research Papers
by kefag22407＠haotuwu.com
Marketing is no longer just about selling — it’s about understanding why people buy, share, and stay loyal. Research papers in marketing can dive into fascinating areas like consumer psychology, digital engagement, and emotional branding. Exploring topics such as the impact of social media influencers on brand perception, consumer trust in AI-driven recommendations, or sustainability as a driver of purchase intent can help uncover what really shapes modern consumer decisions.
Another promising angle is studying data and personalization in marketing. With companies relying heavily on analytics, there’s a growing need to explore how data-driven strategies influence consumer experience and brand loyalty. Researching ethical data usage, AI in customer segmentation, or neuromarketing trends can lead to insights that bridge creativity with strategy — essential for any marketer looking to make an impact in today’s competitive landscape. Have more info at: https://thedissertationhelp.co.uk/marketing-research-paper-topics/
3 weeks, 6 days
Behind the Scenes of Campus Data Centers: Insights from Crash Utility Practices
by yingashley13＠gmail.com
Modern universities rely heavily on digital infrastructure to keep classrooms, online platforms, and administrative systems running smoothly. While students and faculty experience seamless access to online courses, virtual libraries, and academic portals, much of this reliability comes from what happens behind the scenes—specifically within campus data centers. These centers serve as the backbone of digital learning, ensuring continuous access to resources, stable performance, and quick recovery during system failures.
In higher education, the importance of uninterrupted online learning cannot be overstated. Many students, for instance, rely on platforms like Myassignmenthelp for academic support, where they might search for options such as take my online class for me (https://myassignmenthelp.com/take-my-online-class.html
). This highlights how critical system reliability is for educational services, whether hosted directly by universities or through third-party academic support platforms. Without dependable infrastructure, both students and institutions risk losing valuable time, resources, and learning opportunities.
This is where practices drawn from tools like the Crash Utility come into play. Originally designed for analyzing Linux kernel crash dumps, these tools provide system administrators with detailed insights into why systems fail. For campus data centers, adopting similar diagnostic approaches allows IT teams to quickly identify the root cause of failures, prevent recurring issues, and maintain high system availability. In turn, this ensures that students can log into their learning portals, submit assignments, and access lecture recordings without disruption.
Moreover, proactive crash analysis fosters a culture of resilience within educational institutions. Instead of waiting for problems to escalate, IT administrators can anticipate potential bottlenecks or vulnerabilities and resolve them before they affect users. For universities striving to enhance their digital infrastructure, integrating such practices strengthens their ability to support large-scale e-learning initiatives, hybrid classrooms, and research collaborations.
In conclusion, while students may only see the front-end of digital learning systems, the true strength of an institution lies in its backend stability. By incorporating insights from crash utility practices, campus data centers can ensure smooth, uninterrupted academic experiences—making education more accessible, reliable, and future-ready.
1 month
[PATCH] Fix "timer -r" option on Linux 6.18 and later kernels
by HAGIO KAZUHITO(萩尾 一仁)
Kernel commit 009eb5da29a9 ("hrtimer: Remove hrtimer_clock_base::
Get_time") removed the get_time member from struct hrtimer_clock_base.
As a result, the "timer -r" option fails with the following error:
crash> timer -r
timer: invalid structure member offset: hrtimer_clock_base_get_time
FILE: kernel.c LINE: 7953 FUNCTION: dump_hrtimer_clock_base()
As the get_time function is switched by __hrtimer_cb_get_time() function
with clock_id macro value, crash cannot follow their changes
automatically. So change what "timer -r" displays there from the
get_time function name to enum hrtimer_base_type name.
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
I refered to page_flags_init_from_pageflags_enum() function to use
dump_enumerator_list(), pc->flags2 and etc.
defs.h | 1 +
kernel.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++----
symbols.c | 2 ++
3 files changed, 73 insertions(+), 5 deletions(-)
diff --git a/defs.h b/defs.h
index ab4aee8520a7..7f87e8e939e9 100644
--- a/defs.h
+++ b/defs.h
@@ -2280,6 +2280,7 @@ struct offset_table { /* stash of commonly-used offsets */
long bpf_ringbuf_map_rb;
long bpf_ringbuf_consumer_pos;
long bpf_ringbuf_nr_pages;
+ long hrtimer_clock_base_index;
};
struct size_table { /* stash of commonly-used sizes */
diff --git a/kernel.c b/kernel.c
index 13f33742990e..ec287bb55c05 100644
--- a/kernel.c
+++ b/kernel.c
@@ -43,6 +43,7 @@ static void display_bh_1(void);
static void display_bh_2(void);
static void display_bh_3(void);
static void display_bh_4(void);
+static int hrtimer_base_type_init(void);
static void dump_hrtimer_data(const ulong *cpus);
static void dump_hrtimer_clock_base(const void *, const int);
static void dump_hrtimer_base(const void *, const int);
@@ -796,6 +797,12 @@ kernel_init()
"hrtimer_clock_base", "first");
MEMBER_OFFSET_INIT(hrtimer_clock_base_get_time,
"hrtimer_clock_base", "get_time");
+ if (INVALID_MEMBER(hrtimer_clock_base_get_time)) {
+ /* Linux 6.18: 009eb5da29a9 */
+ MEMBER_OFFSET_INIT(hrtimer_clock_base_index, "hrtimer_clock_base", "index");
+ if (!hrtimer_base_type_init())
+ error(WARNING, "cannot get enum hrtimer_base_type\n");
+ }
}
STRUCT_SIZE_INIT(hrtimer_base, "hrtimer_base");
@@ -7938,6 +7945,52 @@ static int expires_len = -1;
static int softexpires_len = -1;
static int tte_len = -1;
+static char **hrtimer_base_type = NULL;
+static int
+hrtimer_base_type_init(void)
+{
+ long max_bases;
+ int i, c ATTRIBUTE_UNUSED;
+ char buf[BUFSIZE];
+ char *arglist[MAXARGS];
+
+ if (!enumerator_value("HRTIMER_MAX_CLOCK_BASES", &max_bases))
+ return FALSE;
+
+ hrtimer_base_type = (char **)calloc(max_bases, sizeof(char *));
+ if (!hrtimer_base_type)
+ return FALSE;
+
+ pc->flags2 |= ALLOW_FP; /* Required during initialization */
+ open_tmpfile();
+ if (dump_enumerator_list("hrtimer_base_type")) {
+ rewind(pc->tmpfile);
+ while (fgets(buf, BUFSIZE, pc->tmpfile)) {
+ if (!strstr(buf, " = "))
+ continue;
+ c = parse_line(buf, arglist);
+ i = atoi(arglist[2]);
+ if (0 <= i && i < max_bases)
+ hrtimer_base_type[i] = strdup(arglist[0]);
+ }
+ close_tmpfile();
+ pc->flags2 &= ~ALLOW_FP;
+ } else {
+ close_tmpfile();
+ pc->flags2 &= ~ALLOW_FP;
+ free(hrtimer_base_type);
+ hrtimer_base_type = NULL;
+ return FALSE;
+ }
+
+ if (CRASHDEBUG(1)) {
+ for (i = 0; i < max_bases; i++)
+ fprintf(fp, "hrtimer_base_type[%d] = %s\n", i, hrtimer_base_type[i]);
+ }
+
+ return TRUE;
+}
+
static void
dump_hrtimer_clock_base(const void *hrtimer_bases, const int num)
{
@@ -7949,11 +8002,23 @@ dump_hrtimer_clock_base(const void *hrtimer_bases, const int num)
base = (void *)hrtimer_bases + OFFSET(hrtimer_cpu_base_clock_base) +
SIZE(hrtimer_clock_base) * num;
- readmem((ulong)(base + OFFSET(hrtimer_clock_base_get_time)), KVADDR,
- &get_time, sizeof(get_time), "hrtimer_clock_base get_time",
- FAULT_ON_ERROR);
- fprintf(fp, " CLOCK: %d HRTIMER_CLOCK_BASE: %lx [%s]\n", num,
- (ulong)base, value_to_symstr(get_time, buf, 0));
+
+ if (INVALID_MEMBER(hrtimer_clock_base_get_time)) {
+ /* Linux 6.18: 009eb5da29a9 */
+ if (hrtimer_base_type) {
+ uint index;
+ readmem((ulong)(base + OFFSET(hrtimer_clock_base_index)), KVADDR, &index,
+ sizeof(index), "hrtimer_clock_base index", FAULT_ON_ERROR);
+ fprintf(fp, " CLOCK: %d HRTIMER_CLOCK_BASE: %lx [%s]\n", num,
+ (ulong)base, hrtimer_base_type[index]);
+ } else
+ fprintf(fp, " CLOCK: %d HRTIMER_CLOCK_BASE: %lx\n", num, (ulong)base);
+ } else {
+ readmem((ulong)(base + OFFSET(hrtimer_clock_base_get_time)), KVADDR, &get_time,
+ sizeof(get_time), "hrtimer_clock_base get_time", FAULT_ON_ERROR);
+ fprintf(fp, " CLOCK: %d HRTIMER_CLOCK_BASE: %lx [%s]\n", num,
+ (ulong)base, value_to_symstr(get_time, buf, 0));
+ }
/* get current time(uptime) */
get_uptime(NULL, ¤t_time);
diff --git a/symbols.c b/symbols.c
index 480fdb6d98b3..c446beb43a76 100644
--- a/symbols.c
+++ b/symbols.c
@@ -11760,6 +11760,8 @@ dump_offset_table(char *spec, ulong makestruct)
OFFSET(hrtimer_clock_base_first));
fprintf(fp, " hrtimer_clock_base_get_time: %ld\n",
OFFSET(hrtimer_clock_base_get_time));
+ fprintf(fp, " hrtimer_clock_base_index: %ld\n",
+ OFFSET(hrtimer_clock_base_index));
fprintf(fp, " hrtimer_base_first: %ld\n",
OFFSET(hrtimer_base_first));
fprintf(fp, " hrtimer_base_pending: %ld\n",
--
2.31.1
1 month
[PATCH] Fix typo: uncompess -> uncompress
by Dominique Martinet
---
Not much to say about this, just happened to run into that building an
aarch64 crash for testing and forgetting to add zstd flag -- thanks for
the cross build option, that was great! :)
diskdump.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/diskdump.c b/diskdump.c
index de907551153d..5d3ef81fc607 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -1368,7 +1368,7 @@ cache_page(physaddr_t paddr)
} else if (pd.flags & DUMP_DH_COMPRESSED_ZSTD) {
if (!(dd->flags & ZSTD_SUPPORTED)) {
- error(INFO, "%s: uncompess failed: no zstd compression support\n",
+ error(INFO, "%s: uncompress failed: no zstd compression support\n",
DISKDUMP_VALID() ? "diskdump" : "compressed kdump");
return READ_ERROR;
}
@@ -1376,7 +1376,7 @@ cache_page(physaddr_t paddr)
if (!dctx) {
dctx = ZSTD_createDCtx();
if (!dctx) {
- error(INFO, "%s: uncompess failed: cannot create ZSTD_DCtx\n",
+ error(INFO, "%s: uncompress failed: cannot create ZSTD_DCtx\n",
DISKDUMP_VALID() ? "diskdump" : "compressed kdump");
return READ_ERROR;
}
--
2.47.3
1 month
Tiché proměny v digitálním světě a cesty za novými zážitky
by lindyhearter＠gmail.com
V posledních letech se mění způsoby, jak lidé tráví volný čas, komunikují a objevují nové příležitosti. Mnoho cestovatelů a nadšenců do technologií sleduje, jak rychle se vyvíjí online prostředí a jak se stále více propojuje s každodenním životem. Přitom se objevují i nové trendy v oblasti zábavy a digitálních služeb, mezi nimiž se na okraji pozornosti ocitají i zahraniční kasina přijímající hráče z EU, která se s nástupem roku 2025 často zmiňují v kontextu technologických inovací a bezpečnostních standardů v Evropě. I když tato téma není pro každého, je součástí širšího obrazu změn ve způsobu, jak lidé využívají online platformy.
Když se mluví o cestování po Evropě a o kulturním bohatství jednotlivých regionů, nelze přehlédnout, že digitální platformy usnadňují plánování a přístup k nejrůznějším službám. Turisté, obchodníci i ti, kteří pracují vzdáleně, si stále více uvědomují výhody online možností. Do těchto souvislostí se někdy přidávají také zahraniční kasina přijímající hráče z EU, která bývají srovnávána s jinými formami zábavy dostupnými v různých evropských zemích. Ať už člověk preferuje kulturní památky, gastronomii nebo jen touží po odpočinku ve wellness centrech, rozmanitost nabízených zážitků je dnes širší než kdy dříve.
Evropské metropole lákají díky pohodlí dopravy, bohaté historii a pestré nabídce akcí. Kromě tradičních atrakcí se do povědomí dostávají i technologie, které proměňují způsob, jak lidé tráví volný čas. V diskusích o digitální bezpečnosti a evropských standardech důvěry se čas od času zmiňují také zahraniční kasina přijímající hráče z EU, především v souvislosti s tím, jak se vyvíjí přístup k regulacím, odpovědnosti a transparentnosti ve službách, které fungují napříč hranicemi. Tato témata se často přirozeně objevují při úvahách o tom, co se očekává od nejmodernějších digitálních projektů v roce 2025.
Při cestování Evropou mnoho návštěvníků vyhledává nejen historické památky či kulturní zážitky, ale také nové trendy v oblasti digitálního prostředí. Česká republika je známá tím, že spojuje tradici s moderním přístupem, což lze vidět ve městech jako Praha, Brno nebo Ostrava. Zatímco Praha láká svou architekturou a kulturním dědictvím, Brno je oceňováno pro technologické inovace a dynamický studentský život. V některých městech se lze setkat i se zmínkami o tom, jak se český přístup k regulacím a transparentnosti liší od jiných evropských států, a to i pokud jde o oblasti jako kasina v České republice, které se objevují spíše okrajově v debatách o odpovědném digitálním prostředí.
V souvislosti s rokem 2025 se často hovoří o vývoji nových standardů bezpečnosti dat, osobní ochrany a digitalizace služeb. Mnoho odborníků očekává, že evropské země budou i nadále určovat směr v otázkách regulací a férového přístupu k poskytování služeb na online platformách. Tento směr má dopad na mnoho odvětví – od bankovnictví a zdravotnictví až po oblast zábavy a technologií. Témata jako Nejlepší kasina pro rok 2025 jsou v médiích diskutována spíše z pohledu technologického pokroku, kvality zákaznické podpory a moderních bezpečnostních standardů, což je přístup, který odráží evropské hodnoty orientované na transparentnost.
Česká republika je v mnoha směrech aktivní součástí digitální transformace. Rozvoj chytré infrastruktury, technologických parků a vzdělávacích center dokazují, že investice do inovací mají dlouhodobý dopad na ekonomiku i každodenní život. Díky silnému akademickému zázemí a schopnosti přizpůsobit se trendům se české prostředí stává atraktivním pro zahraniční firmy a projekty z různých odvětví. Přestože debaty o kasinech v České republice nebo o evropských online službách se mohou objevovat v tisku, většina diskuse se soustředí především na širší ekonomický a technologický přínos, nikoli na samotnou zábavní rovinu.
Evropa v poslední době čelí rychlému rozvoji digitálních technologií, umělé inteligence a online vzdělávání. Společně s tím vznikají diskuse o tom, jak zajistit spravedlivé podmínky pro všechny uživatele a jak nastavit pravidla pro služby, které působí https://www.veteran-veterani.cz/ napříč geografickými hranicemi. Česká republika se aktivně podílí na těchto jednáních a snaží se vytvořit prostředí, které bude přátelské pro podnikání i běžné občany. Budoucnost roku 2025 je spojována s tím, že Evropa bude nadále podporovat inovace bez ohledu na odvětví a zároveň si zachová své hodnoty.
Když se ohlédneme zpět, vidíme, že každá etapa technologického vývoje přinášela nové otázky a výzvy. Stejně jako se kdysi diskutovalo o digitalizaci dopravy nebo zdravotnictví, dnes probíhá debata o tom, jak zajistit bezpečné a férové prostředí pro různé digitální služby. Ať už se jedná o online vzdělávání, kulturní platformy nebo projekty zaměřené na inovace v oblasti zábavy, hlavní pozornost se soustředí na uživatelské pohodlí, dostupnost, bezpečnost a odpovědnou správu dat. Evropa i Česká republika tak pokračují v cestě, která směřuje ke kvalitnějším a transparentním digitálním službám.
1 month
[PATCH] Fix for "runq -g" option failure
by Lianbo Jiang
The "runq -g" option may fail on some vmcores from customers, and report
the following error:
crash> runq -g
...
malloc_bp[1998]: 11592c20
malloc_bp[1999]: 11662490
...
average size: 11922
runq: cannot allocate any more memory!
This is because the maximum number of malloc() was reached through
GETBUF(), currently which is limited to MAX_MALLOC_BUFS(2000).
Furthermore, the error messages is not very clear.
Given that, let's expand the limitation of MAX_MALLOC_BUFS and make the
error message clear and concise.
With the patch:
crash> runq -g
...
CPU 95
CURRENT: PID: 64281 TASK: ffff9f541b064000 COMMAND: "xxx_64281_sv"
ROOT_TASK_GROUP: ffffffffa64ff940 RT_RQ: ffff9f86bfdf3a80
[no tasks queued]
ROOT_TASK_GROUP: ffffffffa64ff940 CFS_RQ: ffff9f86bfdf38c0
[120] PID: 64281 TASK: ffff9f541b064000 COMMAND: "xxx_64281_sv" [CURRENT]
TASK_GROUP: ffff9f47cb3b9180 CFS_RQ: ffff9f67c0417a00 <user.slice>
[120] PID: 65275 TASK: ffff9f6820208000 COMMAND: "server"
TASK_GROUP: ffff9f67f9ac2300 CFS_RQ: ffff9f6803662000 <oratfagroup>
[120] PID: 1209636 TASK: ffff9f582f25c000 COMMAND: "crsctl"
Reported-by: Buland Kumar Singh <bsingh(a)redhat.com>
Signed-off-by: Lianbo Jiang <lijiang(a)redhat.com>
---
tools.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools.c b/tools.c
index a9ad18d520d9..6676881c182a 100644
--- a/tools.c
+++ b/tools.c
@@ -5698,7 +5698,7 @@ ll_power(long long base, long long exp)
#define B32K (4)
#define SHARED_BUF_SIZES (B32K+1)
-#define MAX_MALLOC_BUFS (2000)
+#define MAX_MALLOC_BUFS (3072)
#define MAX_CACHE_SIZE (KILOBYTES(32))
struct shared_bufs {
@@ -6130,7 +6130,7 @@ getbuf(long reqsize)
dump_shared_bufs();
return ((char *)(long)
- error(FATAL, "cannot allocate any more memory!\n"));
+ error(FATAL, "cannot allocate any more memory, reached to max numbers of malloc() via GETBUF()!\n"));
}
/*
--
2.51.1
1 month, 1 week
[PATCH] Revert "vmcoreinfo: read vmcoreinfo using 'vmcoreinfo_data' when unavailable in elf note"
by Tao Liu
This patch will cause a regression on some x86_64 vmcores.
$ crash -s vmcore vmlinux.gz
WARNING: vmcoreinfo is empty, will read from symbols
crash: cannot malloc vmcoreinfo buffer
crash: /var/tmp/vmlinux.gz_fWV3kA and vmcore do not match!
The root cause is, in main.c, is_kdump() calls is_netdump(), which will
set pc->read_vmcoreinfo as vmcoreinfo_read_from_memory(), rather than
original vmcoreinfo_read_string().
Later in machdep_init(PRE_SYMTAB), vmcoreinfo_read_from_memory() doesn't
get "relocate" string, so fails for set kaslr flag, then fails for
linux_banner detection:
Thread 1 "crash" hit Breakpoint 2, verify_version ():
1096 if (!IS_KVADDR(linux_banner))
(gdb) p/x linux_banner
$4 = 0xffffffff81e00100
crash> sym linux_banner
ffffffff9aa00100 (R) linux_banner
As we can see with the patch applied, linux_banner got a wrong address.
So this patch currently is unsafe, and should be reverted before the fix.
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
Since it is too close to the new release date of crash utility, I don't
have enough time for full root cause analysis and re-testing. So currently
the best option is to revert it for now, and fix it in the next release then
re-apply.
---
defs.h | 1 -
diskdump.c | 18 ------------------
kernel.c | 17 +++++------------
netdump.c | 19 -------------------
4 files changed, 5 insertions(+), 50 deletions(-)
diff --git a/defs.h b/defs.h
index ab4aee8..ae6ea01 100644
--- a/defs.h
+++ b/defs.h
@@ -6225,7 +6225,6 @@ void dump_kernel_table(int);
void dump_bt_info(struct bt_info *, char *where);
void dump_log(int);
void parse_kernel_version(char *);
-char *vmcoreinfo_read_from_memory(const char *);
#define LOG_LEVEL(v) ((v) & 0x07)
#define SHOW_LOG_LEVEL (0x1)
diff --git a/diskdump.c b/diskdump.c
index de90755..ce3cbb7 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -1041,13 +1041,6 @@ pfn_to_pos(ulong pfn)
return desc_pos;
}
-/**
- * Check if vmcoreinfo in vmcore is missing/empty
- */
-static bool is_diskdump_vmcoreinfo_empty(void)
-{
- return (dd->sub_header_kdump->size_vmcoreinfo == 0);
-}
/*
* Determine whether a file is a diskdump creation, and if TRUE,
@@ -1095,17 +1088,6 @@ is_diskdump(char *file)
pc->read_vmcoreinfo = vmcoreinfo_read_string;
- /*
- * vmcoreinfo can be empty in case of dump collected via virsh-dump
- *
- * check if vmcoreinfo is not available in vmcore, and try to read
- * the vmcoreinfo from memory, using "vmcoreinfo_data" symbol
- */
- if (is_diskdump_vmcoreinfo_empty()) {
- error(WARNING, "vmcoreinfo is empty, will read from symbols\n");
- pc->read_vmcoreinfo = vmcoreinfo_read_from_memory;
- }
-
if ((pc->flags2 & GET_LOG) && KDUMP_CMPRS_VALID()) {
pc->dfd = dd->dfd;
pc->readmem = read_diskdump;
diff --git a/kernel.c b/kernel.c
index 13f3374..e077275 100644
--- a/kernel.c
+++ b/kernel.c
@@ -99,6 +99,7 @@ static ulong dump_audit_skb_queue(ulong);
static ulong __dump_audit(char *);
static void dump_audit(void);
static void dump_printk_safe_seq_buf(int);
+static char *vmcoreinfo_read_string(const char *);
static void check_vmcoreinfo(void);
static int is_pvops_xen(void);
static int get_linux_banner_from_vmlinux(char *, size_t);
@@ -11894,8 +11895,8 @@ dump_printk_safe_seq_buf(int msg_flags)
* Returns a string (that has to be freed by the caller) that contains the
* value for key or NULL if the key has not been found.
*/
-char *
-vmcoreinfo_read_from_memory(const char *key)
+static char *
+vmcoreinfo_read_string(const char *key)
{
char *buf, *value_string, *p1, *p2;
size_t value_length;
@@ -11905,14 +11906,6 @@ vmcoreinfo_read_from_memory(const char *key)
buf = value_string = NULL;
- if (!(pc->flags & GDB_INIT)) {
- /*
- * GDB interface hasn't been initialised yet, so can't
- * access vmcoreinfo_data
- */
- return NULL;
- }
-
switch (get_symbol_type("vmcoreinfo_data", NULL, NULL))
{
case TYPE_CODE_PTR:
@@ -11968,10 +11961,10 @@ check_vmcoreinfo(void)
switch (get_symbol_type("vmcoreinfo_data", NULL, NULL))
{
case TYPE_CODE_PTR:
- pc->read_vmcoreinfo = vmcoreinfo_read_from_memory;
+ pc->read_vmcoreinfo = vmcoreinfo_read_string;
break;
case TYPE_CODE_ARRAY:
- pc->read_vmcoreinfo = vmcoreinfo_read_from_memory;
+ pc->read_vmcoreinfo = vmcoreinfo_read_string;
break;
}
}
diff --git a/netdump.c b/netdump.c
index 69100a9..c7ff009 100644
--- a/netdump.c
+++ b/netdump.c
@@ -111,14 +111,6 @@ map_cpus_to_prstatus(void)
FREEBUF(nt_ptr);
}
-/**
- * Check if vmcoreinfo in vmcore is missing/empty
- */
-static bool is_netdump_vmcoreinfo_empty(void)
-{
- return (nd->size_vmcoreinfo == 0);
-}
-
/*
* Determine whether a file is a netdump/diskdump/kdump creation,
* and if TRUE, initialize the vmcore_data structure.
@@ -472,17 +464,6 @@ is_netdump(char *file, ulong source_query)
pc->read_vmcoreinfo = vmcoreinfo_read_string;
- /*
- * vmcoreinfo can be empty in case of dump collected via virsh-dump
- *
- * check if vmcoreinfo is not available in vmcore, and try to read
- * the vmcoreinfo from memory, using "vmcoreinfo_data" symbol
- */
- if (is_netdump_vmcoreinfo_empty()) {
- error(WARNING, "vmcoreinfo is empty, will read from symbols\n");
- pc->read_vmcoreinfo = vmcoreinfo_read_from_memory;
- }
-
if ((source_query == KDUMP_LOCAL) &&
(pc->flags2 & GET_OSRELEASE))
kdump_get_osrelease();
--
2.47.0
1 month, 2 weeks