[PATCH] add clear command
by Huang Shijie
Add the clear command for crash.
Use it to clear the screen.
Signed-off-by: Huang Shijie <shijie(a)os.amperecomputing.com>
---
This is just for tool "crash".
---
defs.h | 2 ++
global_data.c | 1 +
help.c | 8 ++++++++
tools.c | 9 +++++++++
4 files changed, 20 insertions(+)
diff --git a/defs.h b/defs.h
index 96a7a2a..a72aa69 100644
--- a/defs.h
+++ b/defs.h
@@ -5283,6 +5283,7 @@ void cmd_test(void); /* test.c */
void cmd_ascii(void); /* tools.c */
void cmd_sbitmapq(void); /* sbitmap.c */
void cmd_bpf(void); /* bfp.c */
+void cmd_clear(void); /* tools.c */
void cmd_set(void); /* tools.c */
void cmd_eval(void); /* tools.c */
void cmd_list(void); /* tools.c */
@@ -5883,6 +5884,7 @@ extern char *help_ascii[];
extern char *help_bpf[];
extern char *help_bt[];
extern char *help_btop[];
+extern char *help_clear[];
extern char *help_dev[];
extern char *help_dis[];
extern char *help_eval[];
diff --git a/global_data.c b/global_data.c
index f9bb7d0..2157e8c 100644
--- a/global_data.c
+++ b/global_data.c
@@ -75,6 +75,7 @@ struct command_table_entry linux_command_table[] = {
{"bpf", cmd_bpf, help_bpf, 0},
{"bt", cmd_bt, help_bt, REFRESH_TASK_TABLE},
{"btop", cmd_btop, help_btop, 0},
+ {"clear", cmd_clear, help_clear, 0},
{"dev", cmd_dev, help_dev, 0},
{"dis", cmd_dis, help_dis, MINIMAL},
{"eval", cmd_eval, help_eval, MINIMAL},
diff --git a/help.c b/help.c
index cc7ab20..04284e5 100644
--- a/help.c
+++ b/help.c
@@ -2293,6 +2293,14 @@ char *help_btop[] = {
NULL
};
+char *help_clear[] = {
+"clear",
+"Clear the screen",
+" ",
+"Used to clear the screen",
+NULL
+};
+
char *help_extend[] = {
"extend",
"extend the %s command set",
diff --git a/tools.c b/tools.c
index 0f2db10..96c8dbe 100644
--- a/tools.c
+++ b/tools.c
@@ -1783,6 +1783,15 @@ mkstring(char *s, int size, ulong flags, const char *opt)
return(s);
}
+/*
+ * Clear the screen.
+ */
+void
+cmd_clear(void)
+{
+ system("clear");
+}
+
/*
* Prints the requested number of BACKSPACE characters.
*/
--
2.39.2
11 months, 3 weeks
Re: [Crash-utility] [PATCH] diskdump: fix read_diskdump() returns successfully for illegal 0-size page descriptors
by lijiang
Thank you for the patch, HATAYAMA.
On Thu, Sep 7, 2023 at 6:55 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Thu, 7 Sep 2023 18:38:25 +0900
> From: HATAYAMA Daisuke <d.hatayama(a)fujitsu.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH] diskdump: fix read_diskdump() returns
> successfully for illegal 0-size page descriptors
> Message-ID: <20230907093825.515-1-d.hatayama(a)fujitsu.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> read_diskdump() returns successfully for illegal 0-size page
> descriptors. Page descriptors are illegal if their size member holds 0
> because makedumpfile never puts 0 there because any data never result
> in 0 byte by compression. If page descriptors hold 0 in size member,
> it means the crash dump file is corrupted for some reason.
>
> The root cause of this is that sanity check of function cache_page()
> doesn't focus on such 0-size page descriptors. Then, the 0-size page
> descriptor is passed to pread(), pread() immediately returns 0
> successfully because read data is 0 byte, and then read_diskdump()
> returns successfully.
>
> To fix this issue, let the sanity check take into account such 0-size
> page descriptors and read_diskdump() result in READ_ERROR.
>
> Signed-off-by: HATAYAMA Daisuke <d.hatayama(a)fujitsu.com>
> ---
> diskdump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/diskdump.c b/diskdump.c
> index 2c284ff..2be7cc7 100644
> --- a/diskdump.c
> +++ b/diskdump.c
> @@ -1210,7 +1210,7 @@ cache_page(physaddr_t paddr)
> return ret;
>
> /* sanity check */
> - if (pd.size > block_size)
> + if (pd.size > block_size || !pd.size)
>
Actually this may not be a real read error instead of an incomplete page
due to corruption or other reasons. Given that, I would suggest adding the
sanity check as below:
- } else if (0 == pd.offset) {
+ } else if (0 == pd.offset || !pd.size) {
It can help to print more information according to the code when fails on
the page:
/*
* First check whether zero_excluded has been set.
*/
if (*diskdump_flags & ZERO_EXCLUDED) {
if (CRASHDEBUG(8))
fprintf(fp,
"read_diskdump/cache_page: zero-fill: "
"paddr/pfn: %llx/%lx\n",
(ulonglong)paddr, pfn);
memset(dd->compressed_page, 0, dd->block_size);
} else {
if (CRASHDEBUG(8))
fprintf(fp,
"read_diskdump/cache_page: "
"descriptor with zero offset found
at "
"paddr/pfn/pos: %llx/%lx/%lx\n",
(ulonglong)paddr, pfn, desc_pos);
return PAGE_INCOMPLETE;
}
I don't have such vmcores, and can not test it, just an idea.
Thanks.
Lianbo
return READ_ERROR;
>
> /* read page data */
> --
> 2.25.1
>
12 months
About referring to struct load_module from extension modules
by Daisuke Hatayama (Fujitsu)
Hagio-san,
crash trace now results in SIGSEGV on Fedora Linux 38 as follows:
crash> extend /usr/lib64/crash/extensions/trace.so
/usr/lib64/crash/extensions/trace.so: shared object loaded
crash> trace
current tracer is nop
crash> trace show
Segmentation fault (core dumped)
The SIGSEGV occurs in function save_proc_kallsyms() when trying to
look up module symbols via lm->mod_symtable:
https://github.com/fujitsu/crash-trace/blob/master/trace.c#L2222-L2246
crash trace command creates a trace data that contains kallsyms
internally. crash trace command refer to lm->mod_symtable to create
the kallsyms. See
https://man7.org/linux/man-pages/man5/trace-cmd.dat.5.html#KALLSYMS_INFOR...
in details.
This issue occurs when using crash utility with the following commit that is for
new kernel module layout support on Linux kernel 6.4:
commit 7750e61fdb2a083f26156a5338aa2ebe26447f3f
Author: Kazuhito Hagio <k-hagio-ab(a)nec.com>
Date: Thu Jun 22 16:09:07 2023 +0900
Support module memory layout change on Linux 6.4
Support module memory layout change on Linux 6.4 by kernel commit
ac3b43283923 ("module: replace module_layout with module_memory") [1].
Without the patch, crash cannot even start a session with an error
message like this:
crash: invalid structure member offset: module_core_size
FILE: kernel.c LINE: 3787 FUNCTION: module_init()
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
I've already made a tentative fixing patch based on this new handling
of struct load_module based on function module_symbol_dump() and it
works fine.
On the other hand, is it OK to refer to struct load_module directly
from extension modules?
I'm not the original author of crash trace command. I've just found
crash trace doing like this for the first time.
- If it is OK to refer to struct load_module directly from extension
modules, should it be backward compatible on it? Or extension
modules should absorb the incompatibility?
- If it is not OK, is there possibility to introduce a new interface
to iterate symbols without need of referring to struct load_modules
directly?
Thanks.
HATAYAMA, Daisuke
12 months
