rpms
/
crash
7
0
Fork 0
Code Issues Pull Requests Releases Activity
crash/SOURCES/github_28fa7bd0_to_02efd083...

175 lines
5.9 KiB
Diff
Raw Blame History

commit 28fa7bd09013455b5ddc020dea4706278cda0d65
Author: Dave Anderson <anderson@redhat.com>
Date: Tue Jun 19 16:31:54 2018 -0400
Fix for PPC64 kernel virtual address translation in Linux 4.17 and
later kernels with commit c2b4d8b7417a59b7f9a52d0d8402f5257cbbd398,
titled "powerpc/mm/hash64: Increase the VA range", in which the
maximum virtual address value has been increased to 4PB. Without
the patch, the translation/access of high vmalloc space addresses
fails; for example, the "kmem -[sS]" option fails the translation
of per-cpu kmem_cache_cpu addresses located in vmalloc space, with
the error messages "kmem: invalid kernel virtual address: <address>
type: kmem_cache_cpu.freelist" and "kmem: invalid kernel virtual
address: <address> type: kmem_cache_cpu.page", and the "vtop"
command shows the addresses as "(not mapped)".
(hbathini@linux.ibm.com)
diff --git a/defs.h b/defs.h
index 6e6f6be..e6e3850 100644
--- a/defs.h
+++ b/defs.h
@@ -3977,6 +3977,7 @@ struct efi_memory_desc_t {
#define PMD_INDEX_SIZE_L4_64K_4_12 10
#define PUD_INDEX_SIZE_L4_64K_4_12 7
#define PGD_INDEX_SIZE_L4_64K_4_12 8
+#define PUD_INDEX_SIZE_L4_64K_4_17 10
#define PTE_INDEX_SIZE_RADIX_64K 5
#define PMD_INDEX_SIZE_RADIX_64K 9
#define PUD_INDEX_SIZE_RADIX_64K 9
diff --git a/ppc64.c b/ppc64.c
index 0dd8a2a..f5d0dac 100644
--- a/ppc64.c
+++ b/ppc64.c
@@ -451,7 +451,10 @@ ppc64_init(int when)
if (THIS_KERNEL_VERSION >= LINUX(4,12,0)) {
m->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_12;
- m->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_12;
+ if (THIS_KERNEL_VERSION >= LINUX(4,17,0))
+ m->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_17;
+ else
+ m->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_12;
m->l4_index_size = PGD_INDEX_SIZE_L4_64K_4_12;
} else {
m->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_6;
commit e5df29d54bbdb8b84cb1661233ed186b153be746
Author: Dave Anderson <anderson@redhat.com>
Date: Wed Jun 20 11:15:38 2018 -0400
Fix for the x86_64 "bt" command in which a legitimate exception
frame is appended with the message "bt: WARNING: possibly bogus
exception frame". This only happens in KASLR-enabled kernels when
the text address that was executing when the exception occurred
is marked as a "weak" symbol (type "W") instead of a text symbol
(type "T" or "t"). As a result, the exception frame's RIP is not
recognized as a text symbol, and the warning message is displayed.
(anderson@redhat.com)
diff --git a/symbols.c b/symbols.c
index bb4ae3a..bf55319 100644
--- a/symbols.c
+++ b/symbols.c
@@ -2755,9 +2755,14 @@ is_kernel_text(ulong value)
section);
end = start + (ulong)bfd_section_size(st->bfd,
section);
+
+ if (kt->flags2 & KASLR) {
+ start += (kt->relocate * -1);
+ end += (kt->relocate * -1);
+ }
- if ((value >= start) && (value < end))
- return TRUE;
+ if ((value >= start) && (value < end))
+ return TRUE;
}
}
}
@@ -2833,7 +2838,16 @@ is_kernel_text_offset(ulong value)
int
is_symbol_text(struct syment *sp)
{
- return ((sp->type == 'T') || (sp->type == 't'));
+ if ((sp->type == 'T') || (sp->type == 't'))
+ return TRUE;
+
+ if ((sp->type == 'W') || (sp->type == 'w')) {
+ if ((sp->value >= kt->stext) &&
+ (sp->value < kt->etext))
+ return TRUE;
+ }
+
+ return FALSE;
}
/*
commit a7e5b90757bb41ad5e148177c5b3aaf5d892243d
Author: Dave Anderson <anderson@redhat.com>
Date: Wed Jun 20 16:33:43 2018 -0400
Fix for the x86_64 "bt" command in Linux 4.16 and later kernels
containing commit 3aa99fc3e708b9cd9b4cfe2df0b7a66cf293e3cf, titled
"x86/entry/64: Remove 'interrupt' macro". Without the patch, the
exception frame display generated by an interrupt exception will
show incorrect contents, and be followed by the message "bt: WARNING:
possibly bogus exception frame".
(anderson@redhat.com)
diff --git a/x86_64.c b/x86_64.c
index e01082b..6d1ae2f 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -4285,6 +4285,12 @@ x86_64_exception_frame(ulong flags, ulong kvaddr, char *local,
long err;
char buf[BUFSIZE];
+ if (flags == EFRAME_VERIFY) {
+ if (!accessible(kvaddr) ||
+ !accessible(kvaddr + SIZE(pt_regs) - sizeof(long)))
+ return FALSE;
+ }
+
ms = machdep->machspec;
sp = NULL;
@@ -6283,6 +6289,9 @@ x86_64_irq_eframe_link(ulong stkref, struct bt_info *bt, FILE *ofp)
{
ulong irq_eframe;
+ if (x86_64_exception_frame(EFRAME_VERIFY, stkref, 0, bt, ofp))
+ return stkref;
+
irq_eframe = stkref - machdep->machspec->irq_eframe_link;
if (x86_64_exception_frame(EFRAME_VERIFY, irq_eframe, 0, bt, ofp))
commit 02efd0838f05ef8a7fe21b0b8ba6cad729270645
Author: Dave Anderson <anderson@redhat.com>
Date: Fri Jun 22 11:00:01 2018 -0400
Fix for the failure of several "kmem" command options, most notably
seen if the command is piped directly into a crash session, or if
the command is contained in an input file. For examples:
$ echo "kmem -i" | crash ...
$ crash -i <input-file> ...
Without the patch, the kmem command may fail with the error message
"<segmentation violation in gdb>". While the bug is due to a buffer
overflow that has always existed, it only is triggered by certain
kernel configurations.
(anderson@redhat.com)
diff --git a/memory.c b/memory.c
index 2f568d5..5c0a853 100644
--- a/memory.c
+++ b/memory.c
@@ -17498,13 +17498,12 @@ vm_stat_init(void)
STREQ(arglist[0], "NR_VM_ZONE_STAT_ITEMS")) {
continue;
} else {
- stringlen += strlen(arglist[0]);
+ stringlen += strlen(arglist[0]) + 1;
count++;
}
}
- total = stringlen + vt->nr_vm_stat_items +
- (sizeof(void *) * vt->nr_vm_stat_items);
+ total = stringlen + (sizeof(void *) * vt->nr_vm_stat_items);
if (!(vt->vm_stat_items = (char **)malloc(total))) {
close_tmpfile();
error(FATAL, "cannot malloc vm_stat_items cache\n");
Reference in New Issue View Git Blame Copy Permalink