From 364b5b7b1d793a7f98be55b6b154716dcae78dfc Mon Sep 17 00:00:00 2001 From: Jason Wessel Date: Wed, 13 May 2009 21:56:59 -0500 Subject: sysrq, intel_fb: fix sysrq g collision Commit 79e539453b34e35f39299a899d263b0a1f1670bd introduced a regression where you cannot use sysrq 'g' to enter kgdb. The solution is to move the intel fb sysrq over to V for video instead of G for graphics. The SMP VOYAGER code to register for the sysrq-v is not anywhere to be found in the mainline kernel, so the comments in the code were cleaned up as well. This patch also cleans up the sysrq definitions for kgdb to make it generic for the kernel debugger, such that the sysrq 'g' can be used in the future to enter a gdbstub or another kernel debugger. Signed-off-by: Jason Wessel Acked-by: Jesse Barnes Acked-by: Randy Dunlap Signed-off-by: Andrew Morton --- drivers/char/sysrq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers/char') diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c index b0a6a3e51924..d6a807f4077d 100644 --- a/drivers/char/sysrq.c +++ b/drivers/char/sysrq.c @@ -406,7 +406,7 @@ static struct sysrq_key_op *sysrq_key_table[36] = { &sysrq_showlocks_op, /* d */ &sysrq_term_op, /* e */ &sysrq_moom_op, /* f */ - /* g: May be registered by ppc for kgdb */ + /* g: May be registered for the kernel debugger */ NULL, /* g */ NULL, /* h - reserved for help */ &sysrq_kill_op, /* i */ @@ -431,7 +431,7 @@ static struct sysrq_key_op *sysrq_key_table[36] = { &sysrq_sync_op, /* s */ &sysrq_showstate_op, /* t */ &sysrq_mountro_op, /* u */ - /* v: May be registered at init time by SMP VOYAGER */ + /* v: May be registered for frame buffer console restore */ NULL, /* v */ &sysrq_showstate_blocked_op, /* w */ /* x: May be registered on ppc/powerpc for xmon */ -- cgit v1.2.3 From 26a9a418237c0b06528941bca693c49c8d97edbe Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Tue, 19 May 2009 11:25:35 -0700 Subject: Avoid ICE in get_random_int() with gcc-3.4.5 Martin Knoblauch reports that trying to build 2.6.30-rc6-git3 with RHEL4.3 userspace (gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)) causes an internal compiler error (ICE): drivers/char/random.c: In function `get_random_int': drivers/char/random.c:1672: error: unrecognizable insn: (insn 202 148 150 0 /scratch/build/linux-2.6.30-rc6-git3/arch/x86/include/asm/tsc.h:23 (set (reg:SI 0 ax [91]) (subreg:SI (plus:DI (plus:DI (reg:DI 0 ax [88]) (subreg:DI (reg:SI 6 bp) 0)) (const_int -4 [0xfffffffffffffffc])) 0)) -1 (nil) (nil)) drivers/char/random.c:1672: internal compiler error: in extract_insn, at recog.c:2083 and after some debugging it turns out that it's due to the code trying to figure out the rough value of the current stack pointer by taking an address of an uninitialized variable and casting that to an integer. This is clearly a compiler bug, but it's not worth fighting - while the current stack kernel pointer might be somewhat hard to predict in user space, it's also not generally going to change for a lot of the call chains for a particular process. So just drop it, and mumble some incoherent curses at the compiler. Tested-by: Martin Knoblauch Cc: Matt Mackall Cc: Ingo Molnar Signed-off-by: Linus Torvalds --- drivers/char/random.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/char') diff --git a/drivers/char/random.c b/drivers/char/random.c index b2ced39d76b2..8c7444857a4b 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1673,7 +1673,7 @@ unsigned int get_random_int(void) int ret; keyptr = get_keyptr(); - hash[0] += current->pid + jiffies + get_cycles() + (int)(long)&ret; + hash[0] += current->pid + jiffies + get_cycles(); ret = half_md4_transform(hash, keyptr->secret); put_cpu_var(get_random_int_hash); -- cgit v1.2.3 From fbaa58696cef848de818768783ef185bd3f05158 Mon Sep 17 00:00:00 2001 From: Eric Paris Date: Wed, 13 May 2009 12:50:40 -0400 Subject: TPM: get_event_name stack corruption get_event_name uses sprintf to fill a buffer declared on the stack. It fills the buffer 2 bytes at a time. What the code doesn't take into account is that sprintf(buf, "%02x", data) actually writes 3 bytes. 2 bytes for the data and then it nul terminates the string. Since we declare buf to be 40 characters long and then we write 40 bytes of data into buf sprintf is going to write 41 characters. The fix is to leave room in buf for the nul terminator. Signed-off-by: Eric Paris Signed-off-by: James Morris --- drivers/char/tpm/tpm_bios.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'drivers/char') diff --git a/drivers/char/tpm/tpm_bios.c b/drivers/char/tpm/tpm_bios.c index ed306eb1057f..0c2f55a38b95 100644 --- a/drivers/char/tpm/tpm_bios.c +++ b/drivers/char/tpm/tpm_bios.c @@ -212,7 +212,8 @@ static int get_event_name(char *dest, struct tcpa_event *event, unsigned char * event_entry) { const char *name = ""; - char data[40] = ""; + /* 41 so there is room for 40 data and 1 nul */ + char data[41] = ""; int i, n_len = 0, d_len = 0; struct tcpa_pc_event *pc_event; -- cgit v1.2.3 From 9a2845c453d170e4e9b1437fa671dbf39b0e7bd8 Mon Sep 17 00:00:00 2001 From: Corey Minyard Date: Wed, 20 May 2009 13:36:17 -0500 Subject: ipmi: fix ipmi_si modprobe hang Instead of queuing IPMB messages before channel initialization, just throw them away. Nobody will be listening for them at this point, anyway, and they will clog up the queue and nothing will be delivered if we queue them. Also set the current channel to the number of channels, as this value is used to tell if the channel information has been initialized. Signed-off-by: Corey Minyard Cc: Ferenc Wagner Cc: Dan Frazier Signed-off-by: Linus Torvalds --- drivers/char/ipmi/ipmi_msghandler.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) (limited to 'drivers/char') diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index aa83a0865ec1..09050797c76a 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -2856,6 +2856,7 @@ int ipmi_register_smi(struct ipmi_smi_handlers *handlers, /* Assume a single IPMB channel at zero. */ intf->channels[0].medium = IPMI_CHANNEL_MEDIUM_IPMB; intf->channels[0].protocol = IPMI_CHANNEL_PROTOCOL_IPMB; + intf->curr_channel = IPMI_MAX_CHANNELS; } if (rv == 0) @@ -3648,13 +3649,13 @@ static int handle_new_recv_msg(ipmi_smi_t intf, } /* - ** We need to make sure the channels have been initialized. - ** The channel_handler routine will set the "curr_channel" - ** equal to or greater than IPMI_MAX_CHANNELS when all the - ** channels for this interface have been initialized. - */ + * We need to make sure the channels have been initialized. + * The channel_handler routine will set the "curr_channel" + * equal to or greater than IPMI_MAX_CHANNELS when all the + * channels for this interface have been initialized. + */ if (intf->curr_channel < IPMI_MAX_CHANNELS) { - requeue = 1; /* Just put the message back for now */ + requeue = 0; /* Throw the message away */ goto out; } -- cgit v1.2.3 From 730c586ad5228c339949b2eb4e72b80ae167abc4 Mon Sep 17 00:00:00 2001 From: Salman Qazi Date: Thu, 4 Jun 2009 15:20:39 -0700 Subject: drivers/char/mem.c: avoid OOM lockup during large reads from /dev/zero While running 20 parallel instances of dd as follows: #!/bin/bash for i in `seq 1 20`; do dd if=/dev/zero of=/export/hda3/dd_$i bs=1073741824 count=1 & done wait on a 16G machine, we noticed that rather than just killing the processes, the entire kernel went down. Stracing dd reveals that it first does an mmap2, which makes 1GB worth of zero page mappings. Then it performs a read on those pages from /dev/zero, and finally it performs a write. The machine died during the reads. Looking at the code, it was noticed that /dev/zero's read operation had been changed by 557ed1fa2620dc119adb86b34c614e152a629a80 ("remove ZERO_PAGE") from giving zero page mappings to actually zeroing the page. The zeroing of the pages causes physical pages to be allocated to the process. But, when the process exhausts all the memory that it can, the kernel cannot kill it, as it is still in the kernel mode allocating more memory. Consequently, the kernel eventually crashes. To fix this, I propose that when a fatal signal is pending during /dev/zero read operation, we simply return and let the user process die. Signed-off-by: Salman Qazi Cc: Nick Piggin Signed-off-by: Andrew Morton [ Modified error return and comment trivially. - Linus] Signed-off-by: Linus Torvalds --- drivers/char/mem.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'drivers/char') diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 8f05c38c2f06..65e12bca657c 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -694,6 +694,9 @@ static ssize_t read_zero(struct file * file, char __user * buf, written += chunk - unwritten; if (unwritten) break; + /* Consider changing this to just 'signal_pending()' with lots of testing */ + if (fatal_signal_pending(current)) + return written ? written : -EINTR; buf += chunk; count -= chunk; cond_resched(); -- cgit v1.2.3 From 96050dfb25966612008dcea7d342e91fa01e993c Mon Sep 17 00:00:00 2001 From: Peter Botha Date: Tue, 9 Jun 2009 17:16:32 -0700 Subject: char: mxser, fix ISA board lookup There's a bug in the mxser kernel module that still appears in the 2.6.29.4 kernel. mxser_get_ISA_conf takes a ioaddress as its first argument, by passing the not of the ioaddr, you're effectively passing 0 which means it won't be able to talk to an ISA card. I have tested this, and removing the ! fixes the problem. Cc: "Peter Botha" Signed-off-by: Jiri Slaby Acked-by: Alan Cox Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- drivers/char/mxser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/char') diff --git a/drivers/char/mxser.c b/drivers/char/mxser.c index a420e8d437dd..13f8871e5b21 100644 --- a/drivers/char/mxser.c +++ b/drivers/char/mxser.c @@ -2711,7 +2711,7 @@ static int __init mxser_module_init(void) continue; brd = &mxser_boards[m]; - retval = mxser_get_ISA_conf(!ioaddr[b], brd); + retval = mxser_get_ISA_conf(ioaddr[b], brd); if (retval <= 0) { brd->info = NULL; continue; -- cgit v1.2.3