Re: [Crash-utility] [PATCH 0/3] trace.so: Make trace dump -t work again
by Dave Anderson
Hi Steve,
I'm not going to wait any longer for Xu Huan to respond. Perhaps he's no longer interested
in maintaining the package, but if he is, he can always reply later.
Your patches are queued for crash-7.2.6:
https://github.com/crash-utility/crash/commit/26488e918f065c7cdd8e8d77ef7...
Thanks,
Dave
----- Original Message -----
> Hi Dave,
>
> I gave a talk at SCaLE 17x last week and was going to demonstrate using
> ftrace on a system that crashes, and then pulling out the vmcore file
> with kexec and kdump, and then pulling out the ftrace ring buffers and
> creating a trace.dat file with the crash extension trace.so.
> Unfortunately, this wasn't working as I planned. I created the
> following three patches, where two fix the issue (I was getting a
> corrupted trace.dat file), and the third actually documents the '-t'
> option of the dump command. Hopefully you can accept these patches.
>
> Thanks!
>
> -- Steve
>
> -----
> extensions/trace.c | 32 +++++++++++++++++++++++++++++---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> Steven Rostedt (VMware) (3):
> trace.so: Do not record empty pages
> trace.so: Do not print garbage for kallsyms "type" for modules
> trace.so: Show -t option in trace dump short help message
>
5 years, 5 months
[PATCH 0/1] Fix for XArray/radix_tree rework on linux-next
by Philipp Rudo
Hi Dave,
crash currently fails on linux-next kernel due to another radix-tree rework.
The patch attached fixes this.
BTW, is there an 'official policy' about fixing linux-next issues, as commits
can be changed/dropped on their way to the linux repo?
Thanks
Philipp
Philipp Rudo (1):
Fix for XArray/radix_tree rework on linux-next
bpf.c | 7 ++++++-
ipcs.c | 5 ++++-
task.c | 15 +++++++++++----
3 files changed, 21 insertions(+), 6 deletions(-)
--
2.16.4
5 years, 5 months
Fwd: [PATCH 0/3] trace.so: Make trace dump -t work again
by Dave Anderson
----- Original Message -----
>
>>> The problem happens only with module symbols, not with kallsyms.
>>>
>>> crash> sym -M
>>> c008000007810000 MODULE START: crc32c_vpmsum
>>> c008000007810000 (^R) __crc32c_vpmsum
>>> c008000007810670 (^B) crc32c_vpmsum_cra_init
>>> c008000007810690 (^B) crc32c_vpmsum_setkey
>>
>> Hi Ravi,
>>
>> I have never seen this before, but nonetheless, it does seem that Steve's patch
>> to the trace.c module is the better course of action. Does it work OK for you?
>>
>> Dave
>
> Dave, I see only cover letter:
> https://www.redhat.com/archives/crash-utility/2019-March/thread.html
>
> Can you please forward patches to ml as well.
>
Sorry about that...
Dave
5 years, 5 months
[PATCH] crash: Use '?' for kernel module symbols type
by Ravi Bangoria
We are using ELFXX_sym->st_info directly as the 'type' of symbol,
which is wrong, because st_info contains numeric value which needs
to be mapped to appropriate type character. Sections headers are
also required to correctly map st_info to symbol type which are
missing here (lm->mod_section_data is NULL). Use '?' for now. This
fixes 'trace' extension which segfaults internally while parsing
module kallsyms:
Before patch:
crash> trace show
crash>
After patch:
crash> trace show
cpus=4
<idle>-0 [002] 4350.912553: function: __hrtimer_get_next_event <-- hrtime
<idle>-0 [002] 4350.912553: function: __hrtimer_next_event_base <-- __hrt
Signed-off-by: Ravi Bangoria <ravi.bangoria(a)linux.ibm.com>
---
symbols.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/symbols.c b/symbols.c
index e73e735..4456cd3 100644
--- a/symbols.c
+++ b/symbols.c
@@ -2188,7 +2188,12 @@ Elf32_Sym_to_common(Elf32_Sym *e32, struct elf_common *ec)
ec->st_name = (ulong)e32->st_name;
ec->st_value = (ulong)e32->st_value;
ec->st_shndx = (ulong)e32->st_shndx;
- ec->st_info = e32->st_info;
+ /*
+ * Section headers are required to correctly map st_info
+ * to symbol type, which are missing here. Let's use '?'
+ * for all kernel module symbols type.
+ */
+ ec->st_info = '?';
ec->st_size = (ulong)e32->st_size;
}
@@ -2198,7 +2203,12 @@ Elf64_Sym_to_common(Elf64_Sym *e64, struct elf_common *ec)
ec->st_name = (ulong)e64->st_name;
ec->st_value = (ulong)e64->st_value;
ec->st_shndx = (ulong)e64->st_shndx;
- ec->st_info = e64->st_info;
+ /*
+ * Section headers are required to correctly map st_info
+ * to symbol type, which are missing here. Let's use '?'
+ * for all kernel module symbols type.
+ */
+ ec->st_info = '?';
ec->st_size = (ulong)e64->st_size;
}
--
1.8.3.1
5 years, 5 months
Fwd: [PATCH 0/3] trace.so: Make trace dump -t work again
by Dave Anderson
Thanks a lot, Steve -- forwarding to the crash-utility mainling list and to Xu Huan,
the trace.c maintainer for his ACK.
There was a report on this list about the sp_type problem last week, but the proposed fix
(which just changed all module symbol sp_type's to '?' in the crash utility itself) wasn't
acceptable, and there was no response after that. This looks to fix the same issue.
Dave
----- Forwarded Message -----
From: "Steven Rostedt" <rostedt(a)goodmis.org>
To: "Dave Anderson" <anderson(a)redhat.com>
Sent: Friday, March 15, 2019 9:03:33 PM
Subject: [PATCH 0/3] trace.so: Make trace dump -t work again
Hi Dave,
I gave a talk at SCaLE 17x last week and was going to demonstrate using
ftrace on a system that crashes, and then pulling out the vmcore file
with kexec and kdump, and then pulling out the ftrace ring buffers and
creating a trace.dat file with the crash extension trace.so.
Unfortunately, this wasn't working as I planned. I created the
following three patches, where two fix the issue (I was getting a
corrupted trace.dat file), and the third actually documents the '-t'
option of the dump command. Hopefully you can accept these patches.
Thanks!
-- Steve
-----
extensions/trace.c | 32 +++++++++++++++++++++++++++++---
1 file changed, 29 insertions(+), 3 deletions(-)
Steven Rostedt (VMware) (3):
trace.so: Do not record empty pages
trace.so: Do not print garbage for kallsyms "type" for modules
trace.so: Show -t option in trace dump short help message
5 years, 5 months
[PATCH] Fix for the "kmem -i" option on Linux 5.0
by Kazuhito Hagio
Fix for the "kmem -i" option on Linux 5.0 and later kernels that
contain commit ca79b0c211af63fa3276f0e3fd7dd9ada2439839, titled
"mm: convert totalram_pages and totalhigh_pages variables to atomic".
Without the patch, the command prints some incorrect values, and
besides doesn't print high/low memory information on kernels which
are configured with CONFIG_HIGHMEM.
crash> kmem -i
PAGES TOTAL PERCENTAGE
TOTAL MEM -4395174638254716088 53602483503169.4 GB ----
FREE 398314 1.5 GB 0% of TOTAL MEM
USED -4395174638255114402 53602483503167.9 GB 0% of TOTAL MEM
...
Tested with 5.0 and 4.20 Fedora kernels for x86_64 and x86.
Signed-off-by: Kazuhito Hagio <k-hagio(a)ab.jp.nec.com>
---
memory.c | 75 +++++++++++++++++++++++++++-----------------------------
1 file changed, 36 insertions(+), 39 deletions(-)
diff --git a/memory.c b/memory.c
index 9c1019a..ab561b3 100644
--- a/memory.c
+++ b/memory.c
@@ -910,26 +910,40 @@ vm_init(void)
if (IS_VMALLOC_ADDR(vt->mem_map))
vt->flags |= V_MEM_MAP;
vt->total_pages = BTOP(VTOP(vt->high_memory));
- switch (get_syment_array("totalram_pages", sp_array, 2))
- {
- case 1:
- get_symbol_data("totalram_pages", sizeof(ulong),
- &vt->totalram_pages);
- break;
- case 2:
- if (!(readmem(sp_array[0]->value, KVADDR,
- &value1, sizeof(ulong),
- "totalram_pages #1", RETURN_ON_ERROR)))
+
+ if (symbol_exists("_totalram_pages")) {
+ readmem(symbol_value("_totalram_pages") +
+ OFFSET(atomic_t_counter), KVADDR,
+ &vt->totalram_pages, sizeof(ulong),
+ "_totalram_pages", FAULT_ON_ERROR);
+ } else {
+ switch (get_syment_array("totalram_pages", sp_array, 2))
+ {
+ case 1:
+ get_symbol_data("totalram_pages", sizeof(ulong),
+ &vt->totalram_pages);
break;
- if (!(readmem(sp_array[1]->value, KVADDR,
- &value2, sizeof(ulong),
- "totalram_pages #2", RETURN_ON_ERROR)))
- break;
- vt->totalram_pages = MAX(value1, value2);
- break;
+ case 2:
+ if (!(readmem(sp_array[0]->value, KVADDR,
+ &value1, sizeof(ulong),
+ "totalram_pages #1", RETURN_ON_ERROR)))
+ break;
+ if (!(readmem(sp_array[1]->value, KVADDR,
+ &value2, sizeof(ulong),
+ "totalram_pages #2", RETURN_ON_ERROR)))
+ break;
+ vt->totalram_pages = MAX(value1, value2);
+ break;
+ }
}
- if (symbol_exists("totalhigh_pages")) {
+ if (symbol_exists("_totalhigh_pages")) {
+ readmem(symbol_value("_totalhigh_pages") +
+ OFFSET(atomic_t_counter), KVADDR,
+ &vt->totalhigh_pages, sizeof(ulong),
+ "_totalhigh_pages", FAULT_ON_ERROR);
+ vt->total_pages += vt->totalhigh_pages;
+ } else if (symbol_exists("totalhigh_pages")) {
switch (get_syment_array("totalhigh_pages", sp_array, 2))
{
case 1:
@@ -8169,7 +8183,6 @@ dump_kmeminfo(void)
long nr_file_pages, nr_slab;
ulong swapper_space_nrpages;
ulong pct;
- ulong value1, value2;
uint tmp;
struct meminfo meminfo;
struct gnu_request req;
@@ -8177,7 +8190,6 @@ dump_kmeminfo(void)
ulong get_totalram;
ulong get_buffers;
ulong get_slabs;
- struct syment *sp_array[2];
char buf[BUFSIZE];
@@ -8210,7 +8222,8 @@ dump_kmeminfo(void)
* Prior to 2.3.36, count all mem_map pages minus the reserved ones.
* From 2.3.36 onwards, use "totalram_pages" if set.
*/
- if (symbol_exists("totalram_pages")) {
+ if (symbol_exists("totalram_pages") ||
+ symbol_exists("_totalram_pages")) {
totalram_pages = vt->totalram_pages ?
vt->totalram_pages : get_totalram;
} else
@@ -8362,25 +8375,9 @@ dump_kmeminfo(void)
fprintf(fp, "%13s %7ld %11s %3ld%% of TOTAL MEM\n",
"SLAB", get_slabs, pages_to_size(get_slabs, buf), pct);
- if (symbol_exists("totalhigh_pages")) {
- switch (get_syment_array("totalhigh_pages", sp_array, 2))
- {
- case 1:
- get_symbol_data("totalhigh_pages", sizeof(ulong),
- &totalhigh_pages);
- break;
- case 2:
- if (!(readmem(sp_array[0]->value, KVADDR,
- &value1, sizeof(ulong),
- "totalhigh_pages #1", RETURN_ON_ERROR)))
- break;
- if (!(readmem(sp_array[1]->value, KVADDR,
- &value2, sizeof(ulong),
- "totalhigh_pages #2", RETURN_ON_ERROR)))
- break;
- totalhigh_pages = MAX(value1, value2);
- break;
- }
+ if (symbol_exists("totalhigh_pages") ||
+ symbol_exists("_totalhigh_pages")) {
+ totalhigh_pages = vt->totalhigh_pages;
pct = totalhigh_pages ?
(totalhigh_pages * 100)/totalram_pages : 0;
--
2.17.0
5 years, 6 months
[PATCH] Fix for "kmem -z" on Linux 5.0
by Kazuhito Hagio
Fix for the "kmem -z" command on Linux 5.0 and later kernels that
contain commit a921444382b49cc7fdeca3fba3e278bc09484a27, titled
"mm: move zone watermark accesses behind an accessor". Without the
patch, the command fails with the following error message.
kmem: invalid (optional) structure member offsets: zone_pages_min or zone_struct_pages_min
FILE: memory.c LINE: 16457 FUNCTION: dump_zone_stats()
Signed-off-by: Kazuhito Hagio <k-hagio(a)ab.jp.nec.com>
---
memory.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/memory.c b/memory.c
index 8cdab06..9c1019a 100644
--- a/memory.c
+++ b/memory.c
@@ -1095,6 +1095,9 @@ vm_init(void)
"zone", "pages_high");
MEMBER_OFFSET_INIT(zone_watermark,
"zone", "watermark");
+ if (INVALID_MEMBER(zone_watermark))
+ MEMBER_OFFSET_INIT(zone_watermark,
+ "zone", "_watermark");
MEMBER_OFFSET_INIT(zone_nr_active,
"zone", "nr_active");
MEMBER_OFFSET_INIT(zone_nr_inactive,
--
1.8.3.1
5 years, 6 months
