linux/drivers/misc, branch v2.6.32.32

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

sgi-xpc: XPC fails to discover partitions with all nasids above 128

2010-12-09T21:26:42Z

commit c22c7aeff69796f46ae0fcec141538e28f50b24e upstream. UV hardware defines 256 memory protection regions versus the baseline 64 with increasing size for the SN2 ia64. This was overlooked when XPC was modified to accomodate both UV and SN2. Without this patch, a user could reconfigure their existing system and suddenly disable cross-partition communications with no indication of what has gone wrong. It also prevents larger configurations from using cross-partition communication. Signed-off-by: Robin Holt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

sgi-xp: incoming XPC channel messages can come in after the channel's partition structures have been torn down

2010-11-22T18:47:38Z

commit 09358972bff5ce99de496bbba97c85d417b3c054 upstream. Under some workloads, some channel messages have been observed being delayed on the sending side past the point where the receiving side has been able to tear down its partition structures. This condition is already detected in xpc_handle_activate_IRQ_uv(), but that information is not given to xpc_handle_activate_mq_msg_uv(). As a result, xpc_handle_activate_mq_msg_uv() assumes the structures still exist and references them, causing a NULL-pointer deref. Signed-off-by: Robin Holt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

SCSI: enclosure: fix error path - actually return ERR_PTR() on error

2010-08-10T17:20:44Z

commit a91c1be21704113b023919826c6d531da46656ef upstream. we also need to clean up and free the cdev. Reported-by: Jani Nikula Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

SCSI: enclosure: fix oops while iterating enclosure_status array

2010-01-25T18:49:37Z

commit cc9b2e9f6603190c009e5d2629ce8e3f99571346 upstream. Based on patch originally by Jeff Mahoney enclosure_status is expected to be a NULL terminated array of strings but isn't actually NULL terminated. When writing an invalid value to /sys/class/enclosure/.../.../status, it goes off the end of the array and Oopses. Fix by making the assumption true and adding NULL at the end. Reported-by: Artur Wojcik Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

at24: Use timeout also for read

2009-11-26T08:22:33Z

Writes may take some time on EEPROMs, so for consecutive writes, we already have a loop waiting for the EEPROM to become ready. Use such a loop for reads, too, in case somebody wants to immediately read after a write. Detailed bug report and test case can be found here: http://article.gmane.org/gmane.linux.drivers.i2c/4660 Reported-by: Aleksandar Ivanov Signed-off-by: Wolfram Sang Tested-by: Aleksandar Ivanov Cc: David Brownell Signed-off-by: Jean Delvare

sgi-gru: decrapfiy options_write() function

2009-11-05T18:48:30Z

Not a single line of actual code in the function was really fundamentally correct. Problems ranged from lack of proper range checking, to removing the last character written (which admittedly is usually '\n'), to not accepting hex numbers even though the 'show' routine would show the data in that format. This tries to do better. Acked-by: Michael Buesch Tested-and-acked-by: Jack Steiner Cc: stable@kernel.org Cc: Jiri Kosina Cc: Michael Gilbert Signed-off-by: Linus Torvalds