Fix in unwind.c
PATCH 1/1 Fix in unwind.c
Current code in unw_create_gate_table() looks like this:
start = (unsigned long) __start_gate_section - segbase;
end = (unsigned long) __stop_gate_section - segbase;
size = 0;
first = lookup(&unw.kernel_table, start);
for (entry = first; entry->start_offset < end; ++entry)
size += 3*8 + 8 + 8*UNW_LENGTH(*(u64 *) (segbase + entry->info_offset));
Code starts with first unwind kernel table entry for the gate page and goes through all the gate page unwind table entries. Assume if all the gate page unwind table entries comes to the end of kernel unwind table(typically this is what happens because of the order in vmlinux.lds.S), then there is a chance that we go past beyond the kernel unwind table and resulting in a fault while we access "segbase + entry->info_offset".
Attached/appended patch fixes this problem.
thanks,
suresh
arch/ia64/kernel/unwind.c renamed from arch/ia64/kernel/unwind.c~ +9 -2
@@ -1998,6 +1998,7 @@extern char __start_gate_section[], __stop_gate_section[];unsigned long *lp, start, end, segbase = unw.kernel_table.segment_base;const struct unw_table_entry *entry, *first; +extern int ia64_unw_end;size_t info_size, size;char *info;
@@ -2006,7 +2007,10 @@ size =0 ; first =lookup (&unw.kernel_table, start); -for (entry = first; entry->start_offset < end; ++entry) +for (entry = first; + (entry < (struct unw_table_entry *) &ia64_unw_end) && + (entry->start_offset < end); + ++entry) size +=3 *8 +8 +8 *UNW_LENGTH (*(u64 *) (segbase + entry->info_offset)); size +=8 ;/* reserve space for "end of table" marker */
@@ -2021,7 +2025,10 @@ lp = unw.gate_table; info = (char *) unw.gate_table + size; -for (entry = first; entry->start_offset < end; ++entry, lp +=3 ) { +for (entry = first; + (entry < (struct unw_table_entry *) &ia64_unw_end) && + (entry->start_offset < end); + ++entry, lp +=3 ) { info_size =8 +8 *UNW_LENGTH (*(u64 *) (segbase + entry->info_offset)); info -= info_size;memcpy (info, (char *) segbase + entry->info_offset, info_size);
arch/ia64/kernel/unwind.c renamed from arch/ia64/kernel/unwind.c~ +9 -2
@@ -1998,6 +1998,7 @@extern char __start_gate_section[], __stop_gate_section[];unsigned long *lp, start, end, segbase = unw.kernel_table.segment_base;const struct unw_table_entry *entry, *first; +extern int ia64_unw_end;size_t info_size, size;char *info;
@@ -2006,7 +2007,10 @@ size =0 ; first =lookup (&unw.kernel_table, start); -for (entry = first; entry->start_offset < end; ++entry) +for (entry = first; + (entry < (struct unw_table_entry *) &ia64_unw_end) && + (entry->start_offset < end); + ++entry) size +=3 *8 +8 +8 *UNW_LENGTH (*(u64 *) (segbase + entry->info_offset)); size +=8 ;/* reserve space for "end of table" marker */
@@ -2021,7 +2025,10 @@ lp = unw.gate_table; info = (char *) unw.gate_table + size; -for (entry = first; entry->start_offset < end; ++entry, lp +=3 ) { +for (entry = first; + (entry < (struct unw_table_entry *) &ia64_unw_end) && + (entry->start_offset < end); + ++entry, lp +=3 ) { info_size =8 +8 *UNW_LENGTH (*(u64 *) (segbase + entry->info_offset)); info -= info_size;memcpy (info, (char *) segbase + entry->info_offset, info_size);
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Suresh B
Suresh> Current code in unw_create_gate_table() looks like this: Suresh> start = (unsigned long) __start_gate_section - segbase; end Suresh> = (unsigned long) __stop_gate_section - segbase; size = 0; Suresh> first = lookup(&unw.kernel_table, start); for (entry Suresh> first; entry->start_offset < end; ++entry) size += 3*8 + 8 + Suresh> 8*UNW_LENGTH(*(u64 *) (segbase + entry->info_offset));
Suresh> Code starts with first unwind kernel table entry for the Suresh> gate page and goes through all the gate page unwind table Suresh> entries. Assume if all the gate page unwind table entries Suresh> comes to the end of kernel unwind table(typically this is Suresh> what happens because of the order in vmlinux.lds.S), then Suresh> there is a chance that we go past beyond the kernel unwind Suresh> table and resulting in a fault while we access "segbase + Suresh> entry->info_offset".
Yes, I agree that's a bug. I fixed it in the source code, though slightly differently from what you had in the patch.
Thanks,
--david