memory mapping and sort_extable?

pa,

2.6.2-rc2 doesn't boot on my c3k when running 32-bit kernel and if CONFIG_STI_CONSOLE is not enabled. The problem seems to be that for some reason [*] when CONFIG_STI_CONSOLE is not defined, we map all kernel memory as r/o, so when sort_extable (in lib/extable.c) tries to rearrange our exception tables it writes to the kernel pages and faults.

interestingly, when building a 64-bit kernel with similar config options i don't see a fault... maybe there is something else happening there.

From a cursory inspection, it appears that we never use to sort our
exception tables; dumping the extable from a vmlinux binary shows that the entries are properly sorted at link time... but i haven't tried this on modules to see if they are also sorted. Not sure how the sorting is happening... does ld do it?

Anyway, the following patch trivially removes sort_extable for parisc and lets the kernel boot. Not yet sure if it's correct. Does anyone know?

[*] Why do we map kernel pages as read-only? is it just to be "extra safe"?

randolph

Index: include/asm-parisc/uaccess.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-parisc/uaccess.h,v retrieving revision 1.12

diff -u -p -r1.12 uaccess.h
@@ -66,6 +66,8 @@ struct exception_table_entry {
 	long skip;           /* pcoq skip | r9 clear flag | r8 -EFAULT flag */
 };
 
+#define ARCH_HAS_SORT_EXTABLE
+
 #define __get_user(x,ptr)                               \
 ({                                                      \
 	register long __gu_err __asm__ ("r8") = 0;      \

@@ -0,0 +1,7 @@
+#include <asm/uaccess.h>
+
+void sort_extable(struct exception_table_entry *start,
+		  struct exception_table_entry *finish)
+{
+}
+

Index: arch/parisc/mm/Makefile
===================================================================
RCS file: /var/cvs/linux-2.6/arch/parisc/mm/Makefile,v retrieving revision 1.2

diff -u -p -r1.2 Makefile
@@ -2,4 +2,4 @@
 # Makefile for arch/parisc/mm
 #
 
-obj-y	 := init.o fault.o ioremap.o
+obj-y	 := init.o fault.o ioremap.o extable.o

Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Let me have a look at this. It sounds like a section naming issue that differs on 32/64 bit.

Of course, you guessed that I'd only tested on a 64 bit kernel...

We need the sort extable because the generic search function (which we now use) expects a sorted table to simplify address searches, so going back to an unsorted one may produce unexpected results...

James