linux/drivers, branch v2.6.32.27

x86: uv: xpc NULL deref when mesq becomes empty

2010-12-09T21:27:15Z

commit 15b87d67ff3dc042bee42f991858d6b121b3b3ca upstream. Under heavy load conditions, our set of xpc messages may become exhausted. The code handles this correctly with the exception of the management code which hits a NULL pointer dereference. Signed-off-by: Robin Holt Cc: Jack Steiner Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

X86: uv: xpc_make_first_contact hang due to not accepting ACTIVE state

2010-12-09T21:27:15Z

commit dbd2918ec65c35f36bb102c88eafe87be0552f6f upstream. Many times while the initial connection is being made, the contacted partition will send back both the ACTIVATING and the ACTIVE remote_act_state changes in very close succescion. The 1/4 second delay in the make first contact loop is large enough to nearly always miss the ACTIVATING state change. Since either state indicates the remote partition has acknowledged our state change, accept either. Signed-off-by: Robin Holt Cc: Jack Steiner Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86: uv: XPC receive message reuse triggers invalid BUG_ON()

2010-12-09T21:27:14Z

commit 046d6c563b1c6226bbf0f84e5b2413ad8ab921a1 upstream. This was a difficult bug to trip. XPC was in the middle of sending an acknowledgement for a received message. In xpc_received_payload_uv(): . ret = xpc_send_gru_msg(ch->sn.uv.cached_notify_gru_mq_desc, msg, sizeof(struct xpc_notify_mq_msghdr_uv)); if (ret != xpSuccess) XPC_DEACTIVATE_PARTITION(&xpc_partitions[ch->partid], ret); msg->hdr.msg_slot_number += ch->remote_nentries; at the point in xpc_send_gru_msg() where the hardware has dispatched the acknowledgement, the remote side is able to reuse the message structure and send a message with a different slot number. This problem is made worse by interrupts. The adjustment of msg_slot_number and the BUG_ON in xpc_handle_notify_mq_msg_uv() which verifies the msg_slot_number is consistent are only used for debug purposes. Since a fix for this that preserves the debug functionality would either have to infringe upon the payload or allocate another structure just for debug, I decided to remove it entirely. Signed-off-by: Robin Holt Cc: Jack Steiner Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

UV - XPC: pass nasid instead of nid to gru_create_message_queue

2010-12-09T21:27:14Z

commit 57e6d258b1e41cd7ceb26fa43ce116939d8440b1 upstream. Currently, the UV xpc code is passing nid to the gru_create_message_queue instead of nasid as it expects. Signed-off-by: Robin Holt Signed-off-by: Jack Steiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

crypto: padlock - Fix AES-CBC handling on odd-block-sized input

2010-12-09T21:27:10Z

commit c054a076a1bd4731820a9c4d638b13d5c9bf5935 upstream. On certain VIA chipsets AES-CBC requires the input/output to be a multiple of 64 bytes. We had a workaround for this but it was buggy as it sent the whole input for processing when it is meant to only send the initial number of blocks which makes the rest a multiple of 64 bytes. As expected this causes memory corruption whenever the workaround kicks in. Reported-by: Phil Sutter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

V4L/DVB: ivtvfb: prevent reading uninitialized stack memory

2010-12-09T21:27:10Z

commit 405707985594169cfd0b1d97d29fcb4b4c6f2ac9 upstream. The FBIOGET_VBLANK device ioctl allows unprivileged users to read 16 bytes of uninitialized stack memory, because the "reserved" member of the fb_vblank struct declared on the stack is not altered or zeroed before being copied back to the user. This patch takes care of it. Signed-off-by: Dan Rosenberg Signed-off-by: Andy Walls Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

Input: i8042 - add Sony VAIO VPCZ122GX to nomux list

2010-12-09T21:27:08Z

[Note that the mainline will not have this particular fix but rather will blacklist entire VAIO line based off DMI board name. For stable I am being a bit more cautious and blacklist one particular product.] Trying to query/activate active multiplexing mode on this VAIO makes both keyboard and touchpad inoperable. Futher kernels will blacklist entire VAIO line, however here we blacklist just one particular model. Reported-by: Jesse Barnes Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

V4L/DVB (13154): uvcvideo: Handle garbage at the end of streaming interface descriptors

2010-12-09T21:27:08Z

commit c4ed8c66d79d707d89fe732ff5b97739edf1ba62 upstream. At least one 5986:0241 webcam model includes vendor-specific descriptors at the end of its streaming interface descriptors. Print an information UVC_TRACE_DESCR message and try to continue parsing the descriptors rather than bailing out with an error. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

efifb: support the EFI framebuffer on more Apple hardware

2010-12-09T21:27:08Z

commit a5757c2a474a15f87e5baa9a4caacc31cde2bae6 upstream. Enable the EFI framebuffer on 14 more Macs, including the iMac11,1 iMac10,1 iMac8,1 Macmini3,1 Macmini4,1 MacBook5,1 MacBook6,1 MacBook7,1 MacBookPro2,2 MacBookPro5,2 MacBookPro5,3 MacBookPro6,1 MacBookPro6,2 and MacBookPro7,1 Information gathered from various user submissions. https://bugzilla.redhat.com/show_bug.cgi?id=528232 http://ubuntuforums.org/showthread.php?t=1557326 [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Luke Macken Signed-off-by: Peter Jones Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

drivers/video/efifb.c: support framebuffer for NVIDIA 9400M in MacBook Pro 5,1

2010-12-09T21:27:08Z

commit 8a3bdfe6cd841880a5d849c40f90093b3817f6e0 upstream. Description of patch: --------------------- This is a patch for the EFI framebuffer driver to enable the framebuffer of the NVIDIA 9400M as found in MacBook Pro (MBP) 5,1 and up. The framebuffer of the NVIDIA graphic cards are located at the following addresses in memory: 9400M: 0xC0010000 9600M GT: 0xB0030000 The patch delivered right here only provides the memory location of the framebuffer of the 9400M device. The 9600M GT is not covered. It is assumed that the 9400M is used when powered up the MBP. The information which device is currently powered and in use is stored in the 64 bytes large EFI variable "gpu-power-prefs". More specifically, byte 0x3B indicates whether 9600M GT (0x00) or 9400M (0x01) is online. The PCI bus IDs are the following: 9400M: PCI 03:00:00 9600M GT: PCI 02:00:00 The EFI variables can be easily read-out and manipulated with "rEFIt", an MBP specific bootloader tool. For more information on how handle rEFIt and EFI variables please consult "http://refit.sourceforge.net" and "http://ubuntuforums.org/archive/index.php/t-1076879.html". IMPORTANT NOTE: The information on how to activate the 9400M device given at "ubuntuforums.org" is not correct, since it states gpu-power-prefs[0x3B] = 0x00 -> 9400M (PCI 02:00:00) gpu-power-prefs[0x3B] = 0x01 -> 9600M GT (PCI 03:00:00) Actually, the assignment of the values and the PCI bus IDs are swapped. Suggestions: ------------ To cover framebuffers of both 9400M and 9600M GT, I would suggest to implement a conditional on "gpu-power-prefs". Depending on the value of byte 0x3B, the according framebuffer is selected. However, this requires kernel access to the EFI variables. [akpm@linux-foundation.org: rename optname, per Peter Jones] Signed-off-by: Thomas Gerlach Acked-by: Peter Jones Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman