[parisc-linux] memory mapping and sort_extable?

[parisc-linux] memory mapping and sort_extable?

[Randolph Chung]

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
--- include/asm-parisc/uaccess.h	28 Jan 2004 05:27:46 -0000	1.12
+++ include/asm-parisc/uaccess.h	4 Feb 2004 07:16:54 -0000
@@ -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;      \
--- arch/parisc/mm/extable.c	2003-09-24 03:11:46.000000000 -0700
+++ arch/parisc/mm/extable.c	2004-02-03 22:58:41.000000000 -0800
@@ -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
--- arch/parisc/mm/Makefile	27 Jan 2004 18:44:34 -0000	1.2
+++ arch/parisc/mm/Makefile	4 Feb 2004 07:17:20 -0000
@@ -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/

Re: [parisc-linux] memory mapping and sort_extable?

[James Bottomley]

On Wed, 2004-02-04 at 04:43, Randolph Chung wrote:
> 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"?

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