Skip to contentSkip to conversation

console_loglevel broken on ia64 (and possibly other archs)

PATCH In review Jesper Juhl 4 participants 5 messages Dec 21, 2001 – Dec 29, 2001 PA-RISC architecture

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 console_loglevel broken on ia64 (and possibly other archs)

This patch fixes the console_loglevel variable(s) so that code that assumes the variables occupy continuous storage does not break (and overwrite other data).

Without this patch this will break on ia64 :

echo 6 4 1 7 > /proc/sys/kernel/printk

with this patch everything works as expected on ia64 and ia32 and as far as I can tell it should have no ill effects on other archs.

The patch has been tested by Keith Owens who agrees that the patch works and fixes the bug. And I've been told that David Mosberger has included this patch in his ia64 add on patch.
So I hope that it could go into 2.4.18-pre when that starts but I'm posting it to the list in case someone else wants to comment on it.

The patch applies cleanly to 2.4.17-final

Best regards,
Jesper Juhl
[email protected]

arch/i386/mm/fault.c +0 -2
diff -ur linux-2.4.17-rc1-orig/arch/i386/mm/fault.c linux-2.4.17-rc1/arch/i386/mm/fault.c
@@ -27,8 +27,6 @@
 
 extern void die(const char *,struct pt_regs *,long);
 
-extern int console_loglevel;
-
 /*
  * Ugly, ugly, but the goto's result in better assembly..
  */
arch/parisc/kernel/traps.c +0 -1
diff -ur linux-2.4.17-rc1-orig/arch/parisc/kernel/traps.c linux-2.4.17-rc1/arch/parisc/kernel/traps.c
@@ -43,7 +43,6 @@
 
 static inline void console_verbose(void)
 {
-	extern int console_loglevel;
 	console_loglevel = 15;
 }
 
include/linux/kernel.h +7 -2
diff -ur linux-2.4.17-rc1-orig/include/linux/kernel.h linux-2.4.17-rc1/include/linux/kernel.h
@@ -36,6 +36,13 @@
 #define	KERN_INFO	"<6>"	/* informational			*/
 #define	KERN_DEBUG	"<7>"	/* debug-level messages			*/
 
+extern int console_printk[];
+
+#define console_loglevel (console_printk[0])
+#define default_message_loglevel (console_printk[1])
+#define minimum_console_loglevel (console_printk[2])
+#define default_console_loglevel (console_printk[3])
+
 # define NORET_TYPE    /**/
 # define ATTRIB_NORET  __attribute__((noreturn))
 # define NORET_AND     noreturn,
@@ -81,8 +88,6 @@
 
 asmlinkage int printk(const char * fmt, ...)
 	__attribute__ ((format (printf, 1, 2)));
-
-extern int console_loglevel;
 
 static inline void console_silent(void)
 {
kernel/printk.c +7 -5
diff -ur linux-2.4.17-rc1-orig/kernel/printk.c linux-2.4.17-rc1/kernel/printk.c
@@ -16,6 +16,7 @@
  *	01Mar01 Andrew Morton <[email protected]>
  */
 
+#include <linux/kernel.h>
 #include <linux/mm.h>
 #include <linux/tty.h>
 #include <linux/tty_driver.h>
@@ -51,11 +52,12 @@
 
 DECLARE_WAIT_QUEUE_HEAD(log_wait);
 
-/* Keep together for sysctl support */
-int console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
-int default_message_loglevel = DEFAULT_MESSAGE_LOGLEVEL;
-int minimum_console_loglevel = MINIMUM_CONSOLE_LOGLEVEL;
-int default_console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;
+int console_printk[4] = {
+	DEFAULT_CONSOLE_LOGLEVEL,	/* console_loglevel */
+	DEFAULT_MESSAGE_LOGLEVEL,	/* default_message_loglevel */
+	MINIMUM_CONSOLE_LOGLEVEL,	/* minimum_console_loglevel */
+	DEFAULT_CONSOLE_LOGLEVEL,	/* default_console_loglevel */
+};
 
 int oops_in_progress;
 
#1 lore raw

Hi!

Quoted 3 lines

This patch fixes the console_loglevel variable(s) so that code that assumes the variables occupy continuous storage does not break (and overwrite other data).

It seems to me you are adding feature? And unneeded one, also.
Pavel

Signature · 2 lines
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
#2 lore raw
Quoted 7 lines · Pavel Machek

Jesper Juhl wrote

Quoted 3 lines

This patch fixes the console_loglevel variable(s) so that code that assumes the variables occupy continuous storage does not break (and overwrite other data).

It seems to me you are adding feature? And unneeded one, also.

No, it is a bug fix. The existing code in kernel/printk.c has

/* Keep together for sysctl support */
int console_loglevel = DEFAULT_CONSOLE_LOGLEVEL; int default_message_loglevel = DEFAULT_MESSAGE_LOGLEVEL; int minimum_console_loglevel = MINIMUM_CONSOLE_LOGLEVEL; int default_console_loglevel = DEFAULT_CONSOLE_LOGLEVEL;

and hopes that gcc will keep those variables together. The sysctl code only addresses console_loglevel and assumes that the other three variables are at the next addresses. There is no requirement for gcc to keep unrelated variables in the order they are defined, on i386 it does, on ia64 it does not. On ia64, doing
echo 1 2 3 4 > /proc/sys/kernel/printk
changes console_loglevel then corrupts three random words, whatever variables gcc put after console_loglevel are destroyed.

#3 lore raw
In reply to Pavel Machek

[email protected] (Pavel Machek) wrote on 24.12.01 in <[email protected]>:

Quoted 5 lines
Quoted 3 lines

This patch fixes the console_loglevel variable(s) so that code that assumes the variables occupy continuous storage does not break (and overwrite other data).

It seems to me you are adding feature? And unneeded one, also.

What feature would that be?

MfG Kai

#4 lore raw
In reply to Pavel Machek
Quoted 6 lines · Pavel Machek
Quoted 3 lines

This patch fixes the console_loglevel variable(s) so that code that assumes the variables occupy continuous storage does not break (and overwrite other data).

It seems to me you are adding feature? And unneeded one, also.
Pavel

if you do

echo 6 4 1 7 > /proc/sys/kernel/printk

then you will overwrite console_loglevel and the next 3 ints. If the next 3 ints are default_message_loglevel, minimum_console_loglevel & default_console_loglevel then all is fine, but if these are not stored in consecutive memory then you will corrupt other data instead - which is a bug. By turning those into an array of ints then you guarantee that the variables will occupy consecutive storage and thus the bug is no more!
That is the purpose of the patch.

Keith Owens has confirmed this to be a problem on IA64 and that the patch fixes the problem. I'm not aware of other architectures having that problem, but with this patch it is impossible for them to have a problem, and it has no ill effects as far as I can tell.

Thank you for your feedback!

Signature · 2 lines
Mvh. / Best regards
Jesper Juhl - [email protected]