linux-toradex.git/drivers, branch v2.6.27.25

V4L/DVB (10943): cx88: Prevent general protection fault on rmmod

2009-06-12T03:01:34+00:00

commit 569b7ec73abf576f9a9e4070d213aadf2cce73cb upstream.

V4L/DVB (10943): cx88: Prevent general protection fault on rmmod

When unloading the cx8800 driver I sometimes get a general protection
fault. Analysis revealed a race in cx88_ir_stop(). It can be solved by
using a delayed work instead of a timer for infrared input polling.

Signed-off-by: Jean Delvare 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

USB: isp1760: urb_dequeue doesn't always find the urbs

2009-06-12T03:01:30+00:00

commit 0afb20e00b5053170c85298fed842b32d20b4ea9 upstream.

The option driver (and presumably others) allocates several URBs when it
opens and tries to free them when it closes. The isp1760_urb_dequeue
function gets called, but the packet being dequeued is not necessarily at
the
front of one of the 32 queues. If not, the isp1760_urb_done function doesn't
get called for the URB and the process trying to free it hangs forever on a
wait_queue. This patch does two things. If the URB being dequeued has others
queued behind it, it re-queues them. And it searches the queues looking for
the URB being dequeued rather than just looking at the one at the front of
the queue.

[bigeasy@linutronix] whitespace fixes, reformating

Signed-off-by: Warren Free 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

Avoid ICE in get_random_int() with gcc-3.4.5

2009-06-12T03:01:27+00:00

commit 26a9a418237c0b06528941bca693c49c8d97edbe upstream.

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 
Signed-off-by: Greg Kroah-Hartman

random: make get_random_int() more random

2009-06-12T03:01:27+00:00

commit 8a0a9bd4db63bc45e3017bedeafbd88d0eb84d02 upstream.

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 
Cc: Jake Edge 
Signed-off-by: Greg Kroah-Hartman

igb: fix LRO warning

2009-06-12T03:01:26+00:00

This fix is only needed for 2.6.29.y tree, since in 2.6.30 and later IGB
has moved to using GRO instead of LRO.

igb supports LRO, but was not setting any hooks to the ->set_flags
ethtool_ops function.  This would trigger warnings if the user tried
to enable or disable LRO.

Based on the patch provided by Stephen Hemminger 

Reported-by: Sergey Kononenko 
Signed-off-by: Jeff Kirsher 
CC: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

hwmon: (lm78) Add missing __devexit_p()

2009-06-12T03:01:25+00:00

commit 39d8bbedb9571a89d638f5b05358f26ab503d7a6 upstream.

The remove function uses __devexit, so the .remove assignment needs
__devexit_p() to fix a build error with hotplug disabled.

Signed-off-by: Mike Frysinger 
Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

e1000: add missing length check to e1000 receive routine

2009-06-12T03:01:25+00:00

commit ea30e11970a96cfe5e32c03a29332554573b4a10 upstream.

	Patch to fix bad length checking in e1000.  E1000 by default does two
things:

1) Spans rx descriptors for packets that don't fit into 1 skb on recieve
2) Strips the crc from a frame by subtracting 4 bytes from the length prior to
doing an skb_put

Since the e1000 driver isn't written to support receiving packets that span
multiple rx buffers, it checks the End of Packet bit of every frame, and
discards it if its not set.  This places us in a situation where, if we have a
spanning packet, the first part is discarded, but the second part is not (since
it is the end of packet, and it passes the EOP bit test).  If the second part of
the frame is small (4 bytes or less), we subtract 4 from it to remove its crc,
underflow the length, and wind up in skb_over_panic, when we try to skb_put a
huge number of bytes into the skb.  This amounts to a remote DOS attack through
careful selection of frame size in relation to interface MTU.  The fix for this
is already in the e1000e driver, as well as the e1000 sourceforge driver, but no
one ever pushed it to e1000.  This is lifted straight from e1000e, and prevents
small frames from causing the underflow described above

Signed-off-by: Neil Horman 
Tested-by: Andy Gospodarek 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drivers/serial/mpc52xx_uart.c: fix array overindexing check

2009-06-12T03:01:24+00:00

commit b898f4f869da5b9d41f297fff87aca4cd42d80b3 upstream.

The check for an overindexing of mpc52xx_uart_{ports,nodes} has an
off-by-one.

Signed-off-by: Roel Kluin 
Acked-by: Wolfram Sang 
Acked-by: Grant Likely 
Cc: Benjamin Herrenschmidt 
Cc: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

cpuidle: make AMC C1E work in processor_idle

2009-06-12T03:01:21+00:00

commit 87ad57bacb25c3f24c54f142ef445f68277705f0 upstream

When AMD C1E is enabled, local APIC timer will stop even in C1. This patch uses
broadcast ipi to replace local APIC timer in C1.

http://bugzilla.kernel.org/show_bug.cgi?id=13233

[ impact: avoid boot hang in AMD CPU with C1E enabled ]

Tested-by: Dmitry Lyzhyn 
Signed-off-by: Shaohua Li 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

cpuidle: fix AMD C1E suspend hang

2009-06-12T03:01:21+00:00

commit 7d60e8ab0d5507229dfbdf456501cc378610fa01 upstream.

When AMD C1E is enabled, local APIC timer will stop even in C1. To avoid
suspend/resume hang, this patch removes C1 and replace it with a cpu_relax() in
suspend/resume path. This hasn't any impact in runtime path.

http://bugzilla.kernel.org/show_bug.cgi?id=13233

[ impact: avoid suspend/resume hang in AMD CPU with C1E enabled ]

Tested-by: Dmitry Lyzhyn 
Signed-off-by: Shaohua Li 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman