linux/drivers, branch v2.6.29.5

crypto: padlock - Revert aes-all alias to aes

2009-06-15T16:40:17Z

commit acd246b7494c629aa617da49716409566cf52149 upstream. Since the padlock-aes driver doesn't require a fallback (it's only padlock-sha that does), it should use the aes alias rather than aes-all so that ones that do need a fallback can use it. Signed-off-by: Herbert Xu Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

cdc-acm: Fix long standing abuse of tty->low_latency

2009-06-15T16:40:16Z

commit 7a9a65ced11ece416b730d6f21040a18e62d78a8 upstream. ACM sets the low latency flag but calls the flip buffer routines from IRQ context which isn't permitted (and as of 2.6.29 causes a warning hence this one was caught) Fortunatelt ACM doesn't need to set this flag in the first place as it only set it to work around problems in ancient (pre tty flip rewrite) kernels. Reported-by: Chuck Ebbert Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ide-tape: remove back-to-back REQUEST_SENSE detection

2009-06-15T16:40:16Z

commit 36999a5af1b6c5379e59f0ddf434db08d03c19e4 upstream. Impact: fix an oops which always triggers ide_tape_issue_pc() assumed drive->pc isn't NULL on invocation when checking for back-to-back request sense issues but drive->pc can be NULL and even when it's not NULL, it's not safe to dereference it once the previous command is complete because pc could have been freed or was on stack. Kill back-to-back REQUEST_SENSE detection. Signed-off-by: Tejun Heo Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman

3w-xxxx: scsi_dma_unmap fix

2009-06-15T16:40:15Z

commit 7b14f58ad65f9d74e4273fb45360cfea824495aa upstream. This patch fixes the following regression that occurred during the scsi_dma_map()/unmap() changes when compiling with CONFIG_DMA_API_DEBUG=y : WARNING: at lib/dma-debug.c:496 check_unmap+0x142/0x542() Hardware name: 3w-xxxx 0000:02:02.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=36 bytes] Signed-off-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

HID: fix dropped device-specific quirks

2009-06-15T16:40:14Z

commit f5208997087e6eb2096532b5a313eeb236535bdc upstream. Device-specific quirks are set up correctly in their respective vendor-specific driver, then get overwritten in usbhid_parse(). This is only issue for device-specific NOGET quirks being set by driver for a few devices out there. Signed-off-by: Zoltan Karcagi Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

Avoid ICE in get_random_int() with gcc-3.4.5

2009-06-15T16:40:14Z

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-15T16:40:13Z

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

bnx2: Fix panic in bnx2_poll_work().

2009-06-15T16:40:13Z

commit 581daf7e00c5e766f26aff80a61a860a17b0d75a upstream. Add barrier() to bnx2_get_hw_{tx|rx}_cons() to fix this issue: http://bugzilla.kernel.org/show_bug.cgi?id=12698 This issue was reported by multiple i386 users. Without barrier(), the compiled code looks like the following where %eax contains the address of the tx_cons or rx_cons in the DMA status block. The status block contents can change between the cmpb and the movzwl instruction. The driver would crash if the value was not 0xff during the cmpb instruction, but changed to 0xff during the movzwl instruction. 6828: 80 38 ff cmpb $0xff,(%eax) 682b: 0f b7 10 movzwl (%eax),%edx With the added barrier(), the compiled code now looks correct: 683d: 0f b7 10 movzwl (%eax),%edx 6840: 0f b6 c2 movzbl %dl,%eax 6843: 3d ff 00 00 00 cmp $0xff,%eax Thanks to Pascal de Bruijn for reporting the problem and Holger Noefer for patiently testing test patches for us. [greg - took out version change] Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

iwlwifi: update key flags at time key is set

2009-06-15T16:40:11Z

commit 299f5462087f3bc2141e6bc83ba7e2b15d8a07d2 upstream. We need to be symmetrical in what is done when key is set and cleared. This is important wrt the key flags as they are used during key clearing and if they are not set when the key is set the key cannot be cleared completely. This addresses the many occurences of the WARN found in iwl_set_tkip_dynamic_key_info() and tracked in http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key If calling iwl_set_tkip_dynamic_key_info()/iwl_remove_dynamic_key() pair a few times in a row will cause that we run out of key space. This is because the index stored in the key flags is used by iwl_remove_dynamic_key() to decide if it should remove the key. Unfortunately the key flags, and hence the key index is currently only set at the time the key is written to the device (in iwl_update_tkip_key()) and _not_ in iwl_set_tkip_dynamic_key_info(). Fix this by setting flags in iwl_set_tkip_dynamic_key_info(). Signed-off-by: Reinette Chatre Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

igb: fix LRO warning

2009-06-15T16:40:11Z

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