parisc: fix kernel crash when unwinding a userspace process

PATCH In review Helge Deller 6 participants 18 messages Nov 20, 2008 – Dec 3, 2008 PA-RISC architecture

Share & tools

Helge Deller

author maintainer

2008-11-20 21:58 UTC #0 lore raw

PATCH 1/1 parisc: fix kernel crash when unwinding a userspace process

Any user on existing parisc 32- and 64bit-kernels can easily crash the kernel and as such enforce a DSO.
A simple testcase is available here:
http://gsyprf10.external.hp.com/~deller/crash.tgz

The problem is introduced by the fact, that the handle_interruption() crash handler calls the show_regs() function, which in turn tries to unwind the stack by calling parisc_show_stack().
Since the stack contains userspace addresses, a try to unwind the stack is dangerous and useless and leads to the crash.

The fix is trivial: For userspace processes
a) avoid to unwind the stack, and
b) avoid to resolve userspace addresses to kernel symbol names.

While touching this code, I converted print_symbol() to %pS printk formats and made parisc_show_stack() static.

An initial patch for this was written by Kyle McMartin back in August:
http://marc.info/?l=linux-parisc&m=121805168830283&w=2

Compile and run-tested with a 64bit parisc kernel. Patches for -stable series will follow shortly.

Signed-off-by Helge Deller <[email protected]>

arch/parisc/kernel/traps.c +17 ~~-22~~

index 675f1d0..acea2dc 100644
@@ -24,7 +24,6 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/console.h>
-#include <linux/kallsyms.h>
 #include <linux/bug.h>
 
 #include <asm/assembly.h>

@@ -51,7 +50,7 @@
 DEFINE_SPINLOCK(pa_dbit_lock);
 #endif
 
-void parisc_show_stack(struct task_struct *t, unsigned long *sp,
+static void parisc_show_stack(struct task_struct *task, unsigned long *sp,
 	struct pt_regs *regs);
 
 static int printbinary(char *buf, unsigned long x, int nbits)

@@ -121,18 +120,19 @@ static void print_fr(char *level, struct pt_regs *regs)
 
 void show_regs(struct pt_regs *regs)
 {
-	int i;
+	int i, user;
 	char *level;
 	unsigned long cr30, cr31;
 
-	level = user_mode(regs) ? KERN_DEBUG : KERN_CRIT;
+	user = user_mode(regs);
+	level = user ? KERN_DEBUG : KERN_CRIT;
 
 	print_gr(level, regs);
 
 	for (i = 0; i < 8; i += 4)
 		PRINTREGS(level, regs->sr, "sr", RFMT, i);
 
-	if (user_mode(regs))
+	if (user)
 		print_fr(level, regs);
 
 	cr30 = mfctl(30);

@@ -145,14 +145,14 @@ void show_regs(struct pt_regs *regs)
 	printk("%s CPU: %8d   CR30: " RFMT " CR31: " RFMT "\n",
 	       level, current_thread_info()->cpu, cr30, cr31);
 	printk("%s ORIG_R28: " RFMT "\n", level, regs->orig_r28);
-	printk(level);
-	print_symbol(" IAOQ[0]: %s\n", regs->iaoq[0]);
-	printk(level);
-	print_symbol(" IAOQ[1]: %s\n", regs->iaoq[1]);
-	printk(level);
-	print_symbol(" RP(r2): %s\n", regs->gr[2]);
-
-	parisc_show_stack(current, NULL, regs);
+
+	if (!user) {
+		printk("%s IAOQ[0]: %pS\n", level, (void *) regs->iaoq[0]);
+		printk("%s IAOQ[1]: %pS\n", level, (void *) regs->iaoq[1]);
+		printk("%s RP(r2): %pS\n", level, (void *) regs->gr[2]);
+
+		parisc_show_stack(current, NULL, regs);
+	}
 }

@@ -173,20 +173,15 @@ static void do_show_stack(struct unwind_frame_info *info)
 			break;
 
 		if (__kernel_text_address(info->ip)) {
-			printk("%s [<" RFMT ">] ", (i&0x3)==1 ? KERN_CRIT : "", info->ip);
-#ifdef CONFIG_KALLSYMS
-			print_symbol("%s\n", info->ip);
-#else
-			if ((i & 0x03) == 0)
-				printk("\n");
-#endif
+			printk(KERN_CRIT " [<" RFMT ">] %pS\n",
+				info->ip, (void *) info->ip);
 			i++;
 		}
 	}
-	printk("\n");
+	printk(KERN_CRIT "\n");
 }
 
-void parisc_show_stack(struct task_struct *task, unsigned long *sp,
+static void parisc_show_stack(struct task_struct *task, unsigned long *sp,
 	struct pt_regs *regs)
 {
 	struct unwind_frame_info info;

Randolph Chung

2008-11-21 10:11 UTC #1 lore raw

Quoted 9 lines · Helge Deller

Any user on existing parisc 32- and 64bit-kernels can easily crash the kernel and as such enforce a DSO.
A simple testcase is available here:
http://gsyprf10.external.hp.com/~deller/crash.tgz
The problem is introduced by the fact, that the handle_interruption()
crash handler calls the show_regs() function, which in turn tries
to unwind the stack by calling parisc_show_stack().
Since the stack contains userspace addresses, a try to unwind the stack is dangerous and useless and leads to the crash.

Helge,

I think this is ok, but can you preserve the printing of IAOQ/RP even for user processes?

randolph

Helge Deller

author maintainer

2008-11-21 14:02 UTC #2 lore raw

Quoted 6 lines · Randolph Chung

Quoted 5 lines · Helge Deller
Any user on existing parisc 32- and 64bit-kernels can easily crash the kernel and as such enforce a DSO.
A simple testcase is available here:
http://gsyprf10.external.hp.com/~deller/crash.tgz

Quoted 8 lines

Quoted 4 lines
The problem is introduced by the fact, that the handle_interruption()
crash handler calls the show_regs() function, which in turn tries
to unwind the stack by calling parisc_show_stack().
Since the stack contains userspace addresses, a try to unwind the stack is dangerous and useless and leads to the crash.
Helge,
I think this is ok, but can you preserve the printing of IAOQ/RP even for user processes?

Thanks Randolph,

You are probably right. It's better to stay consistent for debugging and you'll see the important registers at once. I'll respin a new patch.

Helge

Helge Deller

author maintainer

2008-11-21 14:16 UTC #3 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

In reply to Helge Deller

Any user on existing parisc 32- and 64bit-kernels can easily crash the kernel and as such enforce a DSO.
A simple testcase is available here:
http://gsyprf10.external.hp.com/~deller/crash.tgz

The fix is trivial: For userspace processes
a) avoid to unwind the stack, and
b) avoid to resolve userspace addresses to kernel symbol names.

While touching this code, I converted print_symbol() to %pS printk formats and made parisc_show_stack() static.

An initial patch for this was written by Kyle McMartin back in August:
http://marc.info/?l=linux-parisc&m=121805168830283&w=2

Compile and run-tested with a 64bit parisc kernel. Patches for -stable series will follow shortly.

Signed-off-by Helge Deller <[email protected]>

arch/parisc/kernel/traps.c +21 ~~-22~~

index 675f1d0..4c771cd 100644
@@ -24,7 +24,6 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/console.h>
-#include <linux/kallsyms.h>
 #include <linux/bug.h>
 
 #include <asm/assembly.h>

@@ -51,7 +50,7 @@
 DEFINE_SPINLOCK(pa_dbit_lock);
 #endif
 
-void parisc_show_stack(struct task_struct *t, unsigned long *sp,
+static void parisc_show_stack(struct task_struct *task, unsigned long *sp,
 	struct pt_regs *regs);
 
 static int printbinary(char *buf, unsigned long x, int nbits)

@@ -121,18 +120,19 @@ static void print_fr(char *level, struct pt_regs *regs)
 
 void show_regs(struct pt_regs *regs)
 {
-	int i;
+	int i, user;
 	char *level;
 	unsigned long cr30, cr31;
 
-	level = user_mode(regs) ? KERN_DEBUG : KERN_CRIT;
+	user = user_mode(regs);
+	level = user ? KERN_DEBUG : KERN_CRIT;
 
 	print_gr(level, regs);
 
 	for (i = 0; i < 8; i += 4)
 		PRINTREGS(level, regs->sr, "sr", RFMT, i);
 
-	if (user_mode(regs))
+	if (user)
 		print_fr(level, regs);
 
 	cr30 = mfctl(30);

@@ -145,14 +145,18 @@ void show_regs(struct pt_regs *regs)
 	printk("%s CPU: %8d   CR30: " RFMT " CR31: " RFMT "\n",
 	       level, current_thread_info()->cpu, cr30, cr31);
 	printk("%s ORIG_R28: " RFMT "\n", level, regs->orig_r28);
-	printk(level);
-	print_symbol(" IAOQ[0]: %s\n", regs->iaoq[0]);
-	printk(level);
-	print_symbol(" IAOQ[1]: %s\n", regs->iaoq[1]);
-	printk(level);
-	print_symbol(" RP(r2): %s\n", regs->gr[2]);
-
-	parisc_show_stack(current, NULL, regs);
+
+	if (user) {
+		printk("%s IAOQ[0]: " RFMT "\n", level, regs->iaoq[0]);
+		printk("%s IAOQ[1]: " RFMT "\n", level, regs->iaoq[1]);
+		printk("%s RP(r2): " RFMT "\n", level, regs->gr[2]);
+	} else {
+		printk("%s IAOQ[0]: %pS\n", level, (void *) regs->iaoq[0]);
+		printk("%s IAOQ[1]: %pS\n", level, (void *) regs->iaoq[1]);
+		printk("%s RP(r2): %pS\n", level, (void *) regs->gr[2]);
+
+		parisc_show_stack(current, NULL, regs);
+	}
 }

@@ -173,20 +177,15 @@ static void do_show_stack(struct unwind_frame_info *info)
 			break;
 
 		if (__kernel_text_address(info->ip)) {
-			printk("%s [<" RFMT ">] ", (i&0x3)==1 ? KERN_CRIT : "", info->ip);
-#ifdef CONFIG_KALLSYMS
-			print_symbol("%s\n", info->ip);
-#else
-			if ((i & 0x03) == 0)
-				printk("\n");
-#endif
+			printk(KERN_CRIT " [<" RFMT ">] %pS\n",
+				info->ip, (void *) info->ip);
 			i++;
 		}
 	}
-	printk("\n");
+	printk(KERN_CRIT "\n");
 }
 
-void parisc_show_stack(struct task_struct *task, unsigned long *sp,
+static void parisc_show_stack(struct task_struct *task, unsigned long *sp,
 	struct pt_regs *regs)
 {
 	struct unwind_frame_info info;

Andrew Morton

2008-11-21 19:17 UTC #4 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

Quoted 15 lines · On Fri, 21 Nov 2008 15:16:50 +0100 Helge Deller <[email protected]> wrote:

Any user on existing parisc 32- and 64bit-kernels can easily crash the kernel and as such enforce a DSO.
A simple testcase is available here:
http://gsyprf10.external.hp.com/~deller/crash.tgz
The problem is introduced by the fact, that the handle_interruption() crash handler calls the show_regs() function, which in turn tries to unwind the stack by calling parisc_show_stack().
Since the stack contains userspace addresses, a try to unwind the stack is dangerous and useless and leads to the crash.
The fix is trivial: For userspace processes
a) avoid to unwind the stack, and
b) avoid to resolve userspace addresses to kernel symbol names.

Quoted 7 lines

While touching this code, I converted print_symbol() to %pS printk formats and made parisc_show_stack() static.
An initial patch for this was written by Kyle McMartin back in August:
http://marc.info/?l=linux-parisc&m=121805168830283&w=2
Compile and run-tested with a 64bit parisc kernel.

Why has a fix for such a severe bug been floating around unmerged for such a long time?

Quoted 1 line

Patches for -stable series will follow shortly.

That shouldn't be needed - I'll cc stable on my copy and the stable maintainers should see that and pick it up. The patch applies cleanly all the way back to 2.6.25.

Helge Deller

author maintainer

2008-11-21 22:00 UTC #5 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

Quoted 19 lines · Andrew Morton

Quoted 16 lines · On Fri, 21 Nov 2008 15:16:50 +0100 Helge Deller <[email protected]> wrote:
Any user on existing parisc 32- and 64bit-kernels can easily crash the kernel and as such enforce a DSO.
A simple testcase is available here:
http://gsyprf10.external.hp.com/~deller/crash.tgz
The problem is introduced by the fact, that the handle_interruption()
crash handler calls the show_regs() function, which in turn tries
to unwind the stack by calling parisc_show_stack().
Since the stack contains userspace addresses, a try to unwind the stack is dangerous and useless and leads to the crash.
The fix is trivial: For userspace processes
a) avoid to unwind the stack, and
b) avoid to resolve userspace addresses to kernel symbol names.
While touching this code, I converted print_symbol() to %pS printk formats and made parisc_show_stack() static.

Quoted 7 lines

Quoted 4 lines
An initial patch for this was written by Kyle McMartin back in August:
http://marc.info/?l=linux-parisc&m=121805168830283&w=2
Compile and run-tested with a 64bit parisc kernel.
Why has a fix for such a severe bug been floating around unmerged for such a long time?

I've tried to push it upstream a few times...

Quoted 5 lines

Quoted 1 line
Patches for -stable series will follow shortly.
That shouldn't be needed - I'll cc stable on my copy and the stable maintainers should see that and pick it up. The patch applies cleanly all the way back to 2.6.25.

Although it may apply to the older stable kernels, I'm currently not sure if this will work then.
We added the fixes for PA for the '%pS' vsprintf format pretty late. This is probably then a patch which needs backporting to stable as well (if it didn't happened yet):

	commit deac93df26b20cf8438339b5935b5f5643bc30c9
	Author: James Bottomley <[email protected]>
	Date:   Wed Sep 3 20:43:36 2008 -0500
	lib: Correct printk %pF to work on all architectures

Alternatively, I could write a little more simple patch, which is what I
intended initially.

Thanks a lot Andrew!
Helge

Andrew Morton

2008-11-21 22:20 UTC #6 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

Quoted 25 lines · On Fri, 21 Nov 2008 23:00:06 +0100 Helge Deller <[email protected]> wrote:

Quoted 24 lines · Andrew Morton
Quoted 21 lines · On Fri, 21 Nov 2008 15:16:50 +0100 Helge Deller <[email protected]> wrote:
Any user on existing parisc 32- and 64bit-kernels can easily crash the kernel and as such enforce a DSO.
A simple testcase is available here:
http://gsyprf10.external.hp.com/~deller/crash.tgz
The problem is introduced by the fact, that the handle_interruption() crash handler calls the show_regs() function, which in turn tries to unwind the stack by calling parisc_show_stack().
Since the stack contains userspace addresses, a try to unwind the stack is dangerous and useless and leads to the crash.
The fix is trivial: For userspace processes
a) avoid to unwind the stack, and
b) avoid to resolve userspace addresses to kernel symbol names.
While touching this code, I converted print_symbol() to %pS printk formats and made parisc_show_stack() static.
An initial patch for this was written by Kyle McMartin back in August:
http://marc.info/?l=linux-parisc&m=121805168830283&w=2

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
Compile and run-tested with a 64bit parisc kernel.
Why has a fix for such a severe bug been floating around unmerged for such a long time?
I've tried to push it upstream a few times...

OK, well I'll merge it next week unless someone stops me.

Quoted 11 lines

Quoted 5 lines
Quoted 1 line
Patches for -stable series will follow shortly.
That shouldn't be needed - I'll cc stable on my copy and the stable maintainers should see that and pick it up. The patch applies cleanly all the way back to 2.6.25.
Although it may apply to the older stable kernels, I'm currently not sure if this will work then.
We added the fixes for PA for the '%pS' vsprintf format pretty late. This is probably then a patch which needs backporting to stable as well (if it didn't happened yet):

Quoted 4 lines

	commit deac93df26b20cf8438339b5935b5f5643bc30c9
	Author: James Bottomley <[email protected]>
	Date:   Wed Sep 3 20:43:36 2008 -0500
	lib: Correct printk %pF to work on all architectures

Oh, OK. I'll update the stable tag in the patch appropriately.

Quoted 2 lines

Alternatively, I could write a little more simple patch, which is what I
intended initially.

I'd suggest that you send that patch to [email protected] in reply to this one when you see it get dropped from -mm.

Unless someone stops me ;)

Grant Grundler

2008-11-22 05:53 UTC #7 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

On Fri, Nov 21, 2008 at 02:20:13PM -0800, Andrew Morton wrote:
...

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
Why has a fix for such a severe bug been floating around unmerged for such a long time?

Three people are listed for parisc-linux in MAINTAINERS. My understanding was Kyle would integrate and push patches. Willy and I would help by reviewing code, testing and misc crap.

I asked if I should ACK parisc specific patches and was told in general I didn't need to. I will start sending "Reviewed By:" when I feel I understand what a patch fixes and that it's correct (even if not perfect).

Quoted 3 lines

Quoted 1 line
I've tried to push it upstream a few times...
OK, well I'll merge it next week unless someone stops me.

I won't stop you. :)
Based on this posting:

    http://marc.info/?l=linux-parisc&m=122726233324164&w=2

you can add:

Review-by Randolph Chung <[email protected]>

I trust Randolph - he used to have commit access to the parisc-linux.org CVS tree when we still used one.

And Helge has been great about fixing stuff - much better than the three listed maintainers lately.
Kyle, willy, any objection to adding Helge to the MAINTAINERS list for PARISC port?
I'd rather allow Helge to make a few small mistakes occasionally rather than watch his parisc specific patches fall on the floor.

thanks,
grant

Matthew Wilcox

2008-11-22 12:22 UTC #8 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

Quoted 6 lines · Grant Grundler

And Helge has been great about fixing stuff - much better than the three listed maintainers lately.
Kyle, willy, any objection to adding Helge to the MAINTAINERS list for PARISC port?
I'd rather allow Helge to make a few small mistakes occasionally rather than watch his parisc specific patches fall on the floor.

No objection from me. I think it's time to remove me from MAINTAINERS as it's probably been six months since I last turned on any of my parisc machines.

Signature · 4 lines

Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Grant Grundler

Reviewed-by Matthew Wilcox

2008-11-22 18:01 UTC #9 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

Quoted 11 lines · Matthew Wilcox

Quoted 6 lines · Grant Grundler
And Helge has been great about fixing stuff - much better than the three listed maintainers lately.
Kyle, willy, any objection to adding Helge to the MAINTAINERS list for PARISC port?
I'd rather allow Helge to make a few small mistakes occasionally rather than watch his parisc specific patches fall on the floor.
No objection from me. I think it's time to remove me from MAINTAINERS as it's probably been six months since I last turned on any of my parisc machines.

Thanks! We have quorum.
Andrew can you please apply this and send to linus?
Or should I start acting like a maintainer and send it myself? :)

Willy, I'm not removing you from Cupertino test ring LDAP or any other privileges unless you ask me to. Just note I appreciate all of your past (and future) help with the port and you are always welcome in Mountain View.

thanks,
grant

Signed-off-by Grant Grundler <[email protected]>

Reviewed-by Matthew Wilcox <[email protected]>

MAINTAINERS +2 -2

index 618c1ef..5b5034c 100644
@@ -3294,8 +3294,8 @@ S:	Maintained
 PARISC ARCHITECTURE
 P:	Kyle McMartin
 M:	[email protected]
-P:	Matthew Wilcox
-M:	[email protected]
+P:	Helge Deller
+M:	[email protected]
 P:	Grant Grundler
 M:	[email protected]
 L:	[email protected]

Helge Deller

author maintainer Acked-by

2008-11-22 20:09 UTC #10 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

Quoted 20 lines · Grant Grundler

Quoted 10 lines · Matthew Wilcox
Quoted 6 lines · Grant Grundler
And Helge has been great about fixing stuff - much better than the three listed maintainers lately.
Kyle, willy, any objection to adding Helge to the MAINTAINERS list for PARISC port?
I'd rather allow Helge to make a few small mistakes occasionally rather than watch his parisc specific patches fall on the floor.
No objection from me. I think it's time to remove me from MAINTAINERS as it's probably been six months since I last turned on any of my parisc machines.
Thanks! We have quorum.
Andrew can you please apply this and send to linus?
Or should I start acting like a maintainer and send it myself? :)
Willy, I'm not removing you from Cupertino test ring LDAP or any other privileges unless you ask me to. Just note I appreciate all of your past (and future) help with the port and you are always welcome in Mountain View.

Quoted 5 lines

thanks,
grant
Signed-off-by Grant Grundler <[email protected]>
Reviewed-by Matthew Wilcox <[email protected]>

Acked-by Helge Deller <[email protected]>

Quoted 16 lines

MAINTAINERS +2 -2

index 618c1ef..5b5034c 100644
@@ -3294,8 +3294,8 @@ S:	Maintained
 PARISC ARCHITECTURE
 P:	Kyle McMartin
 M:	[email protected]
-P:	Matthew Wilcox
-M:	[email protected]
+P:	Helge Deller
+M:	[email protected]
 P:	Grant Grundler
 M:	[email protected]
 L:	[email protected]

Grant Grundler

Reviewed-by Matthew Wilcox Acked-by Helge Deller

2008-12-01 07:21 UTC #11 lore raw

Re: [PATCH] 2.6.28-rc6 update parisc MAINTAINERS

In reply to Grant Grundler

Quoted 13 lines · Grant Grundler

Quoted 11 lines · Matthew Wilcox
Quoted 6 lines · Grant Grundler
And Helge has been great about fixing stuff - much better than the three listed maintainers lately.
Kyle, willy, any objection to adding Helge to the MAINTAINERS list for PARISC port?
I'd rather allow Helge to make a few small mistakes occasionally rather than watch his parisc specific patches fall on the floor.
No objection from me. I think it's time to remove me from MAINTAINERS as it's probably been six months since I last turned on any of my parisc machines.

Quoted 7 lines

Thanks! We have quorum.
Andrew can you please apply this and send to linus?
Or should I start acting like a maintainer and send it myself? :)
Willy, I'm not removing you from Cupertino test ring LDAP or any other privileges unless you ask me to. Just note I appreciate all of your past (and future) help with the port and you are always welcome in Mountain View.

Andrew,

Updated version of this patch: I'm removing my own name as well for some of the same reasons as willy. I'll continue to review patches for linux-parisc, maintaining parisc/ia64 systems for gcc/kernel developer access, and testing kernels on parisc occasionally (working on autotest.kernel.org to get that more consistent and easier.)

thanks,
grant

Signed-off-by Grant Grundler <[email protected]>

Reviewed-by Matthew Wilcox <[email protected]>

Acked-by Helge Deller <[email protected]>

MAINTAINERS +2 -4

index 618c1ef..56e519a 100644
@@ -3294,10 +3294,8 @@ S:	Maintained
 PARISC ARCHITECTURE
 P:	Kyle McMartin
 M:	[email protected]
-P:	Matthew Wilcox
-M:	[email protected]
-P:	Grant Grundler
-M:	[email protected]
+P:	Helge Deller
+M:	[email protected]
 L:	[email protected]
 W:	http://www.parisc-linux.org/
 T:	git kernel.org:/pub/scm/linux/kernel/git/kyle/parisc-2.6.git

Helge Deller

author maintainer

2008-12-01 15:59 UTC #12 lore raw

Re: [PATCH] 2.6.28-rc6 update parisc MAINTAINERS

Quoted 16 lines · Grant Grundler

Quoted 15 lines · Grant Grundler
Quoted 10 lines · Matthew Wilcox
Quoted 6 lines · Grant Grundler
And Helge has been great about fixing stuff - much better than the three listed maintainers lately.
Kyle, willy, any objection to adding Helge to the MAINTAINERS list for PARISC port?
I'd rather allow Helge to make a few small mistakes occasionally rather than watch his parisc specific patches fall on the floor.
No objection from me. I think it's time to remove me from MAINTAINERS as it's probably been six months since I last turned on any of my parisc machines.
Thanks! We have quorum.
Andrew can you please apply this and send to linus?
Or should I start acting like a maintainer and send it myself? :)

Quoted 8 lines

Quoted 3 lines
Willy, I'm not removing you from Cupertino test ring LDAP or any other privileges unless you ask me to. Just note I appreciate all of your past (and future) help with the port and you are always welcome in Mountain View.
Andrew,
Updated version of this patch: I'm removing my own name as well for some of the same reasons as willy.

Grant, even if you are currently only occasionally fixing bugs or reviewing patches, I think it would still be valuable to keep you listed here as one of the parisc maintainers.

Helge

Grant Grundler

2008-12-03 08:22 UTC #13 lore raw

Re: [PATCH] 2.6.28-rc6 update parisc MAINTAINERS

Quoted 1 line · Helge Deller

Grant Grundler wrote:

...

Quoted 6 lines

Quoted 2 lines
Updated version of this patch: I'm removing my own name as well for some of the same reasons as willy.
Grant, even if you are currently only occasionally fixing bugs or reviewing patches, I think it would still be valuable to keep you listed here as one of the parisc maintainers.

Helge,
Thanks!

But it sounds a bit biased coming from you given I just nominated you to be listed as maintainer. :)

"occasionally fixing bugs" is generous with respect to parisc-linux. I've prevented a few bugs this year (code review) and substantially helped the Intel IOMMU driver maintainer code (on linux-pci). But those aren't reasons to be listed as parisc-linux maintainer.

I will continue to review parisc-linux patches and occasionally work on "porting" autotest.kernel.org to parisc-linux. I think that would help the port to avoid regressions. I'm just not able (time and ability) to fix the latest major issue which we've been guessing is cache coherency related.

thanks,
grant

Kyle McMartin

2008-11-25 17:20 UTC #14 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

In reply to Grant Grundler

Quoted 2 lines · Grant Grundler

And Helge has been great about fixing stuff - much better than the three listed maintainers lately.

You have an awful lot of nerve saying this, considering.

Grant Grundler

2008-11-26 02:47 UTC #15 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

Quoted 5 lines · Kyle McMartin

Quoted 2 lines · Grant Grundler
And Helge has been great about fixing stuff - much better than the three listed maintainers lately.
You have an awful lot of nerve saying this, considering.

Kyle,
For parisc specific files, I've seen more patches from Helge on linux-parisc than anyone else. That's all I meant. I know I've contributed zero parisc patches in a long time.
I'm not out to offend anyone or pick on you specifically.

I routinely review other people's parisc patches, occasionally try to narrow down the latest b0rkage, and will continue with the care and feeding of the public access machines in Cupertino. The "code review" is the only reason I feel like I should continue as a listed maintainer.

thanks,
grant

Kyle McMartin

2008-11-26 02:59 UTC #16 lore raw

Re: [PATCH] parisc: fix kernel crash when unwinding a userspace process (v2)

Quoted 13 lines · Grant Grundler

Quoted 5 lines · Kyle McMartin
Quoted 2 lines · Grant Grundler
And Helge has been great about fixing stuff - much better than the three listed maintainers lately.
You have an awful lot of nerve saying this, considering.
Kyle,
For parisc specific files, I've seen more patches from Helge on linux-parisc than anyone else. That's all I meant. I know I've contributed zero parisc patches in a long time.
I'm not out to offend anyone or pick on you specifically.

Quoted 5 lines

I routinely review other people's parisc patches, occasionally try to narrow down the latest b0rkage, and will continue with the care and feeding of the public access machines in Cupertino. The "code review" is the only reason I feel like I should continue as a listed maintainer.

Possibly because I don't send my own to the mailing list unless I feel they need review?

Seriously, I *am* offended and I believe I have every right to be.

Kyle McMartin

2008-11-25 17:03 UTC #17 lore raw

In reply to Helge Deller

Quoted 18 lines · Helge Deller

Any user on existing parisc 32- and 64bit-kernels can easily crash the kernel and as such enforce a DSO.
A simple testcase is available here:
http://gsyprf10.external.hp.com/~deller/crash.tgz
The problem is introduced by the fact, that the handle_interruption() crash handler calls the show_regs() function, which in turn tries to unwind the stack by calling parisc_show_stack().
Since the stack contains userspace addresses, a try to unwind the stack is dangerous and useless and leads to the crash.
The fix is trivial: For userspace processes
a) avoid to unwind the stack, and
b) avoid to resolve userspace addresses to kernel symbol names.
While touching this code, I converted print_symbol() to %pS printk formats and made parisc_show_stack() static.

Quoted 8 lines

An initial patch for this was written by Kyle McMartin back in August:
http://marc.info/?l=linux-parisc&m=121805168830283&w=2
Compile and run-tested with a 64bit parisc kernel. Patches for -stable series will follow shortly.
Signed-off-by Helge Deller <[email protected]>

Sorry, I've been sick for the last few days. I see this has already been applied, cool.

Anyway, acked-by me.