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.
4 days, 15 hours
[PATCH] Fix for "set" command failure
by Lianbo Jiang
Recently we have observed some failures as below:
crash> set 2276866
set: invalid kernel virtual address: 0 type: "stack contents"
set: read of stack at 0 failed
crash> ps 2276866
PID PPID CPU TASK ST %MEM VSZ RSS COMM
2276866 2276750 47 ff3a19fbd3c80000 ZO 0.0 0 0 sh
This is a regression issue that introduced by adding gdb stack unwind
support. When attempting to read from the stack, firstly, need to check
if the stack exists, otherwise it may fail in some corner cases. E.g:
there are some zombie processes(ZO) and the stack does not exist.
Furthermore this may also break the switching thread in gdb.
With the patch:
crash> set 2276866
PID: 2276866
COMMAND: "sh"
TASK: ff3a19fbd3c80000 [THREAD_INFO: ff3a19fbd3c80000]
CPU: 47
STATE: EXIT_DEAD|EXIT_ZOMBIE
Reported-by: Buland Kumar Singh <bsingh(a)redhat.com>
Signed-off-by: Lianbo Jiang <lijiang(a)redhat.com>
---
arm64.c | 2 ++
ppc64.c | 2 ++
x86_64.c | 2 ++
3 files changed, 6 insertions(+)
diff --git a/arm64.c b/arm64.c
index 354d17ab6a19..17235950bb60 100644
--- a/arm64.c
+++ b/arm64.c
@@ -234,6 +234,8 @@ arm64_get_current_task_reg(int regno, const char *name,
BZERO(&bt_setup, sizeof(struct bt_info));
clone_bt_info(&bt_setup, &bt_info, tc);
+ if (bt_info.stackbase == 0)
+ return FALSE;
fill_stackbuf(&bt_info);
get_dumpfile_regs(&bt_info, &sp, &ip);
diff --git a/ppc64.c b/ppc64.c
index d1a506773c93..9c5c0a460c7a 100644
--- a/ppc64.c
+++ b/ppc64.c
@@ -2606,6 +2606,8 @@ ppc64_get_current_task_reg(int regno, const char *name, int size,
BZERO(&bt_setup, sizeof(struct bt_info));
clone_bt_info(&bt_setup, &bt_info, tc);
+ if (bt_info.stackbase == 0)
+ return FALSE;
fill_stackbuf(&bt_info);
// reusing the get_dumpfile_regs function to get pt regs structure
diff --git a/x86_64.c b/x86_64.c
index d7da536d20d8..b2cddbf8ba3d 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -9383,6 +9383,8 @@ x86_64_get_current_task_reg(int regno, const char *name,
BZERO(&bt_setup, sizeof(struct bt_info));
clone_bt_info(&bt_setup, &bt_info, tc);
+ if (bt_info.stackbase == 0)
+ return FALSE;
fill_stackbuf(&bt_info);
// reusing the get_dumpfile_regs function to get pt regs structure
--
2.50.1
1 month
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/
1 month, 1 week
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/
1 month, 1 week
[PATCH v2] vmcoreinfo: read vmcoreinfo using 'vmcoreinfo_data' when unavailable in elf note
by Aditya Gupta
Few vmcores don't have vmcoreinfo elf note, such as those created using
virsh-dump.
On architectures such as PowerPC64, vmcoreinfo is mandatory to fetch the
first_vmalloc_address, for vmcores of upstream linux, since crash-utility commit:
commit 5b24e363a898 ("get vmalloc start address from vmcoreinfo")
Try reading from the 'vmcoreinfo_data' symbol instead, if the vmcoreinfo
crash tries to read in case of diskdump/netdump is empty/missing.
The approach to read 'vmcoreinfo_data' was used for a live kernel, which can be
reused in the case of missing vmcoreinfo note also, as the
'vmcoreinfo_data' symbol is available with vmcore too
Note though, till GDB interface is not initialised, reading from
vmcoreinfo_data symbol is not done, so behaviour is same as previously
with no vmcoreinfo (only till GDB interface is not initialised)
Hence rename 'vmcoreinfo_read_string' in kernel.c to
'vmcoreinfo_read_from_memory', and use it in netdump.c and diskdump.c
too.
Reported-by: Anushree Mathur <anushree.mathur(a)linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur(a)linux.ibm.com>
Signed-off-by: Aditya Gupta <adityag(a)linux.ibm.com>
---
Changelog
=========
v2:
+ rename 'is_vmcoreinfo_empty' to netdump/diskdump variants in
netdump.c and diskdump.c respectively
---
---
defs.h | 1 +
diskdump.c | 18 ++++++++++++++++++
kernel.c | 17 ++++++++++++-----
netdump.c | 19 +++++++++++++++++++
4 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/defs.h b/defs.h
index 156ac0232906..d28484ec44f9 100644
--- a/defs.h
+++ b/defs.h
@@ -6218,6 +6218,7 @@ 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 ce3cbb7b12dd..de907551153d 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -1041,6 +1041,13 @@ 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,
@@ -1088,6 +1095,17 @@ 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 e4213d7a663e..0e17874c503c 100644
--- a/kernel.c
+++ b/kernel.c
@@ -99,7 +99,6 @@ 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);
@@ -11892,8 +11891,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.
*/
-static char *
-vmcoreinfo_read_string(const char *key)
+char *
+vmcoreinfo_read_from_memory(const char *key)
{
char *buf, *value_string, *p1, *p2;
size_t value_length;
@@ -11903,6 +11902,14 @@ vmcoreinfo_read_string(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:
@@ -11958,10 +11965,10 @@ check_vmcoreinfo(void)
switch (get_symbol_type("vmcoreinfo_data", NULL, NULL))
{
case TYPE_CODE_PTR:
- pc->read_vmcoreinfo = vmcoreinfo_read_string;
+ pc->read_vmcoreinfo = vmcoreinfo_read_from_memory;
break;
case TYPE_CODE_ARRAY:
- pc->read_vmcoreinfo = vmcoreinfo_read_string;
+ pc->read_vmcoreinfo = vmcoreinfo_read_from_memory;
break;
}
}
diff --git a/netdump.c b/netdump.c
index c7ff009e7f90..69100a92e067 100644
--- a/netdump.c
+++ b/netdump.c
@@ -111,6 +111,14 @@ 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.
@@ -464,6 +472,17 @@ 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.50.1
1 month, 1 week
Re: [PATCH] RISCV64: fix wrong information of PMD and PTE - SA39(4K page) support
by lijiang
Hi, Austin
Thank you for the patch.
On Wed, Oct 22, 2025 at 6:00 PM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Wed, 22 Oct 2025 11:46:19 +0900
> From: Austin Kim <austindh.kim(a)gmail.com>
> Subject: [Crash-utility] [PATCH] RISCV64: fix wrong information of PMD
> and PTE - SA39(4K page) support
> To: devel(a)lists.crash-utility.osci.io
> Cc: austindh.kim(a)gmail.com
> Message-ID: <aPhFe2nFOb1qlY8h@adminpc-PowerEdge-R7525>
> Content-Type: text/plain; charset=us-ascii
>
> When running 'vtop address' command in RISC-V based vmcore, the base
> address
> without applying offset for PMD and PTE is displayed. This is not correct
> address for PMD and PTE.
>
>
This change looks good to me. So: Ack.
BTW: I haven't seen any similar changes on 4level_4k and 5level_4k, isn't
it necessary? Or can you also take a look?
Thanks
Lianbo
> With this patch, the actual address for PMD and PTE with the valid offset
> is printed:
>
> <Before>
> crash> vtop 0xffffffff81c4f000
> VIRTUAL PHYSICAL
> ffffffff81c4f000 41e4f000
>
> PAGE DIRECTORY: ffffffff81c4f000
> PGD: ffffffff81c4fff0 => 4fffe801
> PMD: 000000013fffa000 => 00000000107800e7
> PTE: 41e00000 => ffffffff8166fea0
>
> PTE PAGE: 0000000000000000 not present
>
> <After>
> crash> vtop 0xffffffff81c4f000
> VIRTUAL PHYSICAL
> ffffffff81c4f000 41e4f000
>
> PAGE DIRECTORY: ffffffff81c4f000
> PGD: ffffffff81c4fff0 => 4fffe801
> PMD: 000000013fffa070 => 00000000107800e7
> PTE: 41e00278 => ffffffff8166fea0
>
> PTE PAGE: 0000000000000000 not present
>
> Signed-off-by: Austin Kim <austindh.kim(a)gmail.com>
> ---
> riscv64.c | 25 ++++++++++++-------------
> 1 file changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/riscv64.c b/riscv64.c
> index ef5c41d..6b89f0b 100644
> --- a/riscv64.c
> +++ b/riscv64.c
> @@ -630,9 +630,8 @@ static int
> riscv64_vtop_3level_4k(ulong *pgd, ulong vaddr, physaddr_t *paddr, int
> verbose)
> {
> ulong *pgd_ptr, pgd_val;
> - ulong pmd_val;
> - ulong pte_val, pte_pfn;
> - ulong pt_phys;
> + ulong pmd_base, pmd_addr, pmd_val;
> + ulong pte_base, pte_addr, pte_val, pte_pfn;
>
> if (verbose)
> fprintf(fp, "PAGE DIRECTORY: %lx\n", (ulong)pgd);
> @@ -646,25 +645,25 @@ riscv64_vtop_3level_4k(ulong *pgd, ulong vaddr,
> physaddr_t *paddr, int verbose)
> if (!pgd_val)
> goto no_page;
> pgd_val &= PTE_PFN_PROT_MASK;
> - pt_phys = (pgd_val >> _PAGE_PFN_SHIFT) << PAGESHIFT();
> + pmd_base = (pgd_val >> _PAGE_PFN_SHIFT) << PAGESHIFT();
>
> /* PMD */
> - FILL_PMD(PAGEBASE(pt_phys), PHYSADDR, PAGESIZE());
> - pmd_val = ULONG(machdep->pmd + PAGEOFFSET(sizeof(pmd_t) *
> - pmd_index_l3_4k(vaddr)));
> + FILL_PMD(PAGEBASE(pmd_base), PHYSADDR, PAGESIZE());
> + pmd_addr = pmd_base + sizeof(pmd_t) * pmd_index_l3_4k(vaddr);
> + pmd_val = ULONG(machdep->pmd + PAGEOFFSET(pmd_addr));
> if (verbose)
> - fprintf(fp, " PMD: %016lx => %016lx\n", pt_phys, pmd_val);
> + fprintf(fp, " PMD: %016lx => %016lx\n", pmd_addr,
> pmd_val);
> if (!pmd_val)
> goto no_page;
> pmd_val &= PTE_PFN_PROT_MASK;
> - pt_phys = (pmd_val >> _PAGE_PFN_SHIFT) << PAGESHIFT();
> + pte_base = (pmd_val >> _PAGE_PFN_SHIFT) << PAGESHIFT();
>
> /* PTE */
> - FILL_PTBL(PAGEBASE(pt_phys), PHYSADDR, PAGESIZE());
> - pte_val = ULONG(machdep->ptbl + PAGEOFFSET(sizeof(pte_t) *
> - pte_index_l3_4k(vaddr)));
> + FILL_PTBL(PAGEBASE(pte_base), PHYSADDR, PAGESIZE());
> + pte_addr = pte_base + sizeof(pmd_t) * pte_index_l3_4k(vaddr);
> + pte_val = ULONG(machdep->ptbl + PAGEOFFSET(pte_addr));
> if (verbose)
> - fprintf(fp, " PTE: %lx => %lx\n", pt_phys, pte_val);
> + fprintf(fp, " PTE: %lx => %lx\n", pte_addr, pte_val);
> if (!pte_val)
> goto no_page;
> pte_val &= PTE_PFN_PROT_MASK;
> --
> 2.34.1
>
1 month, 1 week
[PATCH v3 0/2] extension: Several improvements on eppic extension
by Tao Liu
Eppic works as a crash extension for a long time, and it is a very convenient
tool to extend crash's function:
1) People don't need to write an actual crash extension, which requires
knowledge of crash APIs, such as readmem(), gdb_interface() etc.
Implementing such an crash extension is hard for normal users.
2) Eppic programs are C-syntax-like scripting, no compile needed, so friendly
to kernel developers who are already familiar with C. It's a good alternative
for people who are unfamiliar with python (comparing to drgn/pykdump).
3) Writing eppic programs is similar to do kernel programming, people can use
kernel data structures/global variables directly, again, friendly to kernel
developers.
Personally I think eppic is a good tool and would like to push it forward to
make it used more widely, improved consistently. However I hardly heard anyone
who are using it, I guess it is due to it's extension position and unknown to
others.
In this patchset, I will make several improvements on eppic, although it is
still a crash extension, but I think it is made more easily for
compile/run/scripting.
To-do:
Some crash functions should be exposed to eppic, such as maple_tree/rbtree etc,
so people can iterate these kernel structures with the existing crash functions,
otherwise people need to reimplement those in eppic.
A more aggresive improvement of eppic can be found in [1], which people
can use call_crash_func() to call any crash's function within eppic
script, please refer to code example in [2]. Not sure if people like
this, so any feedback/comments are welcomed.
v2 -> v1:
Removed v1's No.2 & 3 & 5 patch, these 3 are used for compile/preload/alias
eppic by default, these are a little aggressive and left to [1] instead.
[1]: https://github.com/liutgnu/crash-dev/tree/eppic
[2]: https://github.com/liutgnu/crash-dev/blob/eppic/extensions/eppic.patch#L298
v3 -> v2:
Removed goto for get_extensions_directory().
Removed pushd/popd in eppic.mk.
Tao Liu (2):
extensions: Search all possible paths
eppic.patch: Add customized functions to eppic
extensions.c | 59 ++++++------
extensions/eppic.mk | 9 +-
extensions/eppic.patch | 210 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 250 insertions(+), 28 deletions(-)
create mode 100644 extensions/eppic.patch
--
2.47.0
1 month, 1 week
Re: [PATCH v3 1/2] extensions: Search all possible paths
by lijiang
Hi, Tao
Thank you for the update.
On Tue, Oct 28, 2025 at 6:59 AM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Tue, 28 Oct 2025 11:40:03 +1300
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] [PATCH v3 1/2] extensions: Search all
> possible paths
> To: devel(a)lists.crash-utility.osci.io
> Cc: lijiang(a)redhat.com
> Message-ID: <20251027224004.13784-2-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> Search all possible paths for extensions. Previously if one path, e.g.
> "/usr/lib64/crash/extensions" exists, but no extensions found within,
> crash will not search any later paths, e.g. "./extensions". This patch
> will let crash continue to search any later paths.
>
> Signed-off-by: Tao Liu <ltao(a)redhat.com>
> ---
> extensions.c | 59 ++++++++++++++++++++++++++++------------------------
> 1 file changed, 32 insertions(+), 27 deletions(-)
>
> diff --git a/extensions.c b/extensions.c
> index d23b1e3..099af3b 100644
> --- a/extensions.c
> +++ b/extensions.c
> @@ -19,7 +19,7 @@
> #include <dlfcn.h>
>
> static int in_extensions_library(char *, char *);
> -static char *get_extensions_directory(char *);
> +static char *get_extensions_directory(char *, bool *);
> static void show_all_extensions(void);
> static void show_extensions(char *);
>
> @@ -395,32 +395,29 @@ in_extensions_library(char *lib, char *buf)
> * Look for an extensions directory using the proper order.
> */
> static char *
> -get_extensions_directory(char *dirbuf)
> +get_extensions_directory(char *dirbuf, bool *end)
> {
> - char *env;
> + static int index = 0;
>
> + char *dirs[] = {
> + getenv("CRASH_EXTENSIONS"),
> + BITS64() ? "/usr/lib64/crash/extensions" : NULL,
> + "/usr/lib/crash/extensions",
> + "./extensions",
> + };
> + char *dir;
>
> - if ((env = getenv("CRASH_EXTENSIONS"))) {
> - if (is_directory(env)) {
> - strcpy(dirbuf, env);
> - return dirbuf;
> - }
> + if (index >= sizeof(dirs) / sizeof(char *)) {
> + *end = true;
> + return NULL;
> }
> -
> - if (BITS64()) {
> - sprintf(dirbuf, "/usr/lib64/crash/extensions");
> - if (is_directory(dirbuf))
> - return dirbuf;
> + *end = false;
> + dir = dirs[index++];
> + if (is_directory(dir)) {
> + snprintf(dirbuf, BUFSIZE - 1, "%s", dir);
>
The snprintf() won't write more than BUFSIZE - 1 characters and will always
null-terminate the buffer(including the terminating null byte ('\0')),
so using the BUFSIZE should be safe and correct.
Other changes are fine to me. Otherwise: Ack.
Thanks
Lianbo
+ return dir;
> + } else {
> + return NULL;
> }
> -
> - sprintf(dirbuf, "/usr/lib/crash/extensions");
> - if (is_directory(dirbuf))
> - return dirbuf;
> -
> - sprintf(dirbuf, "./extensions");
> - if (is_directory(dirbuf))
> - return dirbuf;
> -
> - return NULL;
> }
>
>
> @@ -432,14 +429,20 @@ preload_extensions(void)
> char dirbuf[BUFSIZE];
> char filename[BUFSIZE*2];
> int found;
> + bool end;
>
> - if (!get_extensions_directory(dirbuf))
> - return;
> +next_dir:
> + if (!get_extensions_directory(dirbuf, &end)) {
> + if (end)
> + return;
> + else
> + goto next_dir;
> + }
>
> dirp = opendir(dirbuf);
> if (!dirp) {
> error(INFO, "%s: %s\n", dirbuf, strerror(errno));
> - return;
> + goto next_dir;
> }
>
> pc->curcmd = pc->program_name;
> @@ -461,10 +464,12 @@ preload_extensions(void)
>
> if (found)
> fprintf(fp, "\n");
> - else
> + else {
> error(NOTE,
> "%s: no extension modules found in directory\n\n",
> dirbuf);
> + goto next_dir;
> + }
> }
>
> /*
> --
> 2.47.0
>
1 month, 1 week
[PATCH v3 1/3] s390x: Add non-zero vmalloc_start check to s390x_vr_IS_VMALLOC_ADDR()
by Mikhail Zaslonko
Update s390x_vr_IS_VMALLOC_ADDR() to include a non-zero vmalloc_start
check, making it consistent with s390x_generic_IS_VMALLOC_ADDR().
Fixes: d0164e7e480a ("s390x: uncouple physical and virtual memory spaces")
Signed-off-by: Mikhail Zaslonko <zaslonko(a)linux.ibm.com>
---
s390x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/s390x.c b/s390x.c
index 0e8e2b3..1117bf0 100644
--- a/s390x.c
+++ b/s390x.c
@@ -724,13 +724,13 @@ static ulong s390x_vr_PTOV(ulong paddr)
{
return paddr + machdep->identity_map_base;
}
static int s390x_vr_IS_VMALLOC_ADDR(ulong vaddr)
{
- return (vaddr >= vt->vmalloc_start && vaddr < machdep->kvbase);
+ return (vt->vmalloc_start && vaddr >= vt->vmalloc_start && vaddr < machdep->kvbase);
}
ulong s390x_VTOP(ulong vaddr)
{
return machdep->machspec->virt_to_phys(vaddr);
}
--
2.49.0
1 month, 1 week
[PATCH] RISCV64: fix wrong information of PMD and PTE - SA39(4K page) support
by Austin Kim
When running 'vtop address' command in RISC-V based vmcore, the base address
without applying offset for PMD and PTE is displayed. This is not correct
address for PMD and PTE.
With this patch, the actual address for PMD and PTE with the valid offset
is printed:
<Before>
crash> vtop 0xffffffff81c4f000
VIRTUAL PHYSICAL
ffffffff81c4f000 41e4f000
PAGE DIRECTORY: ffffffff81c4f000
PGD: ffffffff81c4fff0 => 4fffe801
PMD: 000000013fffa000 => 00000000107800e7
PTE: 41e00000 => ffffffff8166fea0
PTE PAGE: 0000000000000000 not present
<After>
crash> vtop 0xffffffff81c4f000
VIRTUAL PHYSICAL
ffffffff81c4f000 41e4f000
PAGE DIRECTORY: ffffffff81c4f000
PGD: ffffffff81c4fff0 => 4fffe801
PMD: 000000013fffa070 => 00000000107800e7
PTE: 41e00278 => ffffffff8166fea0
PTE PAGE: 0000000000000000 not present
Signed-off-by: Austin Kim <austindh.kim(a)gmail.com>
---
riscv64.c | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/riscv64.c b/riscv64.c
index ef5c41d..6b89f0b 100644
--- a/riscv64.c
+++ b/riscv64.c
@@ -630,9 +630,8 @@ static int
riscv64_vtop_3level_4k(ulong *pgd, ulong vaddr, physaddr_t *paddr, int verbose)
{
ulong *pgd_ptr, pgd_val;
- ulong pmd_val;
- ulong pte_val, pte_pfn;
- ulong pt_phys;
+ ulong pmd_base, pmd_addr, pmd_val;
+ ulong pte_base, pte_addr, pte_val, pte_pfn;
if (verbose)
fprintf(fp, "PAGE DIRECTORY: %lx\n", (ulong)pgd);
@@ -646,25 +645,25 @@ riscv64_vtop_3level_4k(ulong *pgd, ulong vaddr, physaddr_t *paddr, int verbose)
if (!pgd_val)
goto no_page;
pgd_val &= PTE_PFN_PROT_MASK;
- pt_phys = (pgd_val >> _PAGE_PFN_SHIFT) << PAGESHIFT();
+ pmd_base = (pgd_val >> _PAGE_PFN_SHIFT) << PAGESHIFT();
/* PMD */
- FILL_PMD(PAGEBASE(pt_phys), PHYSADDR, PAGESIZE());
- pmd_val = ULONG(machdep->pmd + PAGEOFFSET(sizeof(pmd_t) *
- pmd_index_l3_4k(vaddr)));
+ FILL_PMD(PAGEBASE(pmd_base), PHYSADDR, PAGESIZE());
+ pmd_addr = pmd_base + sizeof(pmd_t) * pmd_index_l3_4k(vaddr);
+ pmd_val = ULONG(machdep->pmd + PAGEOFFSET(pmd_addr));
if (verbose)
- fprintf(fp, " PMD: %016lx => %016lx\n", pt_phys, pmd_val);
+ fprintf(fp, " PMD: %016lx => %016lx\n", pmd_addr, pmd_val);
if (!pmd_val)
goto no_page;
pmd_val &= PTE_PFN_PROT_MASK;
- pt_phys = (pmd_val >> _PAGE_PFN_SHIFT) << PAGESHIFT();
+ pte_base = (pmd_val >> _PAGE_PFN_SHIFT) << PAGESHIFT();
/* PTE */
- FILL_PTBL(PAGEBASE(pt_phys), PHYSADDR, PAGESIZE());
- pte_val = ULONG(machdep->ptbl + PAGEOFFSET(sizeof(pte_t) *
- pte_index_l3_4k(vaddr)));
+ FILL_PTBL(PAGEBASE(pte_base), PHYSADDR, PAGESIZE());
+ pte_addr = pte_base + sizeof(pmd_t) * pte_index_l3_4k(vaddr);
+ pte_val = ULONG(machdep->ptbl + PAGEOFFSET(pte_addr));
if (verbose)
- fprintf(fp, " PTE: %lx => %lx\n", pt_phys, pte_val);
+ fprintf(fp, " PTE: %lx => %lx\n", pte_addr, pte_val);
if (!pte_val)
goto no_page;
pte_val &= PTE_PFN_PROT_MASK;
--
2.34.1
1 month, 1 week
