commit b55f3d92cd8f544f8f0c31f20f0a745d2c138dfc Author: Greg Kroah-Hartman Date: Mon Nov 22 10:48:20 2010 -0800 Linux 2.6.32.26 commit 73d4907e4d42bb42307807d4929be76e6b4a92a0 Author: Robin Holt Date: Tue Oct 26 14:21:15 2010 -0700 sgi-xp: incoming XPC channel messages can come in after the channel's partition structures have been torn down 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 commit c4244895dd30ddfd20086308786e108d3c52161c Author: Mike Christie Date: Wed Oct 6 03:10:59 2010 -0500 Fix regressions in scsi_internal_device_block commit 986fe6c7f50974e871b8ab5a800f5310ea25b361 upstream. Deleting a SCSI device on a blocked fc_remote_port (before fast_io_fail_tmo fires) results in a hanging thread: STACK: 0 schedule+1108 [0x5cac48] 1 schedule_timeout+528 [0x5cb7fc] 2 wait_for_common+266 [0x5ca6be] 3 blk_execute_rq+160 [0x354054] 4 scsi_execute+324 [0x3b7ef4] 5 scsi_execute_req+162 [0x3b80ca] 6 sd_sync_cache+138 [0x3cf662] 7 sd_shutdown+138 [0x3cf91a] 8 sd_remove+112 [0x3cfe4c] 9 __device_release_driver+124 [0x3a08b8] 10 device_release_driver+60 [0x3a0a5c] 11 bus_remove_device+266 [0x39fa76] 12 device_del+340 [0x39d818] 13 __scsi_remove_device+204 [0x3bcc48] 14 scsi_remove_device+66 [0x3bcc8e] 15 sysfs_schedule_callback_work+50 [0x260d66] 16 worker_thread+622 [0x162326] 17 kthread+160 [0x1680b0] 18 kernel_thread_starter+6 [0x10aaea] During the delete, the SCSI device is in moved to SDEV_CANCEL. When the FC transport class later calls scsi_target_unblock, this has no effect, since scsi_internal_device_unblock ignores SCSI devics in this state. It looks like all these are regressions caused by: 5c10e63c943b4c67561ddc6bf61e01d4141f881f [SCSI] limit state transitions in scsi_internal_device_unblock Fix by rejecting offline and cancel in the state transition. Signed-off-by: Christof Schmitt [jejb: Original patch by Christof Schmitt, modified by Mike Christie] Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit d8482738adb76205916cebf828c40d9740d8382b Author: Christof Schmitt Date: Wed Oct 6 13:19:44 2010 +0200 Fix race when removing SCSI devices commit 546ae796bfac6399e30da4b5af2cf7a6d0f8a4ec upstream. Removing SCSI devices through echo 1 > /sys/bus/scsi/devices/ ... /delete while the FC transport class removes the SCSI target can lead to an oops: Unable to handle kernel pointer dereference at virtual kernel address 00000000b6815000 Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: sunrpc qeth_l3 binfmt_misc dm_multipath scsi_dh dm_mod ipv6 qeth ccwgroup [last unloaded: scsi_wait_scan] CPU: 1 Not tainted 2.6.35.5-45.x.20100924-s390xdefault #1 Process fc_wq_0 (pid: 861, task: 00000000b7331240, ksp: 00000000b735bac0) Krnl PSW : 0704200180000000 00000000003ff6e4 (__scsi_remove_device+0x24/0xd0) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 Krnl GPRS: 0000000000000001 0000000000000000 00000000b6815000 00000000bc24a8c0 00000000003ff7c8 000000000056dbb8 0000000000000002 0000000000835d80 ffffffff00000000 0000000000001000 00000000b6815000 00000000bc24a7f0 00000000b68151a0 00000000b6815000 00000000b735bc20 00000000b735bbf8 Krnl Code: 00000000003ff6d6: a7840001 brc 8,3ff6d8 00000000003ff6da: a7fbffd8 aghi %r15,-40 00000000003ff6de: e3e0f0980024 stg %r14,152(%r15) >00000000003ff6e4: e31021200004 lg %r1,288(%r2) 00000000003ff6ea: a71f0000 cghi %r1,0 00000000003ff6ee: a7a40011 brc 10,3ff710 00000000003ff6f2: a7390003 lghi %r3,3 00000000003ff6f6: c0e5ffffc8b1 brasl %r14,3f8858 Call Trace: ([<0000000000001000>] 0x1000) [<00000000003ff7d2>] scsi_remove_device+0x42/0x54 [<00000000003ff8ba>] __scsi_remove_target+0xca/0xfc [<00000000003ff99a>] __remove_child+0x3a/0x48 [<00000000003e3246>] device_for_each_child+0x72/0xbc [<00000000003ff93a>] scsi_remove_target+0x4e/0x74 [<0000000000406586>] fc_rport_final_delete+0xb2/0x23c [<000000000015d080>] worker_thread+0x200/0x344 [<000000000016330c>] kthread+0xa0/0xa8 [<0000000000106c1a>] kernel_thread_starter+0x6/0xc [<0000000000106c14>] kernel_thread_starter+0x0/0xc INFO: lockdep is turned off. Last Breaking-Event-Address: [<00000000003ff7cc>] scsi_remove_device+0x3c/0x54 The function __scsi_remove_target iterates through the SCSI devices on the host, but it drops the host_lock before calling scsi_remove_device. When the SCSI device is deleted from another thread, the pointer to the SCSI device in scsi_remove_device can become invalid. Fix this by getting a reference to the SCSI device before dropping the host_lock to keep the SCSI device alive for the call to scsi_remove_device. Signed-off-by: Christof Schmitt Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit f89236606b91a98c1944f59ee66265d15e74a7c2 Author: Dan Carpenter Date: Fri Oct 8 09:03:07 2010 +0200 gdth: integer overflow in ioctl commit f63ae56e4e97fb12053590e41a4fa59e7daa74a4 upstream. gdth_ioctl_alloc() takes the size variable as an int. copy_from_user() takes the size variable as an unsigned long. gen.data_len and gen.sense_len are unsigned longs. On x86_64 longs are 64 bit and ints are 32 bit. We could pass in a very large number and the allocation would truncate the size to 32 bits and allocate a small buffer. Then when we do the copy_from_user(), it would result in a memory corruption. Signed-off-by: Dan Carpenter Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit f8d4ab3d9bfdb249c3489e92478685b986ef6fcc Author: David Milburn Date: Fri Sep 3 17:13:03 2010 -0500 libsas: fix NCQ mixing with non-NCQ commit f0ad30d3d2dc924decc0e10b1ff6dc32525a5d99 upstream. Some cards (like mvsas) have issue troubles if non-NCQ commands are mixed with NCQ ones. Fix this by using the libata default NCQ check routine which waits until all NCQ commands are complete before issuing a non-NCQ one. The impact to cards (like aic94xx) which don't need this logic should be minimal Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 9f26affd9550b922dd8aaafd7ee3f54844e6cbea Author: Michael Reed Date: Mon Sep 20 11:20:22 2010 -0500 sd name space exhaustion causes system hang commit 1a03ae0f556a931aa3747b70e44b78308f5b0590 upstream. Following a site power outage which re-enabled all the ports on my FC switches, my system subsequently booted with far too many luns! I had let it run hoping it would make multi-user. It didn't. :( It hung solid after exhausting the last sd device, sdzzz, and attempting to create sdaaaa and beyond. I was unable to get a dump. Discovered using a 2.6.32.13 based system. correct this by detecting when the last index is utilized and failing the sd probe of the device. Patch applies to scsi-misc-2.6. Signed-off-by: Michael Reed Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 7d7e0fa3d4b3e8ee06da8eae62ff86b37d7013e2 Author: Alan Stern Date: Thu Oct 14 15:25:21 2010 -0400 USB: accept some invalid ep0-maxpacket values commit 56626a72a47bf3e50875d960d6b5f17b9bee0ab2 upstream. A few devices (such as the RCA VR5220 voice recorder) are so non-compliant with the USB spec that they have invalid maxpacket sizes for endpoint 0. Nevertheless, as long as we can safely use them, we may as well do so. This patch (as1432) softens our acceptance criterion by allowing high-speed devices to have ep0-maxpacket sizes other than 64. A warning is printed in the system log when this happens, and the existing error message is clarified. Signed-off-by: Alan Stern Reported-by: James Signed-off-by: Greg Kroah-Hartman commit b7562261f479efd9b821885fdbed4646d11459f9 Author: Alon Ziv Date: Sun Oct 10 08:32:18 2010 +0200 USB: opticon: Fix long-standing bugs in opticon driver commit 97cd8dc4ca9a1a5efb2cc38758e01492e3b013e2 upstream. The bulk-read callback had two bugs: a) The bulk-in packet's leading two zeros were returned (and the two last bytes truncated) b) The wrong URB was transmitted for the second (and later) read requests, causing further reads to return the entire packet (including leading zeros) Signed-off-by: Alon Ziv Signed-off-by: Greg Kroah-Hartman commit 12a9dbf4448476b2fb523a64f3a6a4624d5a7da4 Author: Alan Stern Date: Thu Sep 30 15:16:23 2010 -0400 USB: disable endpoints after unbinding interfaces, not before commit 80f0cf3947889014d3a3dc0ad60fb87cfda4b12a upstream. This patch (as1430) fixes a bug in usbcore. When a device configuration change occurs or a device is removed, the endpoints for the old config should be completely disabled. However it turns out they aren't; this is because usb_unbind_interface() calls usb_enable_interface() or usb_set_interface() to put interfaces back in altsetting 0, which re-enables the interfaces' endpoints. As a result, when a device goes through a config change or is unconfigured, the ep_in[] and ep_out[] arrays may be left holding old pointers to usb_host_endpoint structures. If the device is deauthorized these structures get freed, and the stale pointers cause errors when the the device is eventually unplugged. The solution is to disable the endpoints after unbinding the interfaces instead of before. This isn't as large a change as it sounds, since usb_unbind_interface() disables all the interface's endpoints anyway before calling the driver's disconnect routine, unless the driver claims to support "soft" unbind. This fixes Bugzilla #19192. Thanks to "Tom" Lei Ming for diagnosing the underlying cause of the problem. Signed-off-by: Alan Stern Tested-by: Carsten Sommer Signed-off-by: Greg Kroah-Hartman commit 1ec2786c5c25810f5592288353cab37dd0517793 Author: Jean-Christophe PLAGNIOL-VILLARD Date: Mon Sep 20 18:31:07 2010 +0200 USB: atmel_usba_udc: force vbus_pin at -EINVAL when gpio_request failled commit 969affff54702785330de553b790372e261e93f9 upstream. to ensure gpio_is_valid return false Signed-off-by: Nicolas Ferre Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Greg Kroah-Hartman commit 4dadf0b4ec84ac2aedf887ac63bb2ba09cfc27c7 Author: Anders Larsen Date: Wed Oct 6 23:46:25 2010 +0200 USB: cp210x: Add WAGO 750-923 Service Cable device ID commit 93ad03d60b5b18897030038234aa2ebae8234748 upstream. The WAGO 750-923 USB Service Cable is used for configuration and firmware updates of several industrial automation products from WAGO Kontakttechnik GmbH. Bus 004 Device 002: ID 1be3:07a6 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1be3 idProduct 0x07a6 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 WAGO USB Service Cable iSerial 3 1277796751 . . . Signed-off-by: Anders Larsen Signed-off-by: Greg Kroah-Hartman commit e834699115ca4431e7fcfb4892ffdc485e36937b Author: DJ Delorie Date: Fri Sep 17 11:09:06 2010 -0400 USB: cp210x: Add Renesas RX-Stick device ID commit 2f1136d1d08a63dcdbcd462621373f30d8dfe590 upstream. RX610 development board by Renesas Bus 001 Device 024: ID 045b:0053 Hitachi, Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x045b Hitachi, Ltd idProduct 0x0053 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 RX-Stick iSerial 3 0001 . . . http://am.renesas.com/rx610stick Signed-off-by: DJ Delorie Signed-off-by: Greg Kroah-Hartman commit 42cdebd71f1b5ae70d4d35ae0ecf488ac79ccb04 Author: Mauro Carvalho Chehab Date: Sun Sep 12 11:41:50 2010 -0300 USB: option: Add more ZTE modem USB id's commit ecfa153ef616b901e86d9a051b329fcda7a6ce7b upstream. There are lots of ZTE USB id's currently not covered by usb/serial. Adds them, to allow those devices to work properly on Linux. While here, put the USB ID's for 0x2002/0x2003 at the sorted order. This patch is based on zte.c file found on MF645. PS.: The ZTE driver is commenting the USB ID for 0x0053. It also adds, commented, an USB ID for 0x0026. Not sure why, but I think that 0053 is used by their devices in storage mode only. So, I opted to keep the comment on this patch. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 2e44efff4dd178ca52f49d9c487951d5e5bbc7cc Author: Sergei Shtylyov Date: Wed Sep 29 09:54:31 2010 +0300 usb: musb: blackfin: call gpio_free() on error path in musb_platform_init() commit 00be545e49d83485d49a598d3b7e090088934be8 upstream. Blackfin's musb_platform_init() needs to call gpio_free() for error cleanup iff otg_get_transceiver() call returns NULL. Signed-off-by: Sergei Shtylyov Acked-by: Mike Frysinger Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 605c6c2c11a74af2bc05e187072a65ee00131162 Author: Greg Kroah-Hartman Date: Tue Oct 19 09:05:43 2010 -0700 USB: ftdi_sio: add device ids for ScienceScope commit 0f266abd70cd83571eca019f764b5f1992da7361 upstream. This adds the requested device ids to the ftdi_sio driver. Reported-by: Ewan Bingham Cc: Kuba Ober Signed-off-by: Greg Kroah-Hartman commit 2ea4a09c514c16836abe91461e978e0de3bac36d Author: Daniel Suchy Date: Tue Oct 12 15:44:24 2010 +0200 USB: ftdi_sio: new VID/PIDs for various Papouch devices commit 59c6ccd9f9aecfa59c99ceba6d4d34b180547a05 upstream. This patch for FTDI USB serial driver ads new VID/PIDs used on various devices manufactured by Papouch (http://www.papouch.com). These devices have their own VID/PID, although they're using standard FTDI chip. In ftdi_sio.c, I also made small cleanup to have declarations for all Papouch devices together. Signed-off-by: Daniel Suchy Signed-off-by: Greg Kroah-Hartman commit 2bcfe3fa4118efc9d9b5e2c459f8578c3a6a78bc Author: Rainer Keller Date: Tue Sep 28 12:27:43 2010 +0200 USB: add PID for FTDI based OpenDCC hardware commit 99c1e4f89d1033444ce4d0c064bd2826e81c3775 upstream. The OpenDCC project is developing a new hardware. This patch adds its PID to the list of known FTDI devices. The PID can be found at http://www.opendcc.de/elektronik/usb/opendcc_usb.html Signed-off-by: Rainer Keller Signed-off-by: Greg Kroah-Hartman commit 702a856650a57851a68cdd37361b80190ed5fe0f Author: Rich Mattes Date: Tue Sep 14 00:35:40 2010 -0400 USB: ftdi_sio: Add PID for accesio products commit 3126d8236ca6f68eb8292c6af22c2e59afbeef24 upstream. Adds support for Accesio USB to Serial adapters, which are built around FTDI FT232 UARTs. Tested with the Accesio USB-COM-4SM. Signed-off-by: Rich Mattes Signed-off-by: Greg Kroah-Hartman commit 7577c943f913d95b797c5bcd9862c47a06bbdb66 Author: Julia Lawall Date: Fri Oct 15 15:00:06 2010 +0200 drivers/net/wireless/p54/eeprom.c: Return -ENOMEM on memory allocation failure commit 0d91f22b75347d9503b17a42b6c74d3f7750acd6 upstream. In this code, 0 is returned on memory allocation failure, even though other failures return -ENOMEM or other similar values. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression ret; expression x,e1,e2,e3; @@ ret = 0 ... when != ret = e1 *x = \(kmalloc\|kcalloc\|kzalloc\)(...) ... when != ret = e2 if (x == NULL) { ... when != ret = e3 return ret; } // Signed-off-by: Julia Lawall Acked-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 735a3742bb8705f71d185d16ef2a9b1ee156003a Author: Christian Lamparter Date: Fri Oct 1 22:01:24 2010 +0200 p54usb: add five more USBIDs commit 1a92795dac419128eb511dce30a6aad672064b88 upstream. Source: http://www.wikidevi.com/wiki/Intersil/p54/usb/windows Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 2d034687a6fe3ff3c82a67ac00f38327f705f497 Author: Christian Lamparter Date: Sun Aug 22 22:41:33 2010 +0200 p54usb: fix off-by-one on !CONFIG_PM commit 11791a6f7534906b4a01ffb54ba0b02ca39398ef upstream. The ISL3887 chip needs a USB reset, whenever the usb-frontend module "p54usb" is reloaded. This patch fixes an off-by-one bug, if the user is running a kernel without the CONFIG_PM option set and for some reason (e.g.: compat-wireless) wants to switch between different p54usb modules. Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit a835be5be324ccd5c99b4f95d9f79e6ebdb63ad5 Author: Nicolas Kaiser Date: Thu Oct 21 14:56:00 2010 +0200 pipe: fix failure to return error code on ->confirm() commit e5953cbdff26f7cbae7eff30cd9b18c4e19b7594 upstream. The arguments were transposed, we want to assign the error code to 'ret', which is being returned. Signed-off-by: Nicolas Kaiser Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 325d960fd9c0211aa32ecffb80edf430b9f9f87e Author: Avi Kivity Date: Thu Oct 28 16:48:16 2010 -0200 KVM: Fix fs/gs reload oops with invalid ldt commit 9581d442b9058d3699b4be568b6e5eae38a41493 upstream kvm reloads the host's fs and gs blindly, however the underlying segment descriptors may be invalid due to the user modifying the ldt after loading them. Fix by using the safe accessors (loadsegment() and load_gs_index()) instead of home grown unsafe versions. This is CVE-2010-3698. Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 69b54926aa37cb07b23ef856d82ea5ec9df8bb86 Author: Zachary Amsden Date: Thu Oct 28 16:48:15 2010 -0200 KVM: x86: Move TSC reset out of vmcb_init commit 47008cd887c1836bcadda123ba73e1863de7a6c4 upstream. The VMCB is reset whenever we receive a startup IPI, so Linux is setting TSC back to zero happens very late in the boot process and destabilizing the TSC. Instead, just set TSC to zero once at VCPU creation time. Why the separate patch? So git-bisect is your friend. Signed-off-by: Zachary Amsden Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 60977a7ab5c850828eccad4ce711f499a1918599 Author: Zachary Amsden Date: Thu Oct 28 16:48:14 2010 -0200 KVM: x86: Fix SVM VMCB reset commit 58877679fd393d3ef71aa383031ac7817561463d upstream. On reset, VMCB TSC should be set to zero. Instead, code was setting tsc_offset to zero, which passes through the underlying TSC. Signed-off-by: Zachary Amsden Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit cd80c840270c7b57bc38d6e2e1647e84ce23075d Author: Joerg Roedel Date: Thu Oct 28 16:48:13 2010 -0200 KVM: SVM: Adjust tsc_offset only if tsc_unstable commit 953899b659adce62cbe83d6a7527550ab8797c48 upstream. The tsc_offset adjustment in svm_vcpu_load is executed unconditionally even if Linux considers the host tsc as stable. This causes a Linux guest detecting an unstable tsc in any case. This patch removes the tsc_offset adjustment if the host tsc is stable. The guest will now get the benefit of a stable tsc too. Signed-off-by: Joerg Roedel Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit ffc109c28a6a4cb5047df82b1d18ad7a13d3e247 Author: Avi Kivity Date: Thu Oct 28 16:48:12 2010 -0200 KVM: VMX: Fix host GDT.LIMIT corruption commit 3444d7da1839b851eefedd372978d8a982316c36 upstream. vmx does not restore GDT.LIMIT to the host value, instead it sets it to 64KB. This means host userspace can learn a few bits of host memory. Fix by reloading GDTR when we load other host state. Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit dbd877e34acf443e11c09361d0eaeaade441de86 Author: Xiao Guangrong Date: Thu Oct 28 16:48:11 2010 -0200 KVM: MMU: fix conflict access permissions in direct sp commit 5fd5387c89ec99ff6cb82d2477ffeb7211b781c2 upstream. In no-direct mapping, we mark sp is 'direct' when we mapping the guest's larger page, but its access is encoded form upper page-struct entire not include the last mapping, it will cause access conflict. For example, have this mapping: [W] / PDE1 -> |---| P[W] | | LPA \ PDE2 -> |---| [R] P have two children, PDE1 and PDE2, both PDE1 and PDE2 mapping the same lage page(LPA). The P's access is WR, PDE1's access is WR, PDE2's access is RO(just consider read-write permissions here) When guest access PDE1, we will create a direct sp for LPA, the sp's access is from P, is W, then we will mark the ptes is W in this sp. Then, guest access PDE2, we will find LPA's shadow page, is the same as PDE's, and mark the ptes is RO. So, if guest access PDE1, the incorrect #PF is occured. Fixed by encode the last mapping access into direct shadow page Signed-off-by: Xiao Guangrong Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 31c6c80f10a4d09fba8ad8d4c57ac2eb2bd23335 Author: Xiao Guangrong Date: Thu Oct 28 16:48:10 2010 -0200 KVM: MMU: fix direct sps access corrupted commit 9e7b0e7fba45ca3c6357aeb7091ebc281f1de365 upstream. If the mapping is writable but the dirty flag is not set, we will find the read-only direct sp and setup the mapping, then if the write #PF occur, we will mark this mapping writable in the read-only direct sp, now, other real read-only mapping will happily write it without #PF. It may hurt guest's COW Fixed by re-install the mapping when write #PF occur. Signed-off-by: Xiao Guangrong Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 004ff730b84c2f35a69871fe3bcde07232ed8610 Author: Joerg Roedel Date: Thu Oct 28 16:48:09 2010 -0200 KVM: SVM: Fix wrong intercept masks on 32 bit commit 061e2fd16863009c8005b4b5fdfb75c7215c0b99 upstream. This patch makes KVM on 32 bit SVM working again by correcting the masks used for iret interception. With the wrong masks the upper 32 bits of the intercepts are masked out which leaves vmrun unintercepted. This is not legal on svm and the vmrun fails. Bug was introduced by commits 95ba827313 and 3cfc3092. Cc: Jan Kiszka Cc: Gleb Natapov Signed-off-by: Joerg Roedel Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit b0051893fd01e362c8065bc5d8b51961fdd15a5b Author: Cliff Wickman Date: Wed Sep 8 10:14:27 2010 -0500 x86, kdump: Change copy_oldmem_page() to use cached addressing commit 37a2f9f30a360fb03522d15c85c78265ccd80287 upstream. The copy of /proc/vmcore to a user buffer proceeds much faster if the kernel addresses memory as cached. With this patch we have seen an increase in transfer rate from less than 15MB/s to 80-460MB/s, depending on size of the transfer. This makes a big difference in time needed to save a system dump. Signed-off-by: Cliff Wickman Acked-by: "Eric W. Biederman" Cc: kexec@lists.infradead.org LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 5d1b265401b8f26a070a82baf76a7c37c0b48108 Author: Suresh Siddha Date: Fri Aug 27 11:09:48 2010 -0700 x86, intr-remap: Set redirection hint in the IRTE commit 75e3cfbed6f71a8f151dc6e413b6ce3c390030cb upstream. Currently the redirection hint in the interrupt-remapping table entry is set to 0, which means the remapped interrupt is directed to the processors listed in the destination. So in logical flat mode in the presence of intr-remapping, this results in a single interrupt multi-casted to multiple cpu's as specified by the destination bit mask. But what we really want is to send that interrupt to one of the cpus based on the lowest priority delivery mode. Set the redirection hint in the IRTE to '1' to indicate that we want the remapped interrupt to be directed to only one of the processors listed in the destination. This fixes the issue of same interrupt getting delivered to multiple cpu's in the logical flat mode in the presence of interrupt-remapping. While there is no functional issue observed with this behavior, this will impact performance of such configurations (<=8 cpu's using logical flat mode in the presence of interrupt-remapping) Signed-off-by: Suresh Siddha LKML-Reference: <20100827181049.013051492@sbsiddha-MOBL3.sc.intel.com> Cc: Weidong Han Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 810db148ee9d0bbef38a05d326c455978f5bd02c Author: Andreas Herrmann Date: Thu Sep 30 14:32:35 2010 +0200 x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUs commit 3fdbf004c1706480a7c7fac3c9d836fa6df20d7d upstream. Instead of adapting the CPU family check in amd_special_default_mtrr() for each new CPU family assume that all new AMD CPUs support the necessary bits in SYS_CFG MSR. Tom2Enabled is architectural (defined in APM Vol.2). Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT. In pre K8-NPT BKDG this bit is reserved (read as zero). W/o this adaption Linux would unnecessarily complain about bad MTRR settings on every new AMD CPU family, e.g. [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM. Signed-off-by: Andreas Herrmann LKML-Reference: <20100930123235.GB20545@loge.amd.com> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit f86bbe3d27d8ca02e40fbd779238a7c89924f0ca Author: Paul Fox Date: Fri Oct 1 18:17:19 2010 +0100 x86, olpc: Don't retry EC commands forever commit 286e5b97eb22baab9d9a41ca76c6b933a484252c upstream. Avoids a potential infinite loop. It was observed once, during an EC hacking/debugging session - not in regular operation. Signed-off-by: Daniel Drake Cc: dilinger@queued.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ae832c21a08514fd11d2d1d6e217c8a537764bb0 Author: Alok Kataria Date: Mon Oct 11 14:37:08 2010 -0700 x86, kexec: Make sure to stop all CPUs before exiting the kernel commit 76fac077db6b34e2c6383a7b4f3f4f7b7d06d8ce upstream. x86 smp_ops now has a new op, stop_other_cpus which takes a parameter "wait" this allows the caller to specify if it wants to stop until all the cpus have processed the stop IPI. This is required specifically for the kexec case where we should wait for all the cpus to be stopped before starting the new kernel. We now wait for the cpus to stop in all cases except for panic/kdump where we expect things to be broken and we are doing our best to make things work anyway. This patch fixes a legitimate regression, which was introduced during 2.6.30, by commit id 4ef702c10b5df18ab04921fc252c26421d4d6c75. Signed-off-by: Alok N Kataria LKML-Reference: <1286833028.1372.20.camel@ank32.eng.vmware.com> Cc: Eric W. Biederman Cc: Jeremy Fitzhardinge Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 7d778ac64b7d42ff3814348a25e99c778f8473f5 Author: Andre Przywara Date: Mon Sep 6 15:14:17 2010 +0200 x86, cpu: Fix renamed, not-yet-shipping AMD CPUID feature bit commit 7ef8aa72ab176e0288f363d1247079732c5d5792 upstream. The AMD SSE5 feature set as-it has been replaced by some extensions to the AVX instruction set. Thus the bit formerly advertised as SSE5 is re-used for one of these extensions (XOP). Although this changes the /proc/cpuinfo output, it is not user visible, as there are no CPUs (yet) having this feature. To avoid confusion this should be added to the stable series, too. Signed-off-by: Andre Przywara LKML-Reference: <1283778860-26843-2-git-send-email-andre.przywara@amd.com> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 9809892e2ccb494ad97599a018788f5abe8f7842 Author: Cliff Wickman Date: Thu Sep 16 11:44:02 2010 -0500 mm, x86: Saving vmcore with non-lazy freeing of vmas commit 3ee48b6af49cf534ca2f481ecc484b156a41451d upstream. During the reading of /proc/vmcore the kernel is doing ioremap()/iounmap() repeatedly. And the buildup of un-flushed vm_area_struct's is causing a great deal of overhead. (rb_next() is chewing up most of that time). This solution is to provide function set_iounmap_nonlazy(). It causes a subsequent call to iounmap() to immediately purge the vma area (with try_purge_vmap_area_lazy()). With this patch we have seen the time for writing a 250MB compressed dump drop from 71 seconds to 44 seconds. Signed-off-by: Cliff Wickman Cc: Andrew Morton Cc: kexec@lists.infradead.org LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 183308db7612a1b46a2b6355e83d93a4a8950771 Author: Darren Hart Date: Sun Oct 17 08:35:04 2010 -0700 futex: Fix errors in nested key ref-counting commit 7ada876a8703f23befbb20a7465a702ee39b1704 upstream. futex_wait() is leaking key references due to futex_wait_setup() acquiring an additional reference via the queue_lock() routine. The nested key ref-counting has been masking bugs and complicating code analysis. queue_lock() is only called with a previously ref-counted key, so remove the additional ref-counting from the queue_(un)lock() functions. Also futex_wait_requeue_pi() drops one key reference too many in unqueue_me_pi(). Remove the key reference handling from unqueue_me_pi(). This was paired with a queue_lock() in futex_lock_pi(), so the count remains unchanged. Document remaining nested key ref-counting sites. Signed-off-by: Darren Hart Reported-and-tested-by: Matthieu Fertré Reported-by: Louis Rilling Cc: Peter Zijlstra Cc: Eric Dumazet Cc: John Kacur Cc: Rusty Russell LKML-Reference: <4CBB17A8.70401@linux.intel.com> Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 3502405eb88b9086acd4fe1dc5113122a19a2bb8 Author: Alan Cox Date: Fri Oct 22 14:11:26 2010 +0100 bluetooth: Fix missing NULL check commit c19483cc5e56ac5e22dd19cf25ba210ab1537773 upstream. Fortunately this is only exploitable on very unusual hardware. [Reported a while ago but nothing happened so just fixing it] Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ebf7608d15a8029ede4b186ba5ec891d0ecfd716 Author: Mathieu Desnoyers Date: Mon Sep 13 17:47:00 2010 -0400 sched: Fix string comparison in /proc/sched_features commit 7740191cd909b75d75685fb08a5d1f54b8a9d28b upstream. Fix incorrect handling of the following case: INTERACTIVE INTERACTIVE_SOMETHING_ELSE The comparison only checks up to each element's length. Changelog since v1: - Embellish using some Rostedtisms. [ mingo: ^^ == smaller and cleaner ] Signed-off-by: Mathieu Desnoyers Reviewed-by: Steven Rostedt Cc: Peter Zijlstra Cc: Tony Lindgren LKML-Reference: <20100913214700.GB16118@Krystal> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f055e6dfa6162006a79fee50a1893ff610d5a633 Author: Vasiliy Kulikov Date: Sun Oct 17 18:41:24 2010 +0400 pcmcia: synclink_cs: fix information leak to userland commit 5b917a1420d3d1a9c8da49fb0090692dc9aaee86 upstream. Structure new_line is copied to userland with some padding fields unitialized. It leads to leaking of stack memory. Signed-off-by: Vasiliy Kulikov Signed-off-by: Dominik Brodowski Signed-off-by: Greg Kroah-Hartman commit 89323c1e44e9b2aa2d749990bbe586551474167e Author: Paul Mackerras Date: Thu Sep 9 19:02:40 2010 +0000 powerpc/perf: Fix sampling enable for PPC970 commit 9f5f9ffe50e90ed73040d2100db8bfc341cee352 upstream. The logic to distinguish marked instruction events from ordinary events on PPC970 and derivatives was flawed. The result is that instruction sampling didn't get enabled in the PMU for some marked instruction events, so they would never trigger. This fixes it by adding the appropriate break statements in the switch statement. Reported-by: David Binderman Signed-off-by: Paul Mackerras Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit f37563afed04150301d66b6f2c128a09a83acdb5 Author: Max Vozeler Date: Tue Sep 21 17:43:30 2010 +0200 staging: usbip: Process event flags without delay commit 584c5b7cf06194464240280483ee0376cdddbbae upstream. The way the event handler works can cause it to delay events until eventual wakeup for another event. For example, on device detach (vhci): - Write to sysfs detach file -> usbip_event_add(VDEV_EVENT_DOWN) -> wakeup() #define VDEV_EVENT_DOWN (USBIP_EH_SHUTDOWN | USBIP_EH_RESET). - Event thread wakes up and passes the event to event_handler() to process. - It processes and clears the USBIP_EH_SHUTDOWN flag then returns. - The outer event loop (event_handler_loop()) calls wait_event_interruptible(). The processing of the second flag which is part of VDEV_EVENT_DOWN (USBIP_EH_RESET) did not happen yet. It is delayed until the next event. This means the ->reset callback may not happen for a long time (if ever), leaving the usbip port in a weird state which prevents its reuse. This patch changes the handler to process all flags before waiting for another wakeup. I have verified this change to fix a problem which prevented reattach of a usbip device. It also helps for socket errors which missed the RESET as well. The delayed event processing also affects the stub side of usbip and the error handling there. Signed-off-by: Max Vozeler Reported-by: Marco Lancione Tested-by: Luc Jalbert Signed-off-by: Greg Kroah-Hartman commit 7f04bf4d3c8bfdfb7dff3db98af6ab7272b516fc Author: Max Vozeler Date: Tue Sep 21 17:31:40 2010 +0200 staging: usbip: Notify usb core of port status changes commit 0c9a32f0192e656daa2ff3c9149f6d71b4a1b873 upstream. This patch changes vhci to behave like dummy and other hcds when disconnecting a device. Previously detaching a device from the root hub did not notify the usb core of the disconnect and left the device visible. Signed-off-by: Max Vozeler Reported-by: Marco Lancione Tested-by: Luc Jalbert Signed-off-by: Greg Kroah-Hartman