All of lore.kernel.org
 help / color / mirror / Atom feed
* exception tables in 2.5.55
@ 2003-01-09  6:20 Miles Bader
  2003-01-10  8:30 ` Rusty Russell
  0 siblings, 1 reply; 9+ messages in thread
From: Miles Bader @ 2003-01-09  6:20 UTC (permalink / raw)
  To: Rusty Russell, Greg Ungerer, David McCullough; +Cc: linux-kernel

I'm building for the v850, which has no MMU.

Starting with 2.5.55, I'm getting link errors like:

  kernel/extable.c:29: undefined reference to `search_extable'

I didn't have to worry about this with earlier kernels, and it looks
like what happened is that previously arch-specific code was
consolidated into the generic kernel.

As far as I can see, the purpose of exception tables is to deal with
unexpected memory access traps and on the v850, this basically can't
happen (there's no MMU, and no way I know of to detect non-existant
memory).  So I'd like to make the generic exception handling stuff
optional.

However, I'm not sure the best way to do this -- I could try to make it
dependent on CONFIG_MMU, but are there non-MMU processors that _can_
usefully use exception tables (in which case perhaps there should just
be a separate CONFIG_EXTABLES or something)?

[Oh, and also, please tell me if I'm mistaken about the purpose of
these tables and really _should_ just implement them.]

Thanks,

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: exception tables in 2.5.55
  2003-01-09  6:20 exception tables in 2.5.55 Miles Bader
@ 2003-01-10  8:30 ` Rusty Russell
  2003-01-13  3:12   ` Greg Ungerer
  0 siblings, 1 reply; 9+ messages in thread
From: Rusty Russell @ 2003-01-10  8:30 UTC (permalink / raw)
  To: Miles Bader; +Cc: linux-kernel, Greg Ungerer, David McCullough, torvalds

In message <buo1y3msv2e.fsf@mcspd15.ucom.lsi.nec.co.jp> you write:
> I'm building for the v850, which has no MMU.
> 
> Starting with 2.5.55, I'm getting link errors like:
> 
>   kernel/extable.c:29: undefined reference to `search_extable'
> 
> I didn't have to worry about this with earlier kernels, and it looks
> like what happened is that previously arch-specific code was
> consolidated into the generic kernel.

Yes.  This patch (like most of the module stuff) was written long
before the mmuless archs were merged.  It didn't occur to me to look
through all the archs again.

> As far as I can see, the purpose of exception tables is to deal with
> unexpected memory access traps and on the v850, this basically can't
> happen (there's no MMU, and no way I know of to detect non-existant
> memory).  So I'd like to make the generic exception handling stuff
> optional.

You can now make kernel/extable.o depend on this configuration option
(whatever you decide it should be).

And surround kernel/module.c's search_module_extables with the same
option.

It's trivial, just CC: me when you send to Linus, and I'll re-xmit if
he drops it.

> However, I'm not sure the best way to do this -- I could try to make it
> dependent on CONFIG_MMU, but are there non-MMU processors that _can_
> usefully use exception tables (in which case perhaps there should just
> be a separate CONFIG_EXTABLES or something)?
> 
> [Oh, and also, please tell me if I'm mistaken about the purpose of
> these tables and really _should_ just implement them.]

No, they're for copy_to/from_user and friends.  If your arch doesn't
rely on exception handling to trap wierd accesses, you can turn this
off.

Hope that helps,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: exception tables in 2.5.55
  2003-01-10  8:30 ` Rusty Russell
@ 2003-01-13  3:12   ` Greg Ungerer
  2003-01-13  3:24     ` Linus Torvalds
  0 siblings, 1 reply; 9+ messages in thread
From: Greg Ungerer @ 2003-01-13  3:12 UTC (permalink / raw)
  To: Rusty Russell; +Cc: Miles Bader, linux-kernel, David McCullough, torvalds

Hi All,

