Re: mac_esp bus error handling, was Re: setjmp/longjmp?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, 19 Feb 2008, Finn Thain wrote:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
Oops: 00000000
Modules linked in:
PC: [<000035b8>] buserr_c+0x4a6/0x546
SR: 2704  SP: 0079ba60  a2: 00478030
d0: 00000020    d1: 00000020    d2: 00000000    d3: 00000000
d4: 00000001    d5: 00000000    a0: 50f10100    a1: 001d6bc8
Process dd (pid: 198, task=00478030)
Frame format=7 eff addr=0079ba18 ssw=00a5 faddr=50f10100
wb 1 stat/addr/data: 00a5 50f10100 00000000
wb 2 stat/addr/data: 0025 50f10100 00000000
wb 3 stat/addr/data: 0045 0079bb58 00000000
push data: 00000000 00102000 0000362a 0079baf8
Stack from 0079bac8:
        00000000 0007a120 00000000 00000000 00000001 00501f80 0802b001 005282a0
        00273078 0079bb14 0000271a 0079baf8 00000000 00000000 0007a120 00000000
        00000000 50f10100 00001a00 00478030 00000001 ffffffff 00000034 27040016
                                                                         ^^^^^^^^
        6be47008 0079bb48 00a50025 00a500a5 50f10100 50f10100 00000000 50f10100
          ^^^^^^^^
Exception frames are a little difficult to handle for a simple call trace, 
as the exception address is misaligned, so it's not always immediately 
visible.
Anyway, above is the frame header and the exception originally came from 
0x166be4, which is:

(gdb) x/i 0x166be4
0x166be4 <mac_esp_send_pdma_cmd+424>:   nop

which I guess is expected at this point.


        00000000 50f10100 00000000 00000000 27040016 6be60008 00000000 00533050
                                              ^^^^^^^^^^^^^^^^^
        0802a800 00163b62 00000001 0079bec6 00000800 002aa970 005282a0 00163ba8

Here is another frame header, which points to:

(gdb) x/i 0x166be6
0x166be6 <mac_esp_send_pdma_cmd+426>:   moveal %a5@(16),%a0

which is the exception exit, so we already called send_fault_sig() which 
sets up everything for the proper exception exit.

The only missing bit is to skip the writeback, as the fault has to be 
first fixed by the caller, so the patch below should do the trick...

bye, Roman

---
 arch/m68k/kernel/traps.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

Index: linux-2.6/arch/m68k/kernel/traps.c
===================================================================
--- linux-2.6.orig/arch/m68k/kernel/traps.c
+++ linux-2.6/arch/m68k/kernel/traps.c
@@ -477,9 +477,16 @@ static inline void access_error040(struc
 			if (fp->un.fmt7.wb3a == fp->un.fmt7.faddr)
 				fp->un.fmt7.wb3s &= ~WBV_040;
 		}
-	} else if (send_fault_sig(&fp->ptregs) > 0) {
-		printk("68040 access error, ssw=%x\n", ssw);
-		trap_c(fp);
+	} else {
+		/* In case of a bus error we either kill the process or expect
+		 * the kernel to catch the fault, which then is also responsible
+		 * for cleaning up the mess, so skip writebacks.
+		 */
+		current->thread.signo = SIGBUS;
+		current->thread.faddr = fp->un.fmt7.faddr;
+		if (send_fault_sig(&fp->ptregs) > 0)
+			printk("68040 access error, ssw=%x\n", ssw);
+		return;
 	}
 
 	do_040writebacks(fp);
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux