Skip to contentSkip to conversation

MIPS: fix micro-assembly overflow in set_except_vector

PATCH In review Florian Fainelli 3 participants 4 messages Feb 1, 2010 – Feb 3, 2010 1 message not in the archive MIPS

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 MIPS: fix micro-assembly overflow in set_except_vector

Commit 24a6d9866c5f15ba7e5b14dc17be4b6edba21d0e broke the installation of handlers for boards which have their handlers above a 1 << 26 address. Fix this by making sure that jump_mask does not excess 0xfc000000 and add the missing ~ operator to jump_mask when jumping to the handler address.

---

arch/mips/kernel/traps.c +2 -2
index 7693929..40d94c3 100644
@@ -1279,11 +1279,11 @@ void __init *set_except_vector(int n, void *addr)
 
 	exception_handlers[n] = handler;
 	if (n == 0 && cpu_has_divec) {
-		unsigned long jump_mask = ~((1 << 28) - 1);
+		unsigned long jump_mask = ~((1 << 26) - 1);
 		u32 *buf = (u32 *)(ebase + 0x200);
 		unsigned int k0 = 26;
 		if ((handler & jump_mask) == ((ebase + 0x200) & jump_mask)) {
-			uasm_i_j(&buf, handler & jump_mask);
+			uasm_i_j(&buf, handler & ~jump_mask);
 			uasm_i_nop(&buf);
 		} else {
 			UASM_i_LA(&buf, k0, handler);
Acked-by on v1 1/1
#1 lore raw
Quoted 8 lines · Florian Fainelli

Commit 24a6d9866c5f15ba7e5b14dc17be4b6edba21d0e broke the installation of handlers for boards which have their handlers above a 1 << 26 address. Fix this by making sure that jump_mask does not excess 0xfc000000 and add the missing ~ operator to jump_mask when jumping to the handler address.

Quoted 22 lines

---

arch/mips/kernel/traps.c +2 -2
index 7693929..40d94c3 100644
@@ -1279,11 +1279,11 @@ void __init *set_except_vector(int n, void *addr)
 
 	exception_handlers[n] = handler;
 	if (n == 0 && cpu_has_divec) {
-		unsigned long jump_mask = ~((1 << 28) - 1);
+		unsigned long jump_mask = ~((1 << 26) - 1);
 		u32 *buf = (u32 *)(ebase + 0x200);
 		unsigned int k0 = 26;
 		if ((handler & jump_mask) == ((ebase + 0x200) & jump_mask)) {
-			uasm_i_j(&buf, handler & jump_mask);
+			uasm_i_j(&buf, handler & ~jump_mask);
 			uasm_i_nop(&buf);
 		} else {
 			UASM_i_LA(&buf, k0, handler);

A message that is not in the archive (sent off-list or not yet received): [email protected]

author Acked-by David Daney
#3 lore raw

Hi Thomas,

Quoted 8 lines · On Monday 01 February 2010 11:36:28 Thomas Bogendoerfer wrote:
Quoted 4 lines · Florian Fainelli

Commit 24a6d9866c5f15ba7e5b14dc17be4b6edba21d0e broke the installation of handlers for boards which have their handlers above a 1 << 26 address. Fix this by making sure that jump_mask does not excess 0xfc000000 and add the missing ~ operator

j can handle 28 bit jump targets (26 bit in instruction plus two 0 bits for 32bit aligment), so 0xf000000 was IMHO fine.

Corrected version below, thanks.
---
From: Florian Fainelli <[email protected]>
Subject: [PATCH urgent] MIPS: fix micro-assembly overflow in set_except_vector

Commit 24a6d9866c5f15ba7e5b14dc17be4b6edba21d0e broke the installation of handlers for boards which have their handlers above 0xf0000000. Fix this by adding the missing ~ operator to jump_mask when loading the handler target address into buf.

---

arch/mips/kernel/traps.c +1 -1
index 7693929..af176b8 100644
@@ -1283,7 +1283,7 @@ void __init *set_except_vector(int n, void *addr)
 		u32 *buf = (u32 *)(ebase + 0x200);
 		unsigned int k0 = 26;
 		if ((handler & jump_mask) == ((ebase + 0x200) & jump_mask)) {
-			uasm_i_j(&buf, handler & jump_mask);
+			uasm_i_j(&buf, handler & ~jump_mask);
 			uasm_i_nop(&buf);
 		} else {
 			UASM_i_LA(&buf, k0, handler);
#4 lore raw
Quoted 11 lines · Florian Fainelli
Quoted 8 lines · On Monday 01 February 2010 11:36:28 Thomas Bogendoerfer wrote:
Quoted 4 lines · Florian Fainelli

Commit 24a6d9866c5f15ba7e5b14dc17be4b6edba21d0e broke the installation of handlers for boards which have their handlers above a 1 << 26 address. Fix this by making sure that jump_mask does not excess 0xfc000000 and add the missing ~ operator

j can handle 28 bit jump targets (26 bit in instruction plus two 0 bits for 32bit aligment), so 0xf000000 was IMHO fine.

Corrected version below, thanks.

Folded into the existing -queue patch.

Thanks,

Ralf