Rusty Russell wrote:
> You can now make kernel/extable.o depend on this configuration option
> (whatever you decide it should be).
> 
> And surround kernel/module.c's search_module_extables with the same
> option.
> 
> It's trivial, just CC: me when you send to Linus, and I'll re-xmit if
> he drops it.

Heres a patch for it. Pretty strait forward, if everyone is
happy with this I will run with it...

Tested and working on m68knommu architecture.

Regards
Greg




diff -Naur linux-2.5.56/kernel/Makefile linux-2.5.56-uc0/kernel/Makefile
--- linux-2.5.56/kernel/Makefile	Sat Jan 11 06:11:36 2003
+++ linux-2.5.56-uc0/kernel/Makefile	Mon Jan 13 13:03:45 2003
@@ -10,7 +10,7 @@
  	    exit.o itimer.o time.o softirq.o resource.o \
  	    sysctl.o capability.o ptrace.o timer.o user.o \
  	    signal.o sys.o kmod.o workqueue.o futex.o pid.o \
-	    rcupdate.o intermodule.o extable.o params.o
+	    rcupdate.o intermodule.o params.o

  obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
  obj-$(CONFIG_SMP) += cpu.o
@@ -22,6 +22,7 @@
  obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
  obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend.o
  obj-$(CONFIG_COMPAT) += compat.o
+obj-$(CONFIG_MMU) += extable.o

  ifneq ($(CONFIG_IA64),y)
  # According to Alan Modra <alan@linuxcare.com.au>, the 
-fno-omit-frame-pointer is
diff -Naur linux-2.5.56/kernel/module.c linux-2.5.56-uc0/kernel/module.c
--- linux-2.5.56/kernel/module.c	Sat Jan 11 06:12:11 2003
+++ linux-2.5.56-uc0/kernel/module.c	Mon Jan 13 13:06:00 2003
@@ -1438,6 +1438,7 @@
  	.show	= m_show
  };

+#ifdef CONFIG_MMU
  /* Given an address, look for it in the module exception tables. */
  const struct exception_table_entry *search_module_extables(unsigned 
long addr)
  {
@@ -1460,6 +1461,7 @@
             we cannot unload the module, hence no refcnt needed. */
  	return e;
  }
+#endif /* CONFIG_MMU */

  /* Is this a valid kernel address?  We don't grab the lock: we are 
oopsing. */
  int module_text_address(unsigned long addr)


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg@snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: exception tables in 2.5.55
  2003-01-13  3:12   ` Greg Ungerer
@ 2003-01-13  3:24     ` Linus Torvalds
  2003-01-13  3:49       ` Greg Ungerer
  0 siblings, 1 reply; 9+ messages in thread
From: Linus Torvalds @ 2003-01-13  3:24 UTC (permalink / raw)
  To: Greg Ungerer; +Cc: Rusty Russell, Miles Bader, linux-kernel, David McCullough


On Mon, 13 Jan 2003, Greg Ungerer wrote:
> 
> Tested and working on m68knommu architecture.

Why does exceptions have anything to do with no-mmu?

There are exceptions that have nothing to do with MMU's, and a no-mmu 
architecture should still support them.  On x86, we have a number of such 
exceptions, for example general protection stuff for wrong values for 
special registers etc.

In other words, not applied. Page table exceptions are just the most 
_common_ exception type, but there's absolutely nothing in the mechanism 
that has anything at all to do with MMU-less.

If some archtiecture happens to have an empty exception table, that's 
fine. 

		Linus


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: exception tables in 2.5.55
  2003-01-13  3:24     ` Linus Torvalds
@ 2003-01-13  3:49       ` Greg Ungerer
  2003-01-13  5:21         ` Miles Bader
  2003-01-13  5:26         ` Rusty Russell
  0 siblings, 2 replies; 9+ messages in thread
From: Greg Ungerer @ 2003-01-13  3:49 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Rusty Russell, Miles Bader, linux-kernel, David McCullough

Hi Linus,

Linus Torvalds wrote:
> On Mon, 13 Jan 2003, Greg Ungerer wrote:
> 
>>Tested and working on m68knommu architecture.
> 
> 
> Why does exceptions have anything to do with no-mmu?
> 
> There are exceptions that have nothing to do with MMU's, and a no-mmu 
> architecture should still support them.  On x86, we have a number of such 
> exceptions, for example general protection stuff for wrong values for 
> special registers etc.
> 
> In other words, not applied.

Good thing I was only after comments then :-)


> Page table exceptions are just the most 
> _common_ exception type, but there's absolutely nothing in the mechanism 
> that has anything at all to do with MMU-less.
> 
> If some archtiecture happens to have an empty exception table, that's 
> fine. 

OK, heres an alternative patch that fully supports exception tables
for m68knommu (Miles you'll need to do the same for v850).

This is tested on my ColdFire targets...

Regards
Greg




diff -Naur linux-2.5.56/arch/m68knommu/mm/Makefile 
linux-2.5.56-uc0/arch/m68knommu/mm/Makefile
--- linux-2.5.56/arch/m68knommu/mm/Makefile	Sat Jan 11 06:12:25 2003
+++ linux-2.5.56-uc0/arch/m68knommu/mm/Makefile	Mon Jan 13 13:43:22 2003
@@ -2,4 +2,4 @@
  # Makefile for the linux m68knommu specific parts of the memory manager.
  #

-obj-y += init.o fault.o memory.o kmap.o
+obj-y += init.o fault.o memory.o kmap.o extable.o
diff -Naur linux-2.5.56/arch/m68knommu/mm/extable.c 
linux-2.5.56-uc0/arch/m68knommu/mm/extable.c
--- linux-2.5.56/arch/m68knommu/mm/extable.c	Thu Jan  1 10:00:00 1970
+++ linux-2.5.56-uc0/arch/m68knommu/mm/extable.c	Mon Jan 13 13:43:08 
2003@@ -0,0 +1,30 @@
+/*
+ * linux/arch/m68knommu/mm/extable.c
+ */
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <asm/uaccess.h>
+
+/* Simple binary search */
+const struct exception_table_entry *
+search_extable(const struct exception_table_entry *first,
+	       const struct exception_table_entry *last,
+	       unsigned long value)
+{
+        while (first <= last) {
+		const struct exception_table_entry *mid;
+		long diff;
+
+		mid = (last - first) / 2 + first;
+		diff = mid->insn - value;
+                if (diff == 0)
+                        return mid;
+                else if (diff < 0)
+                        first = mid+1;
+                else
+                        last = mid-1;
+        }
+        return NULL;
+}

------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg@snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: exception tables in 2.5.55
  2003-01-13  3:49       ` Greg Ungerer
@ 2003-01-13  5:21         ` Miles Bader
  2003-01-13  5:26         ` Rusty Russell
  1 sibling, 0 replies; 9+ messages in thread
From: Miles Bader @ 2003-01-13  5:21 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: Linus Torvalds, Rusty Russell, linux-kernel, David McCullough

On Mon, Jan 13, 2003 at 01:49:42PM +1000, Greg Ungerer wrote:
> >There are exceptions that have nothing to do with MMU's, and a no-mmu 
> >architecture should still support them.  On x86, we have a number of such 
> >exceptions, for example general protection stuff for wrong values for 
> >special registers etc.
> 
> OK, heres an alternative patch that fully supports exception tables
> for m68knommu (Miles you'll need to do the same for v850).

On the v850, there are, to my knowledge, no usable exceptions (the only such
thing is illegal insn, which shouldn't occur, I think).

The latest patches I already sent to Linus handle this by just making
search_extable an inline in asm/module.h:

   /* We don't do exception tables.  */
   struct exception_table_entry;
   static inline const struct exception_table_entry *
   search_extable(const struct exception_table_entry *first,
		  const struct exception_table_entry *last,
	          unsigned long value)
   {
	   return 0;
   }

This allows gcc to remove a bit of the generic exception-table code, but I
was sort of hoping to have something like CONFIG_EXTABLES to get rid of the
rest of it (or maybe CONFIG_INHIBIT_EXTABLES since most archs want them).

As greg showed, this is simple to do, though I suppose the resulting savings
isn't much, and there are many many other places which might more profitably
be pruned...

[OTOH, little bits do add up, and for some reason this particular bit of code
seems extra gratuitous since it was previously arch-specific and I didn't
have to worry about it]

-Miles 
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: exception tables in 2.5.55
  2003-01-13  3:49       ` Greg Ungerer
  2003-01-13  5:21         ` Miles Bader
@ 2003-01-13  5:26         ` Rusty Russell
  2003-01-13 21:03           ` Horst von Brand
  1 sibling, 1 reply; 9+ messages in thread
From: Rusty Russell @ 2003-01-13  5:26 UTC (permalink / raw)
  To: Greg Ungerer; +Cc: Linus Torvalds, Miles Bader, linux-kernel, David McCullough

In message <3E223756.3010200@snapgear.com> you write:
> OK, heres an alternative patch that fully supports exception tables
> for m68knommu (Miles you'll need to do the same for v850).

This seems way overkill.  How about you move the search_extable()
prototype out of linux/module.h and into each asm/uaccess.h, then:

include/asm-m68knommu/uaccess.h:

	/* We don't use such things. */
	struct exception_table_entry
	{
		int unused;
	};

	#define search_extable(first, last, value) ({ BUG(); NULL; })

Thoughts?
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: exception tables in 2.5.55
  2003-01-13  5:26         ` Rusty Russell
@ 2003-01-13 21:03           ` Horst von Brand
  2003-01-14  8:28             ` Rusty Russell
  0 siblings, 1 reply; 9+ messages in thread
From: Horst von Brand @ 2003-01-13 21:03 UTC (permalink / raw)
  To: Rusty Russell; +Cc: linux-kernel

[Massive snippage of Cc:]
Rusty Russell <rusty@rustcorp.com.au>

[...]

> This seems way overkill.  How about you move the search_extable()
> prototype out of linux/module.h and into each asm/uaccess.h, then:
> 
> include/asm-m68knommu/uaccess.h:
> 
> 	/* We don't use such things. */
> 	struct exception_table_entry
> 	{
> 		int unused;
> 	};

Why not just an empty structure?
--
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: exception tables in 2.5.55
  2003-01-13 21:03           ` Horst von Brand
@ 2003-01-14  8:28             ` Rusty Russell
  0 siblings, 0 replies; 9+ messages in thread
From: Rusty Russell @ 2003-01-14  8:28 UTC (permalink / raw)
  To: Horst von Brand; +Cc: linux-kernel

In message <200301132103.h0DL3R0p001528@eeyore.valparaiso.cl> you write:
> [Massive snippage of Cc:]
> Rusty Russell <rusty@rustcorp.com.au>
> 
> [...]
> 
> > This seems way overkill.  How about you move the search_extable()
> > prototype out of linux/module.h and into each asm/uaccess.h, then:
> > 
> > include/asm-m68knommu/uaccess.h:
> > 
> > 	/* We don't use such things. */
> > 	struct exception_table_entry
> > 	{
> > 		int unused;
> > 	};
> 
> Why not just an empty structure?

Ancient compilers.  See linux/spinlock.h.  Since it's not actually
used, putting in a #ifdef is overkill...

Hope that helps!
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2003-01-14  8:31 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-09  6:20 exception tables in 2.5.55 Miles Bader
2003-01-10  8:30 ` Rusty Russell
2003-01-13  3:12   ` Greg Ungerer
2003-01-13  3:24     ` Linus Torvalds
2003-01-13  3:49       ` Greg Ungerer
2003-01-13  5:21         ` Miles Bader
2003-01-13  5:26         ` Rusty Russell
2003-01-13 21:03           ` Horst von Brand
2003-01-14  8:28             ` Rusty Russell

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.