linux/drivers/char, branch v2.6.30

char: mxser, fix ISA board lookup

2009-06-10T01:09:03Z

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/mem.c: avoid OOM lockup during large reads from /dev/zero

2009-06-04T22:20:39Z

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

ipmi: fix ipmi_si modprobe hang

2009-05-22T14:30:41Z

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

TPM: get_event_name stack corruption

2009-05-19T22:30:05Z

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

Avoid ICE in get_random_int() with gcc-3.4.5

2009-05-19T18:25:35Z

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

sysrq, intel_fb: fix sysrq g collision

2009-05-15T12:56:24Z

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

random: make get_random_int() more random

2009-05-07T18:59:06Z

It's a really simple patch that basically just open-codes the current "secure_ip_id()" call, but when open-coding it we now use a _static_ hashing area, so that it gets updated every time. And to make sure somebody can't just start from the same original seed of all-zeroes, and then do the "half_md4_transform()" over and over until they get the same sequence as the kernel has, each iteration also mixes in the same old "current->pid + jiffies" we used - so we should now have a regular strong pseudo-number generator, but we also have one that doesn't have a single seed. Note: the "pid + jiffies" is just meant to be a tiny tiny bit of noise. It has no real meaning. It could be anything. I just picked the previous seed, it's just that now we keep the state in between calls and that will feed into the next result, and that should make all the difference. I made that hash be a per-cpu data just to avoid cache-line ping-pong: having multiple CPU's write to the same data would be fine for randomness, and add yet another layer of chaos to it, but since get_random_int() is supposed to be a fast interface I did it that way instead. I considered using "__raw_get_cpu_var()" to avoid any preemption overhead while still getting the hash be _mostly_ ping-pong free, but in the end good taste won out. Signed-off-by: Ingo Molnar Signed-off-by: Linus Torvalds

vt: Add a note on the historical abuse of CLOCK_TICK_RATE

2009-05-06T21:47:13Z

This is one area where we can't just magic away the bizarre use of CLOCK_TICK_RATE as it leaks to user space APIs. It also means the visible CLOCK_TICK_RATE is frozen for architectures which is horrible. We need to fix this somehow Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds

virtio-rng: Remove false BUG for spurious callbacks

2009-04-24T20:28:30Z

The virtio-rng drivers checks for spurious callbacks. Since callbacks can be implemented via shared interrupts (e.g. PCI) this could lead to guest kernel oopses with lots of virtio devices. Signed-off-by: Christian Borntraeger Cc: Rusty Russell Cc: stable@kernel.org Signed-off-by: Linus Torvalds

ipmi: add oem message handling

2009-04-21T20:41:48Z

Enable userspace to receive messages that a BMC transmits using an OEM medium. This is used by the HP iLO2. Based on code originally written by Patrick Schoeller. Signed-off-by: dann frazier Signed-off-by: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds