commit 6f9a8e4c3a3d9539ee5fb2254c6865eea172321c Author: Paul Gortmaker Date: Thu Jan 6 18:08:33 2011 -0500 Linux 2.6.34.8 commit 9439dc94c9eb38c0b4f4c28059ec1ab24075772a 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: Paul Gortmaker commit 4121a3dd50cb59ef66840e7ca58180fc9c124fa4 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: Paul Gortmaker commit 959b106137840c62e4a5f43506aa14e6c369ed09 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: Paul Gortmaker commit e71740bf3ed9224a9f6e31e28a387cc23bbaa824 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: Paul Gortmaker commit 00c0012c32adebb709e8139ec603b476adae95ea 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: Paul Gortmaker commit 40f6bfc766b4a53c8018da34b18c772cbbeffce5 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: Paul Gortmaker commit 441830e3f24e6b6ff883c87f82b90fecb63ca12f 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 Signed-off-by: Paul Gortmaker commit 81f283bc95cff84658d28de141e93f0760081e40 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 Signed-off-by: Paul Gortmaker commit 374c5bb65bf098fbb368a74767c2d0134addf631 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 Signed-off-by: Paul Gortmaker commit 4d312ca972eabd1401dd098ba3e8935613fecff0 Author: Josh Wu Date: Tue Nov 16 11:51:32 2010 +0100 USB: gadget: AT91: fix typo in atmel_usba_udc driver commit b48809518631880207796b4aab0fc39c2f036754 upstream. compile fix for bug introduced by 969affff547027) Signed-off-by: Josh Wu Cc: Jiri Kosina Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 3fa294c80a5cdc2424a329f119f5d283b50f81ef 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 Signed-off-by: Paul Gortmaker commit 0aa066cc0e9dc0b3ac585570c6cf41abb6f60d44 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 Signed-off-by: Paul Gortmaker commit d2de05404404707fa90fe2ecb84eea6bd8809635 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 Signed-off-by: Paul Gortmaker commit 7d6697d9c9d3fb79fb64435594d510b3e1a9c93b 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 Signed-off-by: Paul Gortmaker commit 64ac50c65ae2202f0fb818c8ad93ab0d22d498fd 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 Signed-off-by: Paul Gortmaker commit 1ace6769cf2ae50bbaf3f358c00c2ea0f33f31d7 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 Signed-off-by: Paul Gortmaker commit bb58d69c762ac22488ef4846af30a2e02e5e85db 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 Signed-off-by: Paul Gortmaker commit 1f7b78db1ca017eb326dbd583f0a9cb497ac9363 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 Signed-off-by: Paul Gortmaker commit b566e0a93ded770c9422eb6d49c100ca4944050b 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 Signed-off-by: Paul Gortmaker commit 2d29e2c584ec9784b186324485143d5dfa2c0212 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: Paul Gortmaker commit c0d545fa659292441d34062fc797e685bb9952bf 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: Paul Gortmaker commit cf6df87124f97947c1d6a61fec37ce07d086f740 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: Paul Gortmaker commit 60534386c08a9bea1049415f88b8c976d27d5be0 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: Paul Gortmaker commit 69536bef5b84796e183b96fbc6f1dac1dce6dfd1 Author: Avi Kivity Date: Tue Oct 19 16:46:55 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. KVM-Stable-Tag. Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti Signed-off-by: Paul Gortmaker commit 279d80ac2efc706df67db8c1d636c96cd4ff97ac Author: Zachary Amsden Date: Thu Aug 19 22:07:19 2010 -1000 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: Paul Gortmaker commit d90a1cae6faee4835d8b5b534d86db9ab5864a7a Author: Zachary Amsden Date: Thu Aug 19 22:07:18 2010 -1000 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: Paul Gortmaker commit 01d1063c93a96ddae04498682eeb50cfd1760a21 Author: Avi Kivity Date: Mon Jul 26 18:32:38 2010 +0300 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: Paul Gortmaker commit 85a66b34c00d0a3acadedd1c4107fbc8587e4f69 Author: Xiao Guangrong Date: Wed Jun 30 16:02:45 2010 +0800 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: Paul Gortmaker commit 40b7c98b47dbef2871f026049d1b9da5ef7b14c8 Author: Xiao Guangrong Date: Wed Jun 30 16:03:28 2010 +0800 KVM: MMU: fix direct sp's 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: Paul Gortmaker commit 66226f90917ddca36b97bdeda52dbe266d818c14 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: Paul Gortmaker commit ead2c1440b100dc3b7013155474c325cdf186a3d 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: Paul Gortmaker commit 1c0838e0c3d91d973ba619ab03c440c0ddee6cbc 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: Paul Gortmaker commit d5632e193d11e1271a2c342cf8ced60053f83390 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: Paul Gortmaker commit 7d7eb1b7722acbd8277e929fe1c837b1e467dbf6 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: Paul Gortmaker commit 1d4f8bd80b862a5ae120a6f30a21193e4a8ca6a4 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: Paul Gortmaker commit ea5c9a4a8520d3174f5015feabaad52e5339989a 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: Paul Gortmaker commit f200cbb6fc3210c3b8d399196dc2c0b15639a581 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: Paul Gortmaker commit 4adac1e0f010d009a08223c14d763787f0e46355 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: Paul Gortmaker commit 5978217da51b10453fd4cebc1b8832d07c704c7f 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: Paul Gortmaker commit c32b9b64959bdfa3fcf7ea693869e25de1201c7e 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: Paul Gortmaker commit ab45a58b6536bdd81eb88833b13885e504b50690 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: Paul Gortmaker commit d2b82d06a3fbbc17369324b6acb48fad7aeaed33 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 Signed-off-by: Paul Gortmaker commit 1dcf63544ee21668c49cd519c3db50406bf1ffb0 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 Signed-off-by: Paul Gortmaker commit 9ff8711f3ec85bbf5c5c581bad4446b03b9e30c1 Author: Stefan Bader Date: Tue Aug 31 15:52:27 2010 +0200 mm: Move vma_stack_continue into mm.h commit 39aa3cb3e8250db9188a6f1e3fb62ffa1a717678 upstream. So it can be used by all that need to check for that. Signed-off-by: Stefan Bader Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit b06887194bbbf899a9c6d19343585430499265e4 Author: Roland McGrath Date: Tue Sep 7 19:37:06 2010 -0700 execve: make responsive to SIGKILL with large arguments commit 9aea5a65aa7a1af9a4236dfaeb0088f1624f9919 upstream. An execve with a very large total of argument/environment strings can take a really long time in the execve system call. It runs uninterruptibly to count and copy all the strings. This change makes it abort the exec quickly if sent a SIGKILL. Note that this is the conservative change, to interrupt only for SIGKILL, by using fatal_signal_pending(). It would be perfectly correct semantics to let any signal interrupt the string-copying in execve, i.e. use signal_pending() instead of fatal_signal_pending(). We'll save that change for later, since it could have user-visible consequences, such as having a timer set too quickly make it so that an execve can never complete, though it always happened to work before. Signed-off-by: Roland McGrath Reviewed-by: KOSAKI Motohiro Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 530cec0b21b6f8fdd2cd45893bb9c06b6afe256e Author: Roland McGrath Date: Tue Sep 7 19:36:28 2010 -0700 execve: improve interactivity with large arguments commit 7993bc1f4663c0db67bb8f0d98e6678145b387cd upstream. This adds a preemption point during the copying of the argument and environment strings for execve, in copy_strings(). There is already a preemption point in the count() loop, so this doesn't add any new points in the abstract sense. When the total argument+environment strings are very large, the time spent copying them can be much more than a normal user time slice. So this change improves the interactivity of the rest of the system when one process is doing an execve with very large arguments. Signed-off-by: Roland McGrath Reviewed-by: KOSAKI Motohiro Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit fe3a036d4230f0268aec6409ec396b323c0b1f0e Author: Roland McGrath Date: Tue Sep 7 19:35:49 2010 -0700 setup_arg_pages: diagnose excessive argument size commit 1b528181b2ffa14721fb28ad1bd539fe1732c583 upstream. The CONFIG_STACK_GROWSDOWN variant of setup_arg_pages() does not check the size of the argument/environment area on the stack. When it is unworkably large, shift_arg_pages() hits its BUG_ON. This is exploitable with a very large RLIMIT_STACK limit, to create a crash pretty easily. Check that the initial stack is not too large to make it possible to map in any executable. We're not checking that the actual executable (or intepreter, for binfmt_elf) will fit. So those mappings might clobber part of the initial stack mapping. But that is just userland lossage that userland made happen, not a kernel problem. Signed-off-by: Roland McGrath Reviewed-by: KOSAKI Motohiro Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit d21e190e40650c71daa45d953c1ea05771234424 Author: Jacob Pan Date: Wed May 19 12:01:23 2010 -0700 x86: detect scattered cpuid features earlier commit 1dedefd1a066a795a87afca9c0236e1a94de9bf6 upstream. Some extra CPU features such as ARAT is needed in early boot so that x86_init function pointers can be set up properly. http://lkml.org/lkml/2010/5/18/519 At start_kernel() level, this patch moves init_scattered_cpuid_features() from check_bugs() to setup_arch() -> early_cpu_init() which is earlier than platform specific x86_init layer setup. Suggested by HPA. Signed-off-by: Jacob Pan LKML-Reference: <1274295685-6774-2-git-send-email-jacob.jun.pan@linux.intel.com> Acked-by: Thomas Gleixner Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit 0c3036ea6c388bb1962e9a4c2fa646d6a15bb7ca Author: Zhang Rui Date: Tue Sep 28 22:48:55 2010 -0400 ACPI: Disable Windows Vista compatibility for Toshiba P305D commit 337279ce3aa85d81d34c0f837d1c204df105103b upstream. Disable the Windows Vista (SP1) compatibility for Toshiba P305D. http://bugzilla.kernel.org/show_bug.cgi?id=14736 Signed-off-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Paul Gortmaker commit 5623100fd92e5ef15318837f3f28030aeeff1591 Author: Len Brown Date: Tue Sep 28 17:20:20 2010 -0400 ACPI: delete ZEPTO idle=nomwait DMI quirk commit 64a32307b710c100beb101e9c78f8022f0e8ba61 upstream. per comments in the bug report, this entry seems to hurt at much as it helps. https://bugzilla.kernel.org/show_bug.cgi?id=10807 Signed-off-by: Len Brown Signed-off-by: Paul Gortmaker commit f5d13bee0feab02c841153990ddfb0d74074c41d Author: Len Brown Date: Tue Sep 28 17:51:51 2010 -0400 ACPI: EC: add Vista incompatibility DMI entry for Toshiba Satellite L355 commit 7a1d602f5fc35d14907b7da98d5627acb69589d1 upstream. https://bugzilla.kernel.org/show_bug.cgi?id=12641 Signed-off-by: Len Brown Signed-off-by: Paul Gortmaker commit 1cabbf3ec8fac5d4fbcc377c0fa67f659f55c745 Author: Len Brown Date: Fri Sep 24 21:02:27 2010 -0400 intel_idle: PCI quirk to prevent Lenovo Ideapad s10-3 boot hang commit 4731fdcf6f7bdab3e369a3f844d4ea4d4017284d upstream. When the Lenovo Ideapad S10-3 is booted with HT enabled, it hits a boot hang in the intel_idle driver. This occurs when entering ATM-C4 for the first time, unless BM_STS is first cleared. acpi_idle doesn't see this because it first checks and clears BM_STS, but it would hit the same hang if that check were disabled. http://bugs.meego.com/show_bug.cgi?id=7093 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/634702 Signed-off-by: Len Brown Signed-off-by: Paul Gortmaker commit 14327dc08260abe9b5259ea6dae771178201d72a Author: Colin Ian King Date: Mon Aug 2 15:14:43 2010 +0000 ACPI: enable repeated PCIEXP wakeup by clearing PCIEXP_WAKE_STS on resume commit 573b638158029898caf9470c8214b7ddd29751e3 upstream. Section 4.7.3.1.1 (PM1 Status Registers) of version 4.0 of the ACPI spec concerning PCIEXP_WAKE_STS points out in in the final note field in table 4-11 that if this bit is set to 1 and the system is put into a sleeping state then the system will not automatically wake. This bit gets set by hardware to indicate that the system woke up due to a PCI Express wakeup event, so clear it during acpi_hw_clear_acpi_status() calls to enable subsequent resumes to work. BugLink: http://bugs.launchpad.net/bugs/613381 Signed-off-by: Colin Ian King Signed-off-by: Len Brown Signed-off-by: Paul Gortmaker commit 9303c5eda74b6be97155b83a2ba6ffcdf98d2845 Author: Paul Fertser Date: Mon Oct 11 15:45:35 2010 -0700 b44: fix carrier detection on bind commit bcf64aa379fcadd074449cbf0c049da70071b06f upstream. For carrier detection to work properly when binding the driver with a cable unplugged, netif_carrier_off() should be called after register_netdev(), not before. Signed-off-by: Paul Fertser Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 14c4f079fde2791e39f9177fee7d6a3829214bde Author: Michael Neuling Date: Wed Aug 25 21:04:25 2010 +0000 powerpc: Don't use kernel stack with translation off commit 54a834043314c257210db2a9d59f8cc605571639 upstream. In f761622e59433130bc33ad086ce219feee9eb961 we changed early_setup_secondary so it's called using the proper kernel stack rather than the emergency one. Unfortunately, this stack pointer can't be used when translation is off on PHYP as this stack pointer might be outside the RMO. This results in the following on all non zero cpus: cpu 0x1: Vector: 300 (Data Access) at [c00000001639fd10] pc: 000000000001c50c lr: 000000000000821c sp: c00000001639ff90 msr: 8000000000001000 dar: c00000001639ffa0 dsisr: 42000000 current = 0xc000000016393540 paca = 0xc000000006e00200 pid = 0, comm = swapper The original patch was only tested on bare metal system, so it never caught this problem. This changes __secondary_start so that we calculate the new stack pointer but only start using it after we've called early_setup_secondary. With this patch, the above problem goes away. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Paul Gortmaker commit da448e9121d8322ac75eb8b8b2dc730c3121317d Author: Matt Evans Date: Thu Aug 12 20:58:28 2010 +0000 powerpc: Initialise paca->kstack before early_setup_secondary commit f761622e59433130bc33ad086ce219feee9eb961 upstream. As early setup calls down to slb_initialize(), we must have kstack initialised before checking "should we add a bolted SLB entry for our kstack?" Failing to do so means stack access requires an SLB miss exception to refill an entry dynamically, if the stack isn't accessible via SLB(0) (kernel text & static data). It's not always allowable to take such a miss, and intermittent crashes will result. Primary CPUs don't have this issue; an SLB entry is not bolted for their stack anyway (as that lives within SLB(0)). This patch therefore only affects the init of secondaries. Signed-off-by: Matt Evans Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Paul Gortmaker commit 86261be42eeb89e48f9722c2eaf477da8ef44a36 Author: FUJITA Tomonori Date: Fri Sep 17 00:46:42 2010 +0900 bsg: fix incorrect device_status value commit 478971600e47cb83ff2d3c63c5c24f2b04b0d6a1 upstream. bsg incorrectly returns sg's masked_status value for device_status. [jejb: fix up expression logic] Reported-by: Douglas Gilbert Signed-off-by: FUJITA Tomonori Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit a6404cee269d28c433e786f9ed514758f59e83ed Author: Stanislaw Gruszka Date: Fri Oct 8 04:25:00 2010 +0000 r8169: allocate with GFP_KERNEL flag when able to sleep commit aeb19f6052b5e5c8a24aa444fbff73b84341beac upstream. We have fedora bug report where driver fail to initialize after suspend/resume because of memory allocation errors: https://bugzilla.redhat.com/show_bug.cgi?id=629158 To fix use GFP_KERNEL allocation where possible. Tested-by: Neal Becker Signed-off-by: Stanislaw Gruszka Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit ac173ae5cbf4f8c90c07a4a60a1b35e091d4a8aa Author: Stanislaw Gruszka Date: Tue Oct 5 15:11:40 2010 -0700 skge: add quirk to limit DMA commit 392bd0cb000d4aac9e88e4f50823db85e7220688 upstream. Skge devices installed on some Gigabyte motherboards are not able to perform 64 dma correctly due to board PCI implementation, so limit DMA to 32bit if such boards are detected. Bug was reported here: https://bugzilla.redhat.com/show_bug.cgi?id=447489 Signed-off-by: Stanislaw Gruszka Tested-by: Luya Tshimbalanga Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit a8b0f3f80981d7c2ec1ee5add800da67143614eb Author: Jianzhao Wang Date: Wed Sep 8 14:35:43 2010 -0700 net: blackhole route should always be recalculated commit ae2688d59b5f861dc70a091d003773975d2ae7fb upstream. Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error triggered by IKE for example), hence this kind of route is always temporary and so we should check if a better route exists for next packets. Bug has been introduced by commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92. Signed-off-by: Jianzhao Wang Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 5c30f6499e028123583a9558dacada798c7f1f07 Author: David S. Miller Date: Mon Sep 20 15:40:35 2010 -0700 rose: Fix signedness issues wrt. digi count. commit 9828e6e6e3f19efcb476c567b9999891d051f52f upstream. Just use explicit casts, since we really can't change the types of structures exported to userspace which have been around for 15 years or so. Reported-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit eda7fca53fce208055c2580c3ca321bc752ad29b Author: Eric Dumazet Date: Tue Sep 21 13:04:04 2010 -0700 netxen: dont set skb->truesize commit 7e96dc7045bff8758804b047c0dfb6868f182500 upstream. skb->truesize is set in core network. Dont change it unless dealing with fragments. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 6e029a079025b66a554708d869af455715ecf5cb Author: Tom Marshall Date: Mon Sep 20 15:42:05 2010 -0700 tcp: Fix race in tcp_poll commit a4d258036ed9b2a1811c3670c6099203a0f284a0 upstream. If a RST comes in immediately after checking sk->sk_err, tcp_poll will return POLLIN but not POLLOUT. Fix this by checking sk->sk_err at the end of tcp_poll. Additionally, ensure the correct order of operations on SMP machines with memory barriers. Signed-off-by: Tom Marshall Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit a621db98fc8cc7b5b513a51ee93df75537256850 Author: Kees Cook Date: Mon Oct 11 12:23:25 2010 -0700 net: clear heap allocations for privileged ethtool actions commit b00916b189d13a615ff05c9242201135992fcda3 upstream. Several other ethtool functions leave heap uncleared (potentially) by drivers. Some interfaces appear safe (eeprom, etc), in that the sizes are well controlled. In some situations (e.g. unchecked error conditions), the heap will remain unchanged in areas before copying back to userspace. Note that these are less of an issue since these all require CAP_NET_ADMIN. [PG: 34 doesn't have ethtool_get_rxnfc(), drop that chunk] Signed-off-by: Kees Cook Acked-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 11c0fc0f0406da7453a78970f874c3060dfc37ec Author: Eric Dumazet Date: Tue Sep 21 08:47:45 2010 +0000 ip: fix truesize mismatch in ip fragmentation commit 3d13008e7345fa7a79d8f6438150dc15d6ba6e9d upstream. Special care should be taken when slow path is hit in ip_fragment() : When walking through frags, we transfert truesize ownership from skb to frags. Then if we hit a slow_path condition, we must undo this or risk uncharging frags->truesize twice, and in the end, having negative socket sk_wmem_alloc counter, or even freeing socket sooner than expected. Many thanks to Nick Bowler, who provided a very clean bug report and test program. Thanks to Jarek for reviewing my first patch and providing a V2 While Nick bisection pointed to commit 2b85a34e911 (net: No more expensive sock_hold()/sock_put() on each tx), underlying bug is older (2.6.12-rc5) A side effect is to extend work done in commit b2722b1c3a893e (ip_fragment: also adjust skb->truesize for packets not owned by a socket) to ipv6 as well. Reported-and-bisected-by: Nick Bowler Tested-by: Nick Bowler Signed-off-by: Eric Dumazet CC: Jarek Poplawski CC: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit f5398f7a1b323a019b4b28d1ab40a300dbe5a755 Author: Maciej Żenczykowski Date: Sun Oct 3 14:49:00 2010 -0700 net: Fix IPv6 PMTU disc. w/ asymmetric routes commit ae878ae280bea286ff2b1e1cb6e609dd8cb4501d upstream. Signed-off-by: Maciej Żenczykowski Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit d486528e6bf52e986926eb7c51ee96063ac0334a Author: Kumar Sanghvi Date: Mon Sep 27 23:10:42 2010 +0000 Phonet: Correct header retrieval after pskb_may_pull commit a91e7d471e2e384035b9746ea707ccdcd353f5dd upstream. Retrieve the header after doing pskb_may_pull since, pskb_may_pull could change the buffer structure. This is based on the comment given by Eric Dumazet on Phonet Pipe controller patch for a similar problem. Signed-off-by: Kumar Sanghvi Acked-by: Linus Walleij Acked-by: Eric Dumazet Acked-by: Rémi Denis-Courmont Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit a38bf80d5f1cbcce44d6e5dd239cef82fb8b41e3 Author: Nagendra Tomar Date: Sat Oct 2 23:45:06 2010 +0000 net: Fix the condition passed to sk_wait_event() commit 482964e56e1320cb7952faa1932d8ecf59c4bf75 upstream. This patch fixes the condition (3rd arg) passed to sk_wait_event() in sk_stream_wait_memory(). The incorrect check in sk_stream_wait_memory() causes the following soft lockup in tcp_sendmsg() when the global tcp memory pool has exhausted. >>> snip <<< localhost kernel: BUG: soft lockup - CPU#3 stuck for 11s! [sshd:6429] localhost kernel: CPU 3: localhost kernel: RIP: 0010:[sk_stream_wait_memory+0xcd/0x200] [sk_stream_wait_memory+0xcd/0x200] sk_stream_wait_memory+0xcd/0x200 localhost kernel: localhost kernel: Call Trace: localhost kernel: [sk_stream_wait_memory+0x1b1/0x200] sk_stream_wait_memory+0x1b1/0x200 localhost kernel: [] autoremove_wake_function+0x0/0x40 localhost kernel: [ipv6:tcp_sendmsg+0x6e6/0xe90] tcp_sendmsg+0x6e6/0xce0 localhost kernel: [sock_aio_write+0x126/0x140] sock_aio_write+0x126/0x140 localhost kernel: [xfs:do_sync_write+0xf1/0x130] do_sync_write+0xf1/0x130 localhost kernel: [] autoremove_wake_function+0x0/0x40 localhost kernel: [hrtimer_start+0xe3/0x170] hrtimer_start+0xe3/0x170 localhost kernel: [vfs_write+0x185/0x190] vfs_write+0x185/0x190 localhost kernel: [sys_write+0x50/0x90] sys_write+0x50/0x90 localhost kernel: [system_call+0x7e/0x83] system_call+0x7e/0x83 >>> snip <<< What is happening is, that the sk_wait_event() condition passed from sk_stream_wait_memory() evaluates to true for the case of tcp global memory exhaustion. This is because both sk_stream_memory_free() and vm_wait are true which causes sk_wait_event() to *not* call schedule_timeout(). Hence sk_stream_wait_memory() returns immediately to the caller w/o sleeping. This causes the caller to again try allocation, which again fails and again calls sk_stream_wait_memory(), and so on. [ Bug introduced by commit c1cbe4b7ad0bc4b1d98ea708a3fecb7362aa4088 ("[NET]: Avoid atomic xchg() for non-error case") -DaveM ] Signed-off-by: Nagendra Singh Tomar Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 8581b1ea57950965b0d95f4d22f535db1ece0afa Author: David S. Miller Date: Mon Sep 27 20:24:54 2010 -0700 tcp: Fix >4GB writes on 64-bit. commit 01db403cf99f739f86903314a489fb420e0e254f upstream. Fixes kernel bugzilla #16603 tcp_sendmsg() truncates iov_len to an 'int' which a 4GB write to write zero bytes, for example. There is also the problem higher up of how verify_iovec() works. It wants to prevent the total length from looking like an error return value. However it does this using 'int', but syscalls return 'long' (and thus signed 64-bit on 64-bit machines). So it could trigger false-positives on 64-bit as written. So fix it to use 'long'. Reported-by: Olaf Bonorden Reported-by: Daniel Büse Reported-by: Andrew Morton Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit b85d0141df0385ecfbbd6a5b6e11c5055226b9ed Author: Ulrich Weber Date: Wed Sep 22 06:45:11 2010 +0000 xfrm4: strip ECN bits from tos field commit 94e2238969e89f5112297ad2a00103089dde7e8f upstream. otherwise ECT(1) bit will get interpreted as RTO_ONLINK and routing will fail with XfrmOutBundleGenError. Signed-off-by: Ulrich Weber Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 78528b972d7d73b221ba5a404bab65c0522be697 Author: Dave Airlie Date: Sat Sep 25 17:45:50 2010 +1000 drm/radeon: fix PCI ID 5657 to be an RV410 commit f459ffbdfd04edb4a8ce6eea33170eb057a5e695 upstream. fixes https://bugzilla.kernel.org/show_bug.cgi?id=19012 cc: stable@kernel.org Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit 9799b4df14606a6fe0d2874d42218a01f6dfbcd4 Author: Linus Torvalds Date: Fri Oct 15 11:09:28 2010 -0700 De-pessimize rds_page_copy_user commit 799c10559d60f159ab2232203f222f18fa3c4a5f upstream. Don't try to "optimize" rds_page_copy_user() by using kmap_atomic() and the unsafe atomic user mode accessor functions. It's actually slower than the straightforward code on any reasonable modern CPU. Back when the code was written (although probably not by the time it was actually merged, though), 32-bit x86 may have been the dominant architecture. And there kmap_atomic() can be a lot faster than kmap() (unless you have very good locality, in which case the virtual address caching by kmap() can overcome all the downsides). But these days, x86-64 may not be more populous, but it's getting there (and if you care about performance, it's definitely already there - you'd have upgraded your CPU's already in the last few years). And on x86-64, the non-kmap_atomic() version is faster, simply because the code is simpler and doesn't have the "re-try page fault" case. People with old hardware are not likely to care about RDS anyway, and the optimization for the 32-bit case is simply buggy, since it doesn't verify the user addresses properly. Reported-by: Dan Rosenberg Acked-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 767b3d5a639f76d930cf11eaaec374318a71c8a8 Author: Borislav Petkov Date: Fri Oct 8 12:08:34 2010 +0200 x86, AMD, MCE thresholding: Fix the MCi_MISCj iteration order commit 6dcbfe4f0b4e17e289d56fa534b7ce5a6b7f63a3 upstream. This fixes possible cases of not collecting valid error info in the MCE error thresholding groups on F10h hardware. The current code contains a subtle problem of checking only the Valid bit of MSR0000_0413 (which is MC4_MISC0 - DRAM thresholding group) in its first iteration and breaking out if the bit is cleared. But (!), this MSR contains an offset value, BlkPtr[31:24], which points to the remaining MSRs in this thresholding group which might contain valid information too. But if we bail out only after we checked the valid bit in the first MSR and not the block pointer too, we miss that other information. The thing is, MC4_MISC0[BlkPtr] is not predicated on MCi_STATUS[MiscV] or MC4_MISC0[Valid] and should be checked prior to iterating over the MCI_MISCj thresholding group, irrespective of the MC4_MISC0[Valid] setting. Signed-off-by: Borislav Petkov Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit cc0d092e92438e632df7354f16656b20b3a32931 Author: Luca Tettamanti Date: Wed Sep 22 10:41:58 2010 +0000 atl1: fix resume commit ec5a32f67c603b11d68eb283d94eb89a4f6cfce1 upstream. adapter->cmb.cmb is initialized when the device is opened and freed when it's closed. Accessing it unconditionally during resume results either in a crash (NULL pointer dereference, when the interface has not been opened yet) or data corruption (when the interface has been used and brought down adapter->cmb.cmb points to a deallocated memory area). Signed-off-by: Luca Tettamanti Acked-by: Chris Snook Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 5abe67cec849afb10f065f859799a4e3384dcf9f Author: Johannes Berg Date: Fri Sep 17 00:38:25 2010 +0200 wext: fix potential private ioctl memory content leak commit df6d02300f7c2fbd0fbe626d819c8e5237d72c62 upstream. When a driver doesn't fill the entire buffer, old heap contents may remain, and if it also doesn't update the length properly, this old heap content will be copied back to userspace. It is very unlikely that this happens in any of the drivers using private ioctls since it would show up as junk being reported by iwpriv, but it seems better to be safe here, so use kzalloc. Reported-by: Jeff Mahoney Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit 2428efbc77b557fe7e6e2d06dd4fb94aef18f6b1 Author: Joel Becker Date: Wed Sep 29 17:33:05 2010 -0700 ocfs2: Don't walk off the end of fast symlinks. commit 1fc8a117865b54590acd773a55fbac9221b018f0 upstream. ocfs2 fast symlinks are NUL terminated strings stored inline in the inode data area. However, disk corruption or a local attacker could, in theory, remove that NUL. Because we're using strlen() (my fault, introduced in a731d1 when removing vfs_follow_link()), we could walk off the end of that string. Signed-off-by: Joel Becker Signed-off-by: Paul Gortmaker commit 388a1771e497f0b78c8993e0259316673d5bc840 Author: Yegor Yefremov Date: Thu Sep 30 14:14:22 2010 +0200 i2c-pca: Fix waitforcompletion() return value commit 6abb930af064fb1cf4177d32e2c7bfb89eee0fe5 upstream. ret is still -1, if during the polling read_byte() returns at once with I2C_PCA_CON_SI set. So ret > 0 would lead *_waitforcompletion() to return 0, in spite of the proper behavior. The routine was rewritten, so that ret has always a proper value, before returning. Signed-off-by: Yegor Yefremov Reviewed-by: Wolfram Sang Signed-off-by: Jean Delvare Signed-off-by: Paul Gortmaker commit 825cdb6dcd0a001c57a7680ab6d2b8d7ebd8462d Author: Salman Qazi Date: Tue Oct 12 07:25:19 2010 -0700 hrtimer: Preserve timer state in remove_hrtimer() commit f13d4f979c518119bba5439dd2364d76d31dcd3f upstream. The race is described as follows: CPU X CPU Y remove_hrtimer // state & QUEUED == 0 timer->state = CALLBACK unlock timer base timer->f(n) //very long hrtimer_start lock timer base remove_hrtimer // no effect hrtimer_enqueue timer->state = CALLBACK | QUEUED unlock timer base hrtimer_start lock timer base remove_hrtimer mode = INACTIVE // CALLBACK bit lost! switch_hrtimer_base CALLBACK bit not set: timer->base changes to a different CPU. lock this CPU's timer base The bug was introduced with commit ca109491f (hrtimer: removing all ur callback modes) in 2.6.29 [ tglx: Feed new state via local variable and add a comment. ] Signed-off-by: Salman Qazi Cc: akpm@linux-foundation.org Cc: Peter Zijlstra LKML-Reference: <20101012142351.8485.21823.stgit@dungbeetle.mtv.corp.google.com> Signed-off-by: Thomas Gleixner Signed-off-by: Paul Gortmaker commit 1e5a0aef9c2c193d43f5942ceb8d427f3e94e667 Author: Simon Guinot Date: Fri Sep 17 23:33:51 2010 +0200 dmaengine: fix interrupt clearing for mv_xor commit cc60f8878eab892c03d06b10f389232b9b66bd83 upstream. When using simultaneously the two DMA channels on a same engine, some transfers are never completed. For example, an endless lock can occur while writing heavily on a RAID5 array (with async-tx offload support enabled). Note that this issue can also be reproduced by using the DMA test client. On a same engine, the interrupt cause register is shared between two DMA channels. This patch make sure that the cause bit is only cleared for the requested channel. Signed-off-by: Simon Guinot Tested-by: Luc Saillard Acked-by: saeed bishara Signed-off-by: Dan Williams Signed-off-by: Paul Gortmaker commit c5d9ae74e289afd95b62d2f0a5646acb3d5b5e29 Author: Steven Rostedt Date: Tue Oct 12 12:06:43 2010 -0400 ring-buffer: Fix typo of time extends per page commit d01343244abdedd18303d0323b518ed9cdcb1988 upstream. Time stamps for the ring buffer are created by the difference between two events. Each page of the ring buffer holds a full 64 bit timestamp. Each event has a 27 bit delta stamp from the last event. The unit of time is nanoseconds, so 27 bits can hold ~134 milliseconds. If two events happen more than 134 milliseconds apart, a time extend is inserted to add more bits for the delta. The time extend has 59 bits, which is good for ~18 years. Currently the time extend is committed separately from the event. If an event is discarded before it is committed, due to filtering, the time extend still exists. If all events are being filtered, then after ~134 milliseconds a new time extend will be added to the buffer. This can only happen till the end of the page. Since each page holds a full timestamp, there is no reason to add a time extend to the beginning of a page. Time extends can only fill a page that has actual data at the beginning, so there is no fear that time extends will fill more than a page without any data. When reading an event, a loop is made to skip over time extends since they are only used to maintain the time stamp and are never given to the caller. As a paranoid check to prevent the loop running forever, with the knowledge that time extends may only fill a page, a check is made that tests the iteration of the loop, and if the iteration is more than the number of time extends that can fit in a page a warning is printed and the ring buffer is disabled (all of ftrace is also disabled with it). There is another event type that is called a TIMESTAMP which can hold 64 bits of data in the theoretical case that two events happen 18 years apart. This code has not been implemented, but the name of this event exists, as well as the structure for it. The size of a TIMESTAMP is 16 bytes, where as a time extend is only 8 bytes. The macro used to calculate how many time extends can fit on a page used the TIMESTAMP size instead of the time extend size cutting the amount in half. The following test case can easily trigger the warning since we only need to have half the page filled with time extends to trigger the warning: # cd /sys/kernel/debug/tracing/ # echo function > current_tracer # echo 'common_pid < 0' > events/ftrace/function/filter # echo > trace # echo 1 > trace_marker # sleep 120 # cat trace Enabling the function tracer and then setting the filter to only trace functions where the process id is negative (no events), then clearing the trace buffer to ensure that we have nothing in the buffer, then write to trace_marker to add an event to the beginning of a page, sleep for 2 minutes (only 35 seconds is probably needed, but this guarantees the bug), and then finally reading the trace which will trigger the bug. This patch fixes the typo and prevents the false positive of that warning. Reported-by: Hans J. Koch Tested-by: Hans J. Koch Cc: Thomas Gleixner Signed-off-by: Steven Rostedt Signed-off-by: Paul Gortmaker commit e0984fdc6395de710fc5ff2a25fe2df251c22bc0 Author: Tejun Heo Date: Fri Oct 15 12:56:21 2010 +0200 ubd: fix incorrect sector handling during request restart commit 47526903feb52f4c26a6350370bdf74e337fcdb1 upstream. Commit f81f2f7c (ubd: drop unnecessary rq->sector manipulation) dropped request->sector manipulation in preparation for global request handling cleanup; unfortunately, it incorrectly assumed that the updated sector wasn't being used. ubd tries to issue as many requests as possible to io_thread. When issuing fails due to memory pressure or other reasons, the device is put on the restart list and issuing stops. On IO completion, devices on the restart list are scanned and IO issuing is restarted. ubd issues IOs sg-by-sg and issuing can be stopped in the middle of a request, so each device on the restart queue needs to remember where to restart in its current request. ubd needs to keep track of the issue position itself because, * blk_rq_pos(req) is now updated by the block layer to keep track of _completion_ position. * Multiple io_req's for the current request may be in flight, so it's difficult to tell where blk_rq_pos(req) currently is. Add ubd->rq_pos to keep track of the issue position and use it to correctly restart io_req issue. Signed-off-by: Tejun Heo Reported-by: Richard Weinberger Tested-by: Richard Weinberger Tested-by: Chris Frey Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit 93f824020d94486df855f60ebdb0b0abae67547e Author: Thomas Gleixner Date: Tue Sep 28 20:57:19 2010 +0200 x86, irq: Plug memory leak in sparse irq commit 1cf180c94e9166cda083ff65333883ab3648e852 upstream. free_irq_cfg() is not freeing the cpumask_vars in irq_cfg. Fixing this triggers a use after free caused by the fact that copying struct irq_cfg is done with memcpy, which copies the pointer not the cpumask. Fix both places. Signed-off-by: Thomas Gleixner Cc: Yinghai Lu LKML-Reference: Signed-off-by: Thomas Gleixner Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit fe33925def4a525302acb8fda2fdd85fd6ef9329 Author: Thomas Gleixner Date: Tue Sep 28 23:20:23 2010 +0200 x86, hpet: Fix bogus error check in hpet_assign_irq() commit 021989622810b02aab4b24f91e1f5ada2b654579 upstream. create_irq() returns -1 if the interrupt allocation failed, but the code checks for irq == 0. Use create_irq_nr() instead. Signed-off-by: Thomas Gleixner Cc: Venkatesh Pallipadi LKML-Reference: Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit a182c5219f8ab1fffd3947b57999f10f8852ca2b Author: Kenneth Waters Date: Tue Sep 21 00:58:23 2010 -0700 Input: joydev - fix JSIOCSAXMAP ioctl commit d2520a426dc3033c00077e923a553fc6c98c7564 upstream. Fixed JSIOCSAXMAP ioctl to update absmap, the map from hardware axis to event axis in addition to abspam. This fixes a regression introduced by 999b874f. Signed-off-by: Kenneth Waters Signed-off-by: Dmitry Torokhov Signed-off-by: Paul Gortmaker commit 3f5d42c68a0fa5c4ce63fa66fdaa98c2bdab0192 Author: Mauro Carvalho Chehab Date: Sat Sep 11 11:37:51 2010 -0300 V4L/DVB: cx231xx: Avoid an OOPS when card is unknown (card=0) commit c10469c637602c2385e2993d8c730cc44fd47d23 upstream. As reported by: Carlos Americo Domiciano : [ 220.033500] cx231xx v4l2 driver loaded. [ 220.033571] cx231xx #0: New device Conexant Corporation Polaris AV Capturb @ 480 Mbps (1554:5010) with 6 interfaces [ 220.033577] cx231xx #0: registering interface 0 [ 220.033591] cx231xx #0: registering interface 1 [ 220.033654] cx231xx #0: registering interface 6 [ 220.033910] cx231xx #0: Identified as Unknown CX231xx video grabber (card=0) [ 220.033946] BUG: unable to handle kernel NULL pointer dereference at (null) [ 220.033955] IP: [] cx231xx_pre_card_setup+0x5d/0xb0 [cx231xx] Thanks-to: Carlos Americo Domiciano Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Paul Gortmaker commit 3376769041fc2e51e05db869e2aab0c77e975982 Author: Linus Torvalds Date: Fri Oct 15 11:12:38 2010 -0700 v4l1: fix 32-bit compat microcode loading translation commit 3e645d6b485446c54c6745c5e2cf5c528fe4deec upstream. The compat code for the VIDIOCSMICROCODE ioctl is totally buggered. It's only used by the VIDEO_STRADIS driver, and that one is scheduled to staging and eventually removed unless somebody steps up to maintain it (at which point it should use request_firmware() rather than some magic ioctl). So we'll get rid of it eventually. But in the meantime, the compatibility ioctl code is broken, and this tries to get it to at least limp along (even if Mauro suggested just deleting it entirely, which may be the right thing to do - I don't think the compatibility translation code has ever worked unless you were very lucky). Reported-by: Kees Cook Cc: Mauro Carvalho Chehab Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 629ccc0f02ff1ce098c5dcb99e88f656b1162db9 Author: Steven Rostedt Date: Wed Sep 22 22:22:25 2010 -0400 tracing/x86: Don't use mcount in kvmclock.c commit 258af47479980d8238a04568b94a4e55aa1cb537 upstream. The guest can use the paravirt clock in kvmclock.c which is used by sched_clock(), which in turn is used by the tracing mechanism for timestamps, which leads to infinite recursion. Disable mcount/tracing for kvmclock.o. Cc: Jeremy Fitzhardinge Cc: Avi Kivity Signed-off-by: Steven Rostedt Signed-off-by: Paul Gortmaker commit 918a16fe94368e8fb0a281b00758879e31cffb17 Author: Jeremy Fitzhardinge Date: Wed Sep 22 17:07:27 2010 -0700 tracing/x86: Don't use mcount in pvclock.c commit 9ecd4e1689208afe9b059a5ce1333acb2f42c4d2 upstream. When using a paravirt clock, pvclock.c can be used by sched_clock(), which in turn is used by the tracing mechanism for timestamps, which leads to infinite recursion. Disable mcount/tracing for pvclock.o. Signed-off-by: Jeremy Fitzhardinge LKML-Reference: <4C9A9A3F.4040201@goop.org> Signed-off-by: Steven Rostedt Signed-off-by: Paul Gortmaker commit ed2afedbe1d7dd018d4a6df84c663ed5c1c3bd21 Author: Joerg Roedel Date: Thu Sep 23 15:15:19 2010 +0200 x86/amd-iommu: Work around S3 BIOS bug commit 4c894f47bb49284008073d351c0ddaac8860864e upstream. This patch adds a workaround for an IOMMU BIOS problem to the AMD IOMMU driver. The result of the bug is that the IOMMU does not execute commands anymore when the system comes out of the S3 state resulting in system failure. The bug in the BIOS is that is does not restore certain hardware specific registers correctly. This workaround reads out the contents of these registers at boot time and restores them on resume from S3. The workaround is limited to the specific IOMMU chipset where this problem occurs. Signed-off-by: Joerg Roedel Signed-off-by: Paul Gortmaker commit 6038fae202d6c2127ca16864bf40f6739ef2e1ec Author: Joerg Roedel Date: Thu Sep 23 16:12:48 2010 +0200 x86/amd-iommu: Fix rounding-bug in __unmap_single commit 04e0463e088b41060c08c255eb0d3278a504f094 upstream. In the __unmap_single function the dma_addr is rounded down to a page boundary before the dma pages are unmapped. The address is later also used to flush the TLB entries for that mapping. But without the offset into the dma page the amount of pages to flush might be miscalculated in the TLB flushing path. This patch fixes this bug by using the original address to flush the TLB. Signed-off-by: Joerg Roedel Signed-off-by: Paul Gortmaker commit c9ce393e4a4cde0e5431d7441015ec6a5fa9f947 Author: Joerg Roedel Date: Mon Sep 20 14:33:07 2010 +0200 x86/amd-iommu: Set iommu configuration flags in enable-loop commit e9bf51971157e367aabfc111a8219db010f69cd4 upstream. This patch moves the setting of the configuration and feature flags out out the acpi table parsing path and moves it into the iommu-enable path. This is needed to reliably fix resume-from-s3. Signed-off-by: Joerg Roedel Signed-off-by: Paul Gortmaker commit 541499002e95f8f2dd370dfac887641db25f02cf Author: Marek Szyprowski Date: Thu Sep 23 16:22:05 2010 +0200 mmc: sdhci-s3c: fix NULL ptr access in sdhci_s3c_remove commit 9320f7cbbdd5febf013b0e91db29189724057738 upstream. If not all clocks have been defined in platform data, the driver will cause a null pointer dereference when it is removed. This patch fixes this issue. Signed-off-by: Marek Szyprowski Signed-off-by: Kyungmin Park Signed-off-by: Andrew Morton Signed-off-by: Chris Ball Signed-off-by: Paul Gortmaker commit 330dc1be8569f7eb671779928a876002bf69cade Author: Steve Wise Date: Sat Sep 18 19:38:21 2010 -0500 RDMA/cxgb3: Turn off RX coalescing for iWARP connections commit bec658ff31453a5726b1c188674d587a5d40c482 upstream. The HW by default has RX coalescing on. For iWARP connections, this causes a 100ms delay in connection establishement due to the ingress MPA Start message being stalled in HW. So explicitly turn RX coalescing off when setting up iWARP connections. This was causing very bad performance for NP64 gather operations using Open MPI, due to the way it sets up connections on larger jobs. Signed-off-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Paul Gortmaker commit 74d69c7cb14633a3fdb087526a257305fb2398c3 Author: Jiri Olsa Date: Tue Sep 21 03:26:35 2010 -0400 oprofile: Add Support for Intel CPU Family 6 / Model 29 commit bb7ab785ad05a97a2c9ffb3a06547ed39f3133e8 upstream. This patch adds CPU type detection for dunnington processor (Family 6 / Model 29) to be identified as core 2 family cpu type (wikipedia source). I tested oprofile on Intel(R) Xeon(R) CPU E7440 reporting itself as model 29, and it runs without an issue. Spec: http://www.intel.com/Assets/en_US/PDF/specupdate/320336.pdf Signed-off-by: Jiri Olsa Acked-by: Andi Kleen Signed-off-by: Robert Richter Signed-off-by: Paul Gortmaker commit f01140f4a52dd75cf01f7fc1b9fcd6ef5cf2bf1a Author: Sergei Shtylyov Date: Sat Sep 11 13:23:12 2010 -0500 usb: musb: gadget: restart request on clearing endpoint halt commit a666e3e6098a9f56310e4ec2705f1dad124a34b5 upstream. Commit 46034dca515bc4ddca0399ae58106d1f5f0d809f (USB: musb_gadget_ep0: stop abusing musb_gadget_set_halt()) forgot to restart a queued request after clearing the endpoint halt feature. This results in a couple of USB resets while enumerating the file-backed storage gadget due to CSW packet not being sent for the MODE SENSE(10) command. Signed-off-by: Sergei Shtylyov Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 571484df1e1aa424749e418ca1428a7411f4e9eb Author: Ming Lei Date: Mon Sep 20 10:32:01 2010 +0300 usb: musb: gadget: fix kernel panic if using out ep with FIFO_TXRX style commit bd2e74d657fc7d514881cc2117e323790b257914 upstream. For shared fifo hw endpoint(with FIFO_TXRX style), only ep_in field of musb_hw_ep is intialized in musb_g_init_endpoints, and ep_out is not initialized, but musb_g_rx and rxstate may access ep_out field of musb_hw_ep by the method below: musb_ep = &musb->endpoints[epnum].ep_out which can cause the kernel panic[1] below, this patch fixes the issue by getting 'musb_ep' from '&musb->endpoints[epnum].ep_in' for shared fifo endpoint. [1], kernel panic [root@OMAP3EVM /]# musb_interrupt 1583: ** IRQ peripheral usb0008 tx0000 rx4000 musb_stage0_irq 460: <== Power=f0, DevCtl=99, int_usb=0x8 musb_g_rx 772: <== (null), rxcsr 4007 ffffffe8 musb_g_rx 786: iso overrun on ffffffe8 Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = c0004000 [00000008] *pgd=00000000 Internal error: Oops: 17 [#1] PREEMPT last sysfs file: /sys/devices/platform/musb_hdrc/usb1/usb_device/usbdev1.1/dev Modules linked in: g_zero CPU: 0 Tainted: G W (2.6.35-rc6-gkh-wl+ #92) PC is at musb_g_rx+0xfc/0x2ec LR is at vprintk+0x3f4/0x458 pc : [] lr : [] psr: 20000193 sp : c760bd78 ip : c03c9d70 fp : c760bdbc r10: 00000000 r9 : fa0ab1e0 r8 : 0000000e r7 : c7e80158 r6 : ffffffe8 r5 : 00000001 r4 : 00004003 r3 : 00010003 r2 : c760bcd8 r1 : c03cd030 r0 : 0000002e Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8778c019 DAC: 00000017 Process kmemleak (pid: 421, stack limit = 0xc760a2e8) Stack: (0xc760bd78 to 0xc760c000) bd60: ffffffe8 c04b1b58 bd80: ffffffe8 c7c01ac0 00000000 c7e80d24 c0084238 00000001 00000001 c7e80158 bda0: 0000000e 00000008 00000099 000000f0 c760be04 c760bdc0 c02bcd68 c02c06b4 bdc0: 00000099 00000008 00004000 c760bdd8 c03cc4f8 00000000 00000002 c7e80158 bde0: c7d2e300 60000193 c760a000 0000005c 00000000 00000000 c760be24 c760be08 be00: c02bcecc c02bc1ac c7d2e300 c7d2e300 0000005c c760a000 c760be54 c760be28 be20: c00ad698 c02bce6c 00000000 c7d2e300 c067c258 0000005c c067c294 00000001 be40: c760a000 00000000 c760be74 c760be58 c00af984 c00ad5fc 0000005c 00000000 be60: 00000000 00000002 c760be8c c760be78 c0039080 c00af8d0 ffffffff fa200000 be80: c760beec c760be90 c0039b6c c003900c 00000001 00000000 c7d1e240 00000000 bea0: 00000000 c068bae8 00000000 60000013 00000001 00000000 00000000 c760beec bec0: c0064ecc c760bed8 c00ff7d0 c003a0a8 60000013 ffffffff 00000000 c068bae8 bee0: c760bf24 c760bef0 c00ff7d0 c0064ec4 00000001 00000000 c00ff700 00000000 bf00: c0087f00 00000000 60000013 c0d76a70 c0e23795 00000001 c760bf4c c760bf28 bf20: c00ffdd8 c00ff70c c068bb08 c068bae8 60000013 c0100938 c068bb30 00000000 bf40: c760bf84 c760bf50 c010014c c00ffd84 00000001 00000000 c010000c 00012c00 bf60: c7c33f04 00012c00 c7c33f04 00000000 c0100938 00000000 c760bf9c c760bf88 bf80: c01009a8 c0100018 c760bfa8 c7c33f04 c760bff4 c760bfa0 c0088000 c0100944 bfa0: c760bf98 00000000 00000000 00000001 dead4ead ffffffff ffffffff c08ba2bc bfc0: 00000000 c049e7fa 00000000 c0087f70 c760bfd0 c760bfd0 c7c33f04 c0087f70 bfe0: c006f5e8 00000013 00000000 c760bff8 c006f5e8 c0087f7c 7f0004ff df2000ff Backtrace: [] (musb_g_rx+0x0/0x2ec) from [] (musb_interrupt+0xbc8/0xcc0) [] (musb_interrupt+0x0/0xcc0) from [] (generic_interrupt+0x6c/0x84) [] (generic_interrupt+0x0/0x84) from [] (handle_IRQ_event+0xa8/0x1ec) r7:c760a000 r6:0000005c r5:c7d2e300 r4:c7d2e300 [] (handle_IRQ_event+0x0/0x1ec) from [] (handle_level_irq+0xc0/0x13c) [] (handle_level_irq+0x0/0x13c) from [] (asm_do_IRQ+0x80/0xa0) r7:00000002 r6:00000000 r5:00000000 r4:0000005c [] (asm_do_IRQ+0x0/0xa0) from [] (__irq_svc+0x4c/0xb4) Exception stack(0xc760be90 to 0xc760bed8) be80: 00000001 00000000 c7d1e240 00000000 bea0: 00000000 c068bae8 00000000 60000013 00000001 00000000 00000000 c760beec bec0: c0064ecc c760bed8 c00ff7d0 c003a0a8 60000013 ffffffff r5:fa200000 r4:ffffffff [] (sub_preempt_count+0x0/0x100) from [] (find_and_get_object+0xd0/0x110) r5:c068bae8 r4:00000000 [] (find_and_get_object+0x0/0x110) from [] (scan_block+0x60/0x104) r8:00000001 r7:c0e23795 r6:c0d76a70 r5:60000013 r4:00000000 [] (scan_block+0x0/0x104) from [] (kmemleak_scan+0x140/0x484) [] (kmemleak_scan+0x0/0x484) from [] (kmemleak_scan_thread+0x70/0xcc) r8:00000000 r7:c0100938 r6:00000000 r5:c7c33f04 r4:00012c00 [] (kmemleak_scan_thread+0x0/0xcc) from [] (kthread+0x90/0x98) r5:c7c33f04 r4:c760bfa8 [] (kthread+0x0/0x98) from [] (do_exit+0x0/0x684) r7:00000013 r6:c006f5e8 r5:c0087f70 r4:c7c33f04 Code: e3002312 e58d6000 e2833e16 eb0422d5 (e5963020) ---[ end trace f3d5e96f75c297b7 ]--- Signed-off-by: Ming Lei Reviewed-by: Sergei Shtylyov Cc: David Brownell Cc: Anand Gadiyar Cc: Mike Frysinger Cc: Sergei Shtylyov Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 0ae4cdf56fa6b9fb2c98083e54f77a19ca4717f4 Author: Alan Stern Date: Tue Sep 21 15:01:53 2010 -0400 USB: fix bug in initialization of interface minor numbers commit 0026e00523a85b90a92a93ddf6660939ecef3e54 upstream. Recent changes in the usbhid layer exposed a bug in usbcore. If CONFIG_USB_DYNAMIC_MINORS is enabled then an interface may be assigned a minor number of 0. However interfaces that aren't registered as USB class devices also have their minor number set to 0, during initialization. As a result usb_find_interface() may return the wrong interface, leading to a crash. This patch (as1418) fixes the problem by initializing every interface's minor number to -1. It also cleans up the usb_register_dev() function, which besides being somewhat awkwardly written, does not unwind completely on all its error paths. Signed-off-by: Alan Stern Tested-by: Philip J. Turmel Tested-by: Gabriel Craciunescu Tested-by: Alex Riesen Tested-by: Matthias Bayer CC: Jiri Kosina Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 777e779591d10f4908361a439f4822aa0143470b Author: Clemens Ladisch Date: Fri Oct 15 12:06:18 2010 +0200 ALSA: rawmidi: fix oops (use after free) when unloading a driver module commit aa73aec6c385e2c797ac25cc7ccf0318031de7c8 upstream. When a driver module is unloaded and the last still open file is a raw MIDI device, the card and its devices will be actually freed in the snd_card_file_remove() call when that file is closed. Afterwards, rmidi and rmidi->card point into freed memory, so the module pointer is likely to be garbage. (This was introduced by commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a.) Signed-off-by: Clemens Ladisch Reported-by: Krzysztof Foltman Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit be6ccb1263467bc1ff2f56de2d5db5288cc9c36d Author: Dan Rosenberg Date: Tue Sep 28 14:18:20 2010 -0400 ALSA: prevent heap corruption in snd_ctl_new() commit 5591bf07225523600450edd9e6ad258bb877b779 upstream. The snd_ctl_new() function in sound/core/control.c allocates space for a snd_kcontrol struct by performing arithmetic operations on a user-provided size without checking for integer overflow. If a user provides a large enough size, an overflow will occur, the allocated chunk will be too small, and a second user-influenced value will be written repeatedly past the bounds of this chunk. This code is reachable by unprivileged users who have permission to open a /dev/snd/controlC* device (on many distros, this is group "audio") via the SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE ioctls. Signed-off-by: Dan Rosenberg Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit b9c721f1960327f6f85fa0ca91c3a7e01f9ab881 Author: Luke Yelavich Date: Tue Sep 21 17:05:46 2010 +1000 ALSA: hda - Add Dell Latitude E6400 model quirk commit 0f9f1ee9d1412d45a22bfd69dfd4d4324b506e9e upstream. BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/643891 Set the Dell Latitude E6400 (1028:0233) SSID to use AD1984_DELL_DESKTOP Signed-off-by: Luke Yelavich Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit b9aaebcc93fca9e89ef2671242b0de78c9da052b Author: Erik J. Staab Date: Wed Sep 22 11:07:41 2010 +0200 ALSA: oxygen: fix analog capture on Claro halo cards commit 0873a5ae747847ee55a63db409dff3476e45bcd9 upstream. On the HT-Omega Claro halo card, the ADC data must be captured from the second I2S input. Using the default first input, which isn't connected to anything, would result in silence. Signed-off-by: Erik J. Staab Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit a3b65e83f5ced1ec0efc28768c8acc30a02dfcb0 Author: Dan Rosenberg Date: Sat Sep 25 11:07:27 2010 -0400 ALSA: sound/pci/rme9652: prevent reading uninitialized stack memory commit e68d3b316ab7b02a074edc4f770e6a746390cb7d upstream. The SNDRV_HDSP_IOCTL_GET_CONFIG_INFO and SNDRV_HDSP_IOCTL_GET_CONFIG_INFO ioctls in hdspm.c and hdsp.c allow unprivileged users to read uninitialized kernel stack memory, because several fields of the hdsp{m}_config_info structs declared on the stack are 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: Takashi Iwai Signed-off-by: Paul Gortmaker commit 7ce01ddd26f64995f3da292187c41eaa81b00993 Author: H. Peter Anvin Date: Tue Sep 28 15:35:01 2010 -0700 x86, cpu: After uncapping CPUID, re-run CPU feature detection commit d900329e20f4476db6461752accebcf7935a8055 upstream. After uncapping the CPUID level, we need to also re-run the CPU feature detection code. This resolves kernel bugzilla 16322. Reported-by: boris64 LKML-Reference: Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit d8c3f70eafb7972e144644259f69f819fff1373e Author: Michael Cree Date: Wed Sep 1 11:25:17 2010 -0400 alpha: Fix printk format errors commit 3e073367a57d41e506f20aebb98e308387ce3090 upstream. When compiling alpha generic build get errors such as: arch/alpha/kernel/err_marvel.c: In function ‘marvel_print_err_cyc’: arch/alpha/kernel/err_marvel.c:119: error: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘u64’ Replaced a number of %ld format specifiers with %lld since u64 is unsigned long long. Signed-off-by: Michael Cree Signed-off-by: Matt Turner Signed-off-by: Paul Gortmaker commit d62dadba708a48105dac8d5bffe0897c6386b5f6 Author: Ben Hutchings Date: Wed Mar 24 03:33:48 2010 +0000 sis-agp: Remove SIS 760, handled by amd64-agp commit d831692a1a8e9ceaaa9bb16bb3fc503b7e372558 upstream. SIS 760 is listed in the device tables for both amd64-agp and sis-agp. amd64-agp is apparently preferable since it has workarounds for some BIOS misconfigurations that sis-agp doesn't handle. Signed-off-by: Ben Hutchings Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit e66ba5344fbae728693874c162220b975e46ad65 Author: Ben Hutchings Date: Sun Jun 13 22:22:59 2010 +0100 MIPS: Set io_map_base for several PCI bridges lacking it commit 8faf2e6c201d95b780cd3b4674b7a55ede6dcbbb upstream. Several MIPS platforms don't set pci_controller::io_map_base for their PCI bridges. This results in a panic in pci_iomap(). (The panic is conditional on CONFIG_PCI_DOMAINS, but that is now enabled for all PCI MIPS systems.) Signed-off-by: Ben Hutchings Cc: linux-mips@linux-mips.org Cc: Martin Michlmayr Cc: Aurelien Jarno Cc: 584784@bugs.debian.org Patchwork: https://patchwork.linux-mips.org/patch/1377/ Signed-off-by: Ralf Baechle Signed-off-by: Paul Gortmaker commit 816ea92c651693f9a3ff9b534a2b0255d959f139 Author: David Daney Date: Thu Jul 22 11:59:27 2010 -0700 MIPS: Quit using undefined behavior of ADDU in 64-bit atomic operations. commit f2a68272d799bf4092443357142f63b74f7669a1 upstream. For 64-bit, we must use DADDU and DSUBU. Signed-off-by: David Daney To: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/1483/ Signed-off-by: Ralf Baechle Signed-off-by: Paul Gortmaker commit 0910346dcc0926fc5b001e344c7f80443944e633 Author: Eric Paris Date: Wed Jul 28 10:18:37 2010 -0400 inotify: fix inotify oneshot support commit ff311008ab8d2f2cfdbbefd407d1b05acc8164b2 upstream. During the large inotify rewrite to fsnotify I completely dropped support for IN_ONESHOT. Reimplement that support. Signed-off-by: Eric Paris Signed-off-by: Paul Gortmaker commit 37362266b0afa8746c45023f482ee18cf0055321 Author: John W. Linville Date: Tue Jul 13 14:06:32 2010 -0400 hostap_pci: set dev->base_addr during probe commit 0f4da2d77e1bf424ac36424081afc22cbfc3ff2b upstream. "hostap: Protect against initialization interrupt" (which reinstated "wireless: hostap, fix oops due to early probing interrupt") reintroduced Bug 16111. This is because hostap_pci wasn't setting dev->base_addr, which is now checked in prism2_interrupt. As a result, initialization was failing for PCI-based hostap devices. This corrects that oversight. Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit c8f7a02386859e42e02d10f05f8c641bb165d373 Author: Peter Oberparleiter Date: Mon Jul 19 09:22:35 2010 +0200 dasd: use correct label location for diag fba disks commit cffab6bc5511cd6f67a60bf16b62de4267b68c4c upstream. Partition boundary calculation fails for DASD FBA disks under the following conditions: - disk is formatted with CMS FORMAT with a blocksize of more than 512 bytes - all of the disk is reserved to a single CMS file using CMS RESERVE - the disk is accessed using the DIAG mode of the DASD driver Under these circumstances, the partition detection code tries to read the CMS label block containing partition-relevant information from logical block offset 1, while it is in fact located at physical block offset 1. Fix this problem by using the correct CMS label block location depending on the device type as determined by the DASD SENSE ID information. Signed-off-by: Peter Oberparleiter Signed-off-by: Martin Schwidefsky Signed-off-by: Paul Gortmaker commit 00a0f4383a9f15cec62905e25b97c4e76c001fb8 Author: Vlad Yasevich Date: Wed Sep 15 10:00:26 2010 -0400 sctp: Do not reset the packet during sctp_packet_config(). commit 4bdab43323b459900578b200a4b8cf9713ac8fab upstream. sctp_packet_config() is called when getting the packet ready for appending of chunks. The function should not touch the current state, since it's possible to ping-pong between two transports when sending, and that can result packet corruption followed by skb overlfow crash. Reported-by: Thomas Dreibholz Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 2d214359f9aeff412379b1bb181ea2fb52e12b41 Author: Daniel J Blueman Date: Tue Aug 17 23:56:55 2010 +0100 Fix unprotected access to task credentials in waitid() commit f362b73244fb16ea4ae127ced1467dd8adaa7733 upstream. Using a program like the following: #include #include #include #include int main() { id_t id; siginfo_t infop; pid_t res; id = fork(); if (id == 0) { sleep(1); exit(0); } kill(id, SIGSTOP); alarm(1); waitid(P_PID, id, &infop, WCONTINUED); return 0; } to call waitid() on a stopped process results in access to the child task's credentials without the RCU read lock being held - which may be replaced in the meantime - eliciting the following warning: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- kernel/exit.c:1460 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by waitid02/22252: #0: (tasklist_lock){.?.?..}, at: [] do_wait+0xc5/0x310 #1: (&(&sighand->siglock)->rlock){-.-...}, at: [] wait_consider_task+0x19a/0xbe0 stack backtrace: Pid: 22252, comm: waitid02 Not tainted 2.6.35-323cd+ #3 Call Trace: [] lockdep_rcu_dereference+0xa4/0xc0 [] wait_consider_task+0xaf1/0xbe0 [] do_wait+0xf5/0x310 [] sys_waitid+0x86/0x1f0 [] ? child_wait_callback+0x0/0x70 [] system_call_fastpath+0x16/0x1b This is fixed by holding the RCU read lock in wait_task_continued() to ensure that the task's current credentials aren't destroyed between us reading the cred pointer and us reading the UID from those credentials. Furthermore, protect wait_task_stopped() in the same way. We don't need to keep holding the RCU read lock once we've read the UID from the credentials as holding the RCU read lock doesn't stop the target task from changing its creds under us - so the credentials may be outdated immediately after we've read the pointer, lock or no lock. Signed-off-by: Daniel J Blueman Signed-off-by: David Howells Acked-by: Paul E. McKenney Acked-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit f9021e856b8d844bcc5efc1f596528afed35bf89 Author: Luck, Tony Date: Tue Aug 24 11:44:18 2010 -0700 guard page for stacks that grow upwards commit 8ca3eb08097f6839b2206e2242db4179aee3cfb3 upstream. pa-risc and ia64 have stacks that grow upwards. Check that they do not run into other mappings. By making VM_GROWSUP 0x0 on architectures that do not ever use it, we can avoid some unpleasant #ifdefs in check_stack_guard_page(). Signed-off-by: Tony Luck Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 748fde1a8832e0d9312e87051b27464dba278933 Author: Mel Gorman Date: Thu Sep 9 16:38:16 2010 -0700 mm: page allocator: update free page counters after pages are placed on the free list commit 72853e2991a2702ae93aaf889ac7db743a415dd3 upstream. When allocating a page, the system uses NR_FREE_PAGES counters to determine if watermarks would remain intact after the allocation was made. This check is made without interrupts disabled or the zone lock held and so is race-prone by nature. Unfortunately, when pages are being freed in batch, the counters are updated before the pages are added on the list. During this window, the counters are misleading as the pages do not exist yet. When under significant pressure on systems with large numbers of CPUs, it's possible for processes to make progress even though they should have been stalled. This is particularly problematic if a number of the processes are using GFP_ATOMIC as the min watermark can be accidentally breached and in extreme cases, the system can livelock. This patch updates the counters after the pages have been added to the list. This makes the allocator more cautious with respect to preserving the watermarks and mitigates livelock possibilities. [akpm@linux-foundation.org: avoid modifying incoming args] Signed-off-by: Mel Gorman Reviewed-by: Rik van Riel Reviewed-by: Minchan Kim Reviewed-by: KAMEZAWA Hiroyuki Reviewed-by: Christoph Lameter Reviewed-by: KOSAKI Motohiro Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit fb46c31ab6bca5f8c084f28ca4c38cc798ca13b2 Author: Christoph Lameter Date: Thu Sep 9 16:38:17 2010 -0700 mm: page allocator: calculate a better estimate of NR_FREE_PAGES when memory is low and kswapd is awake commit aa45484031ddee09b06350ab8528bfe5b2c76d1c upstream. Ordinarily watermark checks are based on the vmstat NR_FREE_PAGES as it is cheaper than scanning a number of lists. To avoid synchronization overhead, counter deltas are maintained on a per-cpu basis and drained both periodically and when the delta is above a threshold. On large CPU systems, the difference between the estimated and real value of NR_FREE_PAGES can be very high. If NR_FREE_PAGES is much higher than number of real free page in buddy, the VM can allocate pages below min watermark, at worst reducing the real number of pages to zero. Even if the OOM killer kills some victim for freeing memory, it may not free memory if the exit path requires a new page resulting in livelock. This patch introduces a zone_page_state_snapshot() function (courtesy of Christoph) that takes a slightly more accurate view of an arbitrary vmstat counter. It is used to read NR_FREE_PAGES while kswapd is awake to avoid the watermark being accidentally broken. The estimate is not perfect and may result in cache line bounces but is expected to be lighter than the IPI calls necessary to continually drain the per-cpu counters while kswapd is awake. Signed-off-by: Christoph Lameter Signed-off-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 1c2f8bd89371100ea3a64a1fa8f807061660b492 Author: Mel Gorman Date: Thu Sep 9 16:38:18 2010 -0700 mm: page allocator: drain per-cpu lists after direct reclaim allocation fails commit 9ee493ce0a60bf42c0f8fd0b0fe91df5704a1cbf upstream. When under significant memory pressure, a process enters direct reclaim and immediately afterwards tries to allocate a page. If it fails and no further progress is made, it's possible the system will go OOM. However, on systems with large amounts of memory, it's possible that a significant number of pages are on per-cpu lists and inaccessible to the calling process. This leads to a process entering direct reclaim more often than it should increasing the pressure on the system and compounding the problem. This patch notes that if direct reclaim is making progress but allocations are still failing that the system is already under heavy pressure. In this case, it drains the per-cpu lists and tries the allocation a second time before continuing. Signed-off-by: Mel Gorman Reviewed-by: Minchan Kim Reviewed-by: KAMEZAWA Hiroyuki Reviewed-by: KOSAKI Motohiro Reviewed-by: Christoph Lameter Cc: Dave Chinner Cc: Wu Fengguang Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 2ce81e08cc9de71e118b401bd5535fc260157193 Author: Nicolas Ferre Date: Fri Aug 20 16:44:33 2010 +0200 AT91: change dma resource index commit 8d2602e0778299e2d6084f03086b716d6e7a1e1e upstream. Reported-by: Dan Liang Signed-off-by: Nicolas Ferre Signed-off-by: Paul Gortmaker commit b40076f9041d97b3e436c8914f21d262cf917d43 Author: Dan Rosenberg Date: Wed Sep 15 19:08:24 2010 -0400 drivers/video/via/ioctl.c: prevent reading uninitialized stack memory commit b4aaa78f4c2f9cde2f335b14f4ca30b01f9651ca upstream. The VIAFB_GET_INFO device ioctl allows unprivileged users to read 246 bytes of uninitialized stack memory, because the "reserved" member of the viafb_ioctl_info 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: Florian Tobias Schandinat Signed-off-by: Paul Gortmaker commit 3c8d8bedf37054493323a6ae402fe538032e37a1 Author: Dan Rosenberg Date: Mon Sep 6 18:24:57 2010 -0400 xfs: prevent reading uninitialized stack memory commit a122eb2fdfd78b58c6dd992d6f4b1aaef667eef9 upstream. The XFS_IOC_FSGETXATTR ioctl allows unprivileged users to read 12 bytes of uninitialized stack memory, because the fsxattr struct declared on the stack in xfs_ioc_fsgetxattr() does not alter (or zero) the 12-byte fsx_pad member before copying it back to the user. This patch takes care of it. Signed-off-by: Dan Rosenberg Reviewed-by: Eric Sandeen Signed-off-by: Alex Elder Signed-off-by: Paul Gortmaker commit dd1644658bbefe2626a5307e90c009720bd62623 Author: David Howells Date: Fri Sep 10 09:59:51 2010 +0100 KEYS: Fix bug in keyctl_session_to_parent() if parent has no session keyring commit 3d96406c7da1ed5811ea52a3b0905f4f0e295376 upstream. Fix a bug in keyctl_session_to_parent() whereby it tries to check the ownership of the parent process's session keyring whether or not the parent has a session keyring [CVE-2010-2960]. This results in the following oops: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 IP: [] keyctl_session_to_parent+0x251/0x443 ... Call Trace: [] ? keyctl_session_to_parent+0x67/0x443 [] ? __do_fault+0x24b/0x3d0 [] sys_keyctl+0xb4/0xb8 [] system_call_fastpath+0x16/0x1b if the parent process has no session keyring. If the system is using pam_keyinit then it mostly protected against this as all processes derived from a login will have inherited the session keyring created by pam_keyinit during the log in procedure. To test this, pam_keyinit calls need to be commented out in /etc/pam.d/. Reported-by: Tavis Ormandy Signed-off-by: David Howells Acked-by: Tavis Ormandy Cc: dann frazier Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 0a92e55adab5b09f9d13e5132e2678c30d34e2f9 Author: David Howells Date: Fri Sep 10 09:59:46 2010 +0100 KEYS: Fix RCU no-lock warning in keyctl_session_to_parent() commit 9d1ac65a9698513d00e5608d93fca0c53f536c14 upstream. There's an protected access to the parent process's credentials in the middle of keyctl_session_to_parent(). This results in the following RCU warning: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by keyctl-session-/2137: #0: (tasklist_lock){.+.+..}, at: [] keyctl_session_to_parent+0x60/0x236 stack backtrace: Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1 Call Trace: [] lockdep_rcu_dereference+0xaa/0xb3 [] keyctl_session_to_parent+0xed/0x236 [] sys_keyctl+0xb4/0xb6 [] system_call_fastpath+0x16/0x1b The code should take the RCU read lock to make sure the parents credentials don't go away, even though it's holding a spinlock and has IRQ disabled. Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 7020951d610434e8bb24f3c431677273921944b7 Author: Petr Tesarik Date: Wed Sep 15 15:35:48 2010 -0700 Optimize ticket spinlocks in fsys_rt_sigprocmask commit 2d2b6901649a62977452be85df53eda2412def24 upstream. Tony's fix (f574c843191728d9407b766a027f779dcd27b272) has a small bug, it incorrectly uses "r3" as a scratch register in the first of the two unlock paths ... it is also inefficient. Optimize the fast path again. Signed-off-by: Petr Tesarik Signed-off-by: Tony Luck Signed-off-by: Paul Gortmaker commit eb0f785b8ced780e22ad2cd742b3b420574e1d1d Author: Tony Luck Date: Thu Sep 9 15:16:56 2010 -0700 fix siglock commit f574c843191728d9407b766a027f779dcd27b272 upstream. When ia64 converted to using ticket locks, an inline implementation of trylock/unlock in fsys.S was missed. This was not noticed because in most circumstances it simply resulted in using the slow path because the siglock was apparently not available (under old spinlock rules). Problems occur when the ticket spinlock has value 0x0 (when first initialised, or when it wraps around). At this point the fsys.S code acquires the lock (changing the 0x0 to 0x1. If another process attempts to get the lock at this point, it will change the value from 0x1 to 0x2 (using new ticket lock rules). Then the fsys.S code will free the lock using old spinlock rules by writing 0x0 to it. From here a variety of bad things can happen. Signed-off-by: Tony Luck Signed-off-by: Paul Gortmaker commit 47ffb4116368cdb4c9225611725e5182dfcb4dcc Author: Dmitry Monakhov Date: Sat Jun 5 11:51:27 2010 -0400 ext4: Fix remaining racy updates of EXT4_I(inode)->i_flags commit 84a8dce2710cc425089a2b92acc354d4fbb5788d upstream. A few functions were still modifying i_flags in a racy manner. Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 2e4261d3a0ad1281d33bd08a128293734e98baa9 Author: Ryan Kuester Date: Mon Apr 26 18:11:54 2010 -0500 mptsas: fix hangs caused by ATA pass-through commit 2a1b7e575b80ceb19ea50bfa86ce0053ea57181d upstream. I may have an explanation for the LSI 1068 HBA hangs provoked by ATA pass-through commands, in particular by smartctl. First, my version of the symptoms. On an LSI SAS1068E B3 HBA running 01.29.00.00 firmware, with SATA disks, and with smartd running, I'm seeing occasional task, bus, and host resets, some of which lead to hard faults of the HBA requiring a reboot. Abusively looping the smartctl command, # while true; do smartctl -a /dev/sdb > /dev/null; done dramatically increases the frequency of these failures to nearly one per minute. A high IO load through the HBA while looping smartctl seems to improve the chance of a full scsi host reset or a non-recoverable hang. I reduced what smartctl was doing down to a simple test case which causes the hang with a single IO when pointed at the sd interface. See the code at the bottom of this e-mail. It uses an SG_IO ioctl to issue a single pass-through ATA identify device command. If the buffer userspace gives for the read data has certain alignments, the task is issued to the HBA but the HBA fails to respond. If run against the sg interface, neither the test code nor smartctl causes a hang. sd and sg handle the SG_IO ioctl slightly differently. Unless you specifically set a flag to do direct IO, sg passes a buffer of its own, which is page-aligned, to the block layer and later copies the result into the userspace buffer regardless of its alignment. sd, on the other hand, always does direct IO unless the userspace buffer fails an alignment test at block/blk-map.c line 57, in which case a page-aligned buffer is created and used for the transfer. The alignment test currently checks for word-alignment, the default setup by scsi_lib.c; therefore, userspace buffers of almost any alignment are given directly to the HBA as DMA targets. The LSI 1068 hardware doesn't seem to like at least a couple of the alignments which cross a page boundary (see the test code below). Curiously, many page-boundary-crossing alignments do work just fine. So, either the hardware has an bug handling certain alignments or the hardware has a stricter alignment requirement than the driver is advertising. If stricter alignment is required, then in no case should misaligned buffers from userspace be allowed through without being bounced or at least causing an error to be returned. It seems the mptsas driver could use blk_queue_dma_alignment() to advertise a stricter alignment requirement. If it does, sd does the right thing and bounces misaligned buffers (see block/blk-map.c line 57). The following patch to 2.6.34-rc5 makes my symptoms go away. I'm sure this is the wrong place for this code, but it gets my idea across. Acked-by: "Desai, Kashyap" Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit ca7db91d8e01f54e0ff0f62fb5d9fc5f1402bee7 Author: Eric Paris Date: Wed Jul 28 10:18:37 2010 -0400 inotify: send IN_UNMOUNT events commit 611da04f7a31b2208e838be55a42c7a1310ae321 upstream. Since the .31 or so notify rewrite inotify has not sent events about inodes which are unmounted. This patch restores those events. Signed-off-by: Eric Paris Signed-off-by: Paul Gortmaker commit 6309b565e9c663915d9a6d50c0bf17cefd6d13b0 Author: Jeff Moyer Date: Fri Sep 10 14:16:00 2010 -0700 aio: check for multiplication overflow in do_io_submit commit 75e1c70fc31490ef8a373ea2a4bea2524099b478 upstream. Tavis Ormandy pointed out that do_io_submit does not do proper bounds checking on the passed-in iocb array:        if (unlikely(nr < 0))                return -EINVAL;        if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(iocbpp)))))                return -EFAULT;                      ^^^^^^^^^^^^^^^^^^ The attached patch checks for overflow, and if it is detected, the number of iocbs submitted is scaled down to a number that will fit in the long.  This is an ok thing to do, as sys_io_submit is documented as returning the number of iocbs submitted, so callers should handle a return value of less than the 'nr' argument passed in. Reported-by: Tavis Ormandy Signed-off-by: Jeff Moyer Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit f53de2a66c091ac0dd4a8a5fa87b149c4660a37a Author: Tejun Heo Date: Tue Sep 21 07:57:19 2010 +0200 percpu: fix pcpu_last_unit_cpu commit 46b30ea9bc3698bc1d1e6fd726c9601d46fa0a91 upstream. pcpu_first/last_unit_cpu are used to track which cpu has the first and last units assigned. This in turn is used to determine the span of a chunk for man/unmap cache flushes and whether an address belongs to the first chunk or not in per_cpu_ptr_to_phys(). When the number of possible CPUs isn't power of two, a chunk may contain unassigned units towards the end of a chunk. The logic to determine pcpu_last_unit_cpu was incorrect when there was an unused unit at the end of a chunk. It failed to ignore the unused unit and assigned the unused marker NR_CPUS to pcpu_last_unit_cpu. This was discovered through kdump failure which was caused by malfunctioning per_cpu_ptr_to_phys() on a kvm setup with 50 possible CPUs by CAI Qian. Signed-off-by: Tejun Heo Reported-by: CAI Qian Signed-off-by: Paul Gortmaker commit 58e825b94f87f5f801f306aafc2bf47867c069c0 Author: Dan Rosenberg Date: Wed Sep 22 13:05:09 2010 -0700 drivers/video/sis/sis_main.c: prevent reading uninitialized stack memory commit fd02db9de73faebc51240619c7c7f99bee9f65c7 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 Cc: Thomas Winischhofer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 877c7c650a9c4bf3e453b5e79a93880d1af375d4 Author: Andrew Morton Date: Wed Sep 22 13:05:11 2010 -0700 drivers/pci/intel-iommu.c: fix build with older gcc's commit df08cdc7ef606509debe7677c439be0ca48790e4 upstream. drivers/pci/intel-iommu.c: In function `__iommu_calculate_agaw': drivers/pci/intel-iommu.c:437: sorry, unimplemented: inlining failed in call to 'width_to_agaw': function body not available drivers/pci/intel-iommu.c:445: sorry, unimplemented: called from here Move the offending function (and its siblings) to top-of-file, remove the forward declaration. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=17441 Reported-by: Martin Mokrejs Cc: David Woodhouse Cc: Jesse Barnes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit c97442183f1dc5f94dd714c28a2ec64ea548f0ad Author: Jan Kara Date: Tue Sep 21 11:49:01 2010 +0200 char: Mark /dev/zero and /dev/kmem as not capable of writeback commit 371d217ee1ff8b418b8f73fb2a34990f951ec2d4 upstream. These devices don't do any writeback but their device inodes still can get dirty so mark bdi appropriately so that bdi code does the right thing and files inodes to lists of bdi carrying the device inodes. Signed-off-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit a13068d2ef7d7060a1d71c979a485e7ee63c01f2 Author: Patrick Simmons Date: Wed Sep 8 10:34:28 2010 -0400 oprofile: Add Support for Intel CPU Family 6 / Model 22 (Intel Celeron 540) commit c33f543d320843e1732534c3931da4bbd18e6c14 upstream. This patch adds CPU type detection for the Intel Celeron 540, which is part of the Core 2 family according to Wikipedia; the family and ID pair is absent from the Volume 3B table referenced in the source code comments. I have tested this patch on an Intel Celeron 540 machine reporting itself as Family 6 Model 22, and OProfile runs on the machine without issue. Spec: http://download.intel.com/design/mobile/SPECUPDT/317667.pdf Signed-off-by: Patrick Simmons Acked-by: Andi Kleen Acked-by: Arnd Bergmann Signed-off-by: Robert Richter Signed-off-by: Paul Gortmaker commit a1ec005ae55ca04896388df88a3763903be2bd9c Author: Stanislaw Gruszka Date: Tue Sep 14 16:35:14 2010 +0200 sched: Fix user time incorrectly accounted as system time on 32-bit commit e75e863dd5c7d96b91ebbd241da5328fc38a78cc upstream. We have 32-bit variable overflow possibility when multiply in task_times() and thread_group_times() functions. When the overflow happens then the scaled utime value becomes erroneously small and the scaled stime becomes i erroneously big. Reported here: https://bugzilla.redhat.com/show_bug.cgi?id=633037 https://bugzilla.kernel.org/show_bug.cgi?id=16559 Reported-by: Michael Chapman Reported-by: Ciriaco Garcia de Celis Signed-off-by: Stanislaw Gruszka Signed-off-by: Peter Zijlstra Cc: Hidetoshi Seto LKML-Reference: <20100914143513.GB8415@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 29562d83a2d8d0bbe5ffb0d976c6c73d5a269853 Author: Paul E. McKenney Date: Tue Aug 31 17:00:18 2010 -0700 pid: make setpgid() system call use RCU read-side critical section commit 950eaaca681c44aab87a46225c9e44f902c080aa upstream. [ 23.584719] [ 23.584720] =================================================== [ 23.585059] [ INFO: suspicious rcu_dereference_check() usage. ] [ 23.585176] --------------------------------------------------- [ 23.585176] kernel/pid.c:419 invoked rcu_dereference_check() without protection! [ 23.585176] [ 23.585176] other info that might help us debug this: [ 23.585176] [ 23.585176] [ 23.585176] rcu_scheduler_active = 1, debug_locks = 1 [ 23.585176] 1 lock held by rc.sysinit/728: [ 23.585176] #0: (tasklist_lock){.+.+..}, at: [] sys_setpgid+0x5f/0x193 [ 23.585176] [ 23.585176] stack backtrace: [ 23.585176] Pid: 728, comm: rc.sysinit Not tainted 2.6.36-rc2 #2 [ 23.585176] Call Trace: [ 23.585176] [] lockdep_rcu_dereference+0x99/0xa2 [ 23.585176] [] find_task_by_pid_ns+0x50/0x6a [ 23.585176] [] find_task_by_vpid+0x1d/0x1f [ 23.585176] [] sys_setpgid+0x67/0x193 [ 23.585176] [] system_call_fastpath+0x16/0x1b [ 24.959669] type=1400 audit(1282938522.956:4): avc: denied { module_request } for pid=766 comm="hwclock" kmod="char-major-10-135" scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclas It turns out that the setpgid() system call fails to enter an RCU read-side critical section before doing a PID-to-task_struct translation. This commit therefore does rcu_read_lock() before the translation, and also does rcu_read_unlock() after the last use of the returned pointer. Reported-by: Andrew Morton Signed-off-by: Paul E. McKenney Acked-by: David Howells Signed-off-by: Paul Gortmaker commit 63b722fac15fc2f9e5846b64a484dd14b0c475c9 Author: Dan Carpenter Date: Fri Sep 10 01:56:16 2010 +0000 net/llc: make opt unsigned in llc_ui_setsockopt() commit 339db11b219f36cf7da61b390992d95bb6b7ba2e upstream. The members of struct llc_sock are unsigned so if we pass a negative value for "opt" it can cause a sign bug. Also it can cause an integer overflow when we multiply "opt * HZ". Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 18051b416cd5211d3be28821a0b2927cac54b9ba Author: Dan Carpenter Date: Mon Sep 6 14:32:30 2010 +0200 Staging: vt6655: fix buffer overflow commit dd173abfead903c7df54e977535973f3312cd307 upstream. "param->u.wpa_associate.wpa_ie_len" comes from the user. We should check it so that the copy_from_user() doesn't overflow the buffer. Also further down in the function, we assume that if "param->u.wpa_associate.wpa_ie_len" is set then "abyWPAIE[0]" is initialized. To make that work, I changed the test here to say that if "wpa_ie_len" is set then "wpa_ie" has to be a valid pointer or we return -EINVAL. Oddly, we only use the first element of the abyWPAIE[] array. So I suspect there may be some other issues in this function. Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit c54851e65ebe3033f070d03cf44fcb92b8021819 Author: Andy Gospodarek Date: Fri Sep 10 11:43:20 2010 +0000 bonding: correctly process non-linear skbs commit ab12811c89e88f2e66746790b1fe4469ccb7bdd9 upstream. It was recently brought to my attention that 802.3ad mode bonds would no longer form when using some network hardware after a driver update. After snooping around I realized that the particular hardware was using page-based skbs and found that skb->data did not contain a valid LACPDU as it was not stored there. That explained the inability to form an 802.3ad-based bond. For balance-alb mode bonds this was also an issue as ARPs would not be properly processed. This patch fixes the issue in my tests and should be applied to 2.6.36 and as far back as anyone cares to add it to stable. Thanks to Alexander Duyck and Jesse Brandeburg for the suggestions on this one. Signed-off-by: Andy Gospodarek CC: Alexander Duyck CC: Jesse Brandeburg Signed-off-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 77a8dd404ee1eee8bb5c2a9c8b83b5df2a0624d4 Author: Dan Rosenberg Date: Wed Sep 15 11:43:04 2010 +0000 drivers/net/eql.c: prevent reading uninitialized stack memory commit 44467187dc22fdd33a1a06ea0ba86ce20be3fe3c upstream. Fixed formatting (tabs and line breaks). The EQL_GETMASTRCFG device ioctl allows unprivileged users to read 16 bytes of uninitialized stack memory, because the "master_name" member of the master_config_t struct declared on the stack in eql_g_master_cfg() 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: David S. Miller Signed-off-by: Paul Gortmaker commit bbf2a842aabff85f810a1571f8598d554690877f Author: Dan Rosenberg Date: Wed Sep 15 11:43:12 2010 +0000 drivers/net/cxgb3/cxgb3_main.c: prevent reading uninitialized stack memory commit 49c37c0334a9b85d30ab3d6b5d1acb05ef2ef6de upstream. Fixed formatting (tabs and line breaks). The CHELSIO_GET_QSET_NUM device ioctl allows unprivileged users to read 4 bytes of uninitialized stack memory, because the "addr" member of the ch_reg struct declared on the stack in cxgb_extension_ioctl() 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: David S. Miller Signed-off-by: Paul Gortmaker commit 9d9d43bd83504af7fcfb473aea2751386b57a95d Author: Dan Rosenberg Date: Wed Sep 15 11:43:28 2010 +0000 drivers/net/usb/hso.c: prevent reading uninitialized memory commit 7011e660938fc44ed86319c18a5954e95a82ab3e upstream. Fixed formatting (tabs and line breaks). The TIOCGICOUNT device ioctl allows unprivileged users to read uninitialized stack memory, because the "reserved" member of the serial_icounter_struct struct declared on the stack in hso_get_count() 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: David S. Miller Signed-off-by: Paul Gortmaker commit aab976adedc431ed10bed9df11a3c69007c16ee2 Author: David S. Miller Date: Mon Aug 23 23:10:57 2010 -0700 sparc64: Get rid of indirect p1275 PROM call buffer. commit 25edd6946a1d74e5e77813c2324a0908c68bcf9e upstream. This is based upon a report by Meelis Roos showing that it's possible that we'll try to fetch a property that is 32K in size with some devices. With the current fixed 3K buffer we use for moving data in and out of the firmware during PROM calls, that simply won't work. In fact, it will scramble random kernel data during bootup. The reasoning behind the temporary buffer is entirely historical. It used to be the case that we had problems referencing dynamic kernel memory (including the stack) early in the boot process before we explicitly told the firwmare to switch us over to the kernel trap table. So what we did was always give the firmware buffers that were locked into the main kernel image. But we no longer have problems like that, so get rid of all of this indirect bounce buffering. Besides fixing Meelis's bug, this also makes the kernel data about 3K smaller. It was also discovered during these conversions that the implementation of prom_retain() was completely wrong, so that was fixed here as well. Currently that interface is not in use. Reported-by: Meelis Roos Tested-by: Meelis Roos Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 8e5b50661d8370fb7623bffb80a46396fe219d78 Author: Tetsuo Handa Date: Sat Sep 4 01:34:28 2010 +0000 UNIX: Do not loop forever at unix_autobind(). commit 8df73ff90f00f14d2c7ff7156f7ef153f7e9d3b7 upstream. We assumed that unix_autobind() never fails if kzalloc() succeeded. But unix_autobind() allows only 1048576 names. If /proc/sys/fs/file-max is larger than 1048576 (e.g. systems with more than 10GB of RAM), a local user can consume all names using fork()/socket()/bind(). If all names are in use, those who call bind() with addr_len == sizeof(short) or connect()/sendmsg() with setsockopt(SO_PASSCRED) will continue while (1) yield(); loop at unix_autobind() till a name becomes available. This patch adds a loop counter in order to give up after 1048576 attempts. Calling yield() for once per 256 attempts may not be sufficient when many names are already in use, for __unix_find_socket_byname() can take long time under such circumstance. Therefore, this patch also adds cond_resched() call. Note that currently a local user can consume 2GB of kernel memory if the user is allowed to create and autobind 1048576 UNIX domain sockets. We should consider adding some restriction for autobind operation. Signed-off-by: Tetsuo Handa Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 184dca11229af57c28619707615ba29ce1bd0111 Author: Alexey Kuznetsov Date: Wed Sep 15 10:27:52 2010 -0700 tcp: Prevent overzealous packetization by SWS logic. commit 01f83d69844d307be2aa6fea88b0e8fe5cbdb2f4 upstream. If peer uses tiny MSS (say, 75 bytes) and similarly tiny advertised window, the SWS logic will packetize to half the MSS unnecessarily. This causes problems with some embedded devices. However for large MSS devices we do want to half-MSS packetize otherwise we never get enough packets into the pipe for things like fast retransmit and recovery to work. Be careful also to handle the case where MSS > window, otherwise we'll never send until the probe timer. Reported-by: ツ Leandro Melo de Sales Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 31bf2335df157ea4f91023af12a2c148cebbf47e Author: Eric Dumazet Date: Mon Aug 16 03:25:00 2010 +0000 rds: fix a leak of kernel memory commit f037590fff3005ce8a1513858d7d44f50053cc8f upstream. struct rds_rdma_notify contains a 32 bits hole on 64bit arches, make sure it is zeroed before copying it to user. Signed-off-by: Eric Dumazet CC: Andy Grover Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit dee9314a05ba1cca3831b749c73260edfcab3c54 Author: David S. Miller Date: Wed Sep 1 18:06:39 2010 -0700 bridge: Clear INET control block of SKBs passed into ip_fragment(). commit 87f94b4e91dc042620c527f3c30c37e5127ef757 upstream. In a similar vain to commit 17762060c25590bfddd68cc1131f28ec720f405f ("bridge: Clear IPCB before possible entry into IP stack") Any time we call into the IP stack we have to make sure the state there is as expected by the ipv4 code. With help from Eric Dumazet and Herbert Xu. Reported-by: Bandan Das Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 7593862bdea935f1898a86bbe74a758776105cb7 Author: Herbert Xu Date: Mon Jul 5 21:29:28 2010 +0000 bridge: Clear IPCB before possible entry into IP stack commit 17762060c25590bfddd68cc1131f28ec720f405f upstream. The bridge protocol lives dangerously by having incestuous relations with the IP stack. In this instance an abomination has been created where a bogus IPCB area from a bridged packet leads to a crash in the IP stack because it's interpreted as IP options. This patch papers over the problem by clearing the IPCB area in that particular spot. To fix this properly we'd also need to parse any IP options if present but I'm way too lazy for that. Signed-off-by: Herbert Xu Cheers, Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit db7106a5dc4f8f77213654bc849583d73ea154eb Author: Eric Dumazet Date: Wed Aug 25 23:02:17 2010 -0700 tcp: fix three tcp sysctls tuning commit c5ed63d66f24fd4f7089b5a6e087b0ce7202aa8e upstream. As discovered by Anton Blanchard, current code to autotune tcp_death_row.sysctl_max_tw_buckets, sysctl_tcp_max_orphans and sysctl_max_syn_backlog makes little sense. The bigger a page is, the less tcp_max_orphans is : 4096 on a 512GB machine in Anton's case. (tcp_hashinfo.bhash_size * sizeof(struct inet_bind_hashbucket)) is much bigger if spinlock debugging is on. Its wrong to select bigger limits in this case (where kernel structures are also bigger) bhash_size max is 65536, and we get this value even for small machines. A better ground is to use size of ehash table, this also makes code shorter and more obvious. Based on a patch from Anton, and another from David. Reported-and-tested-by: Anton Blanchard Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit d62350df64edd6bbfd2530043044064f22def8f1 Author: David S. Miller Date: Wed Aug 25 02:27:49 2010 -0700 tcp: Combat per-cpu skew in orphan tests. commit ad1af0fedba14f82b240a03fe20eb9b2fdbd0357 upstream. As reported by Anton Blanchard when we use percpu_counter_read_positive() to make our orphan socket limit checks, the check can be off by up to num_cpus_online() * batch (which is 32 by default) which on a 128 cpu machine can be as large as the default orphan limit itself. Fix this by doing the full expensive sum check if the optimized check triggers. Reported-by: Anton Blanchard Signed-off-by: David S. Miller Acked-by: Eric Dumazet Signed-off-by: Paul Gortmaker commit 7ced1d814caff3d5a35c9af16896d4097e5e0b05 Author: KOSAKI Motohiro Date: Tue Aug 24 16:05:48 2010 +0000 tcp: select(writefds) don't hang up when a peer close connection commit d84ba638e4ba3c40023ff997aa5e8d3ed002af36 upstream. This issue come from ruby language community. Below test program hang up when only run on Linux. % uname -mrsv Linux 2.6.26-2-486 #1 Sat Dec 26 08:37:39 UTC 2009 i686 % ruby -rsocket -ve ' BasicSocket.do_not_reverse_lookup = true serv = TCPServer.open("127.0.0.1", 0) s1 = TCPSocket.open("127.0.0.1", serv.addr[1]) s2 = serv.accept s2.close s1.write("a") rescue p $! s1.write("a") rescue p $! Thread.new { s1.write("a") }.join' ruby 1.9.3dev (2010-07-06 trunk 28554) [i686-linux] # [Hang Here] FreeBSD, Solaris, Mac doesn't. because Ruby's write() method call select() internally. and tcp_poll has a bug. SUS defined 'ready for writing' of select() as following. | A descriptor shall be considered ready for writing when a call to an output | function with O_NONBLOCK clear would not block, whether or not the function | would transfer data successfully. That said, EPIPE situation is clearly one of 'ready for writing'. We don't have read-side issue because tcp_poll() already has read side shutdown care. | if (sk->sk_shutdown & RCV_SHUTDOWN) | mask |= POLLIN | POLLRDNORM | POLLRDHUP; So, Let's insert same logic in write side. - reference url http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/31065 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/31068 Signed-off-by: KOSAKI Motohiro Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 3795203b12ba68f9f14cc92cd47bb8a4ef294fa6 Author: David S. Miller Date: Mon Aug 30 18:35:24 2010 -0700 irda: Correctly clean up self->ias_obj on irda_bind() failure. commit 628e300cccaa628d8fb92aa28cb7530a3d5f2257 upstream. If irda_open_tsap() fails, the irda_bind() code tries to destroy the ->ias_obj object by hand, but does so wrongly. In particular, it fails to a) release the hashbin attached to the object and b) reset the self->ias_obj pointer to NULL. Fix both problems by using irias_delete_object() and explicitly setting self->ias_obj to NULL, just as irda_release() does. Reported-by: Tavis Ormandy Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 73c6457e9c55fa28154e187f47b300c8df00e7b2 Author: Jarek Poplawski Date: Sat Sep 4 10:34:29 2010 +0000 gro: Re-fix different skb headrooms commit 64289c8e6851bca0e589e064c9a5c9fbd6ae5dd4 upstream. The patch: "gro: fix different skb headrooms" in its part: "2) allocate a minimal skb for head of frag_list" is buggy. The copied skb has p->data set at the ip header at the moment, and skb_gro_offset is the length of ip + tcp headers. So, after the change the length of mac header is skipped. Later skb_set_mac_header() sets it into the NET_SKB_PAD area (if it's long enough) and ip header is misaligned at NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the original skb was wrongly allocated, so let's copy it as it was. bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626 fixes commit: 3d3be4333fdf6faa080947b331a6a19bce1a4f57 Reported-by: Plamen Petrov Signed-off-by: Jarek Poplawski CC: Eric Dumazet Acked-by: Eric Dumazet Tested-by: Plamen Petrov Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit ee2b5b8ff959cf98a58e68375a0c0be58027b79c Author: Eric Dumazet Date: Wed Sep 1 00:50:51 2010 +0000 gro: fix different skb headrooms commit 3d3be4333fdf6faa080947b331a6a19bce1a4f57 upstream. Packets entering GRO might have different headrooms, even for a given flow (because of implementation details in drivers, like copybreak). We cant force drivers to deliver packets with a fixed headroom. 1) fix skb_segment() skb_segment() makes the false assumption headrooms of fragments are same than the head. When CHECKSUM_PARTIAL is used, this can give csum_start errors, and crash later in skb_copy_and_csum_dev() 2) allocate a minimal skb for head of frag_list skb_gro_receive() uses netdev_alloc_skb(headroom + skb_gro_offset(p)) to allocate a fresh skb. This adds NET_SKB_PAD to a padding already provided by netdevice, depending on various things, like copybreak. Use alloc_skb() to allocate an exact padding, to reduce cache line needs: NET_SKB_PAD + NET_IP_ALIGN bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626 Many thanks to Plamen Petrov, testing many debugging patches ! With help of Jarek Poplawski. Reported-by: Plamen Petrov Signed-off-by: Eric Dumazet CC: Jarek Poplawski Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 2a3b699885d83ab285b2a8ef7ab7800f56012bd3 Author: Dan Rosenberg Date: Wed Sep 15 17:44:16 2010 -0400 USB: serial/mos*: prevent reading uninitialized stack memory commit a0846f1868b11cd827bdfeaf4527d8b1b1c0b098 upstream. The TIOCGICOUNT device ioctl in both mos7720.c and mos7840.c allows unprivileged users to read uninitialized stack memory, because the "reserved" member of the serial_icounter_struct 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: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 018402a0ef1042e1d1bbc22507dad258b5402e7c Author: Ben Hutchings Date: Thu Sep 9 05:21:16 2010 +0100 tun: Don't add sysfs attributes to devices without sysfs directories This applies to 2.6.32 *only*. It has not been applied upstream since the limitation no longer exists. Prior to Linux 2.6.35, net devices outside the initial net namespace did not have sysfs directories. Attempting to add attributes to them will trigger a BUG(). Reported-and-tested-by: Russell Stuart Signed-off-by: Ben Hutchings Acked-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 0ca77ac6d65b2d2b0495fd3a8ebdeecc657d81b8 Author: Chris Wilson Date: Thu Sep 9 09:41:32 2010 +0100 drm: Only decouple the old_fb from the crtc is we call mode_set* commit 356ad3cd616185631235ffb48b3efbf39f9923b3 upstream. Otherwise when disabling the output we switch to the new fb (which is likely NULL) and skip the call to mode_set -- leaking driver private state on the old_fb. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857 Reported-by: Sitsofe Wheeler Signed-off-by: Chris Wilson Cc: Dave Airlie Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit 6c3c1b868bbb0ba7394b87d9bc648b5551f252c8 Author: Chris Wilson Date: Mon Sep 6 16:17:22 2010 +0100 drm/i915: Prevent double dpms on commit 032d2a0d068b0368296a56469761394ef03207c3 upstream. Arguably this is a bug in drm-core in that we should not be called twice in succession with DPMS_ON, however this is still occuring and we see FDI link training failures on the second call leading to the occassional blank display. For the time being ignore the repeated call. Original patch by Dave Airlie Signed-off-by: Chris Wilson Signed-off-by: Paul Gortmaker commit 7a607ddc5d39409070adffda938ff000b8a5a23c Author: Dan Carpenter Date: Wed Jun 23 19:03:01 2010 +0200 i915: return -EFAULT if copy_to_user fails commit c877cdce93a44eea96f6cf7fc04be7d0372db2be upstream. copy_to_user() returns the number of bytes remaining to be copied and I'm pretty sure we want to return a negative error code here. Signed-off-by: Dan Carpenter Signed-off-by: Chris Wilson Signed-off-by: Paul Gortmaker commit d3591cf9bb57b98e8f41f755da94c97449913de6 Author: Dan Carpenter Date: Sat Jun 19 15:12:51 2010 +0200 i915: return -EFAULT if copy_to_user fails commit 9927a403ca8c97798129953fa9cbb5dc259c7cb9 upstream. copy_to_user returns the number of bytes remaining to be copied, but we want to return a negative error code here. These are returned to userspace. Signed-off-by: Dan Carpenter Signed-off-by: Chris Wilson Signed-off-by: Paul Gortmaker commit 2c3b8dfc23f91bfcac1bf3865a1d1bf400c23df1 Author: Trond Myklebust Date: Sun Sep 12 19:55:25 2010 -0400 SUNRPC: Fix race corrupting rpc upcall commit 5a67657a2e90c9e4a48518f95d4ba7777aa20fbb upstream. If rpc_queue_upcall() adds a new upcall to the rpci->pipe list just after rpc_pipe_release calls rpc_purge_list(), but before it calls gss_pipe_release (as rpci->ops->release_pipe(inode)), then the latter will free a message without deleting it from the rpci->pipe list. We will be left with a freed object on the rpc->pipe list. Most frequent symptoms are kernel crashes in rpc.gssd system calls on the pipe in question. Reported-by: J. Bruce Fields Signed-off-by: Trond Myklebust Signed-off-by: Paul Gortmaker commit 177c017d15828824a1e63e1beb52162a068c15bb Author: Trond Myklebust Date: Sun Sep 12 19:55:26 2010 -0400 NFS: Fix a typo in nfs_sockaddr_match_ipaddr6 commit b20d37ca9561711c6a3c4b859c2855f49565e061 upstream. Reported-by: Ben Greear Signed-off-by: Trond Myklebust Signed-off-by: Paul Gortmaker commit 293d5b209b9e318b1e261db7b0fe0037e2894555 Author: Anton Vorontsov Date: Wed Sep 8 00:10:26 2010 +0400 apm_power: Add missing break statement commit 1d220334d6a8a711149234dc5f98d34ae02226b8 upstream. The missing break statement causes wrong capacity calculation for batteries that report energy. Reported-by: d binderman Signed-off-by: Anton Vorontsov Signed-off-by: Paul Gortmaker commit 7a576be90ea01ba029df18bf140499cc18cf6331 Author: Guillem Jover Date: Fri Sep 17 17:24:12 2010 +0200 hwmon: (f75375s) Do not overwrite values read from registers commit c3b327d60bbba3f5ff8fd87d1efc0e95eb6c121b upstream. All bits in the values read from registers to be used for the next write were getting overwritten, avoid doing so to not mess with the current configuration. Signed-off-by: Guillem Jover Cc: Riku Voipio Signed-off-by: Jean Delvare Signed-off-by: Paul Gortmaker commit a2230d881ac906c305142f3760d5dc3bd13d4f54 Author: Guillem Jover Date: Fri Sep 17 17:24:11 2010 +0200 hwmon: (f75375s) Shift control mode to the correct bit position commit 96f3640894012be7dd15a384566bfdc18297bc6c upstream. The spec notes that fan0 and fan1 control mode bits are located in bits 7-6 and 5-4 respectively, but the FAN_CTRL_MODE macro was making the bits shift by 5 instead of by 4. Signed-off-by: Guillem Jover Cc: Riku Voipio Signed-off-by: Jean Delvare Signed-off-by: Paul Gortmaker commit 254011ce078854b42f96e6461362ccc94db8be5b Author: Al Viro Date: Fri Sep 17 14:34:39 2010 +0100 arm: fix really nasty sigreturn bug commit 653d48b22166db2d8b1515ebe6f9f0f7c95dfc86 upstream. If a signal hits us outside of a syscall and another gets delivered when we are in sigreturn (e.g. because it had been in sa_mask for the first one and got sent to us while we'd been in the first handler), we have a chance of returning from the second handler to location one insn prior to where we ought to return. If r0 happens to contain -513 (-ERESTARTNOINTR), sigreturn will get confused into doing restart syscall song and dance. Incredible joy to debug, since it manifests as random, infrequent and very hard to reproduce double execution of instructions in userland code... The fix is simple - mark it "don't bother with restarts" in wrapper, i.e. set r8 to 0 in sys_sigreturn and sys_rt_sigreturn wrappers, suppressing the syscall restart handling on return from these guys. They can't legitimately return a restart-worthy error anyway. Testcase: #include #include #include #include #include void f(int n) { __asm__ __volatile__( "ldr r0, [%0]\n" "b 1f\n" "b 2f\n" "1:b .\n" "2:\n" : : "r"(&n)); } void handler1(int sig) { } void handler2(int sig) { raise(1); } void handler3(int sig) { exit(0); } main() { struct sigaction s = {.sa_handler = handler2}; struct itimerval t1 = { .it_value = {1} }; struct itimerval t2 = { .it_value = {2} }; signal(1, handler1); sigemptyset(&s.sa_mask); sigaddset(&s.sa_mask, 1); sigaction(SIGALRM, &s, NULL); signal(SIGVTALRM, handler3); setitimer(ITIMER_REAL, &t1, NULL); setitimer(ITIMER_VIRTUAL, &t2, NULL); f(-513); /* -ERESTARTNOINTR */ write(1, "buggered\n", 9); return 1; } Signed-off-by: Al Viro Acked-by: Russell King Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 3b47cfe4b9ca5048737ee1940fa6fb466dd5e8c9 Author: Takashi Iwai Date: Fri Jul 30 14:08:25 2010 +0200 ALSA: hda - Handle pin NID 0x1a on ALC259/269 commit b08b1637ce1c0196970348bcabf40f04b6b3d58e upstream. The pin NID 0x1a should be handled as well as NID 0x1b. Also added comments. Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 66e49d079f7cf4e04e477224b4515ce4d735a430 Author: Takashi Iwai Date: Fri Jul 30 10:51:10 2010 +0200 ALSA: hda - Handle missing NID 0x1b on ALC259 codec commit 5d4abf93ea3192cc666430225a29a4978c97c57d upstream. Since ALC259/269 use the same parser of ALC268, the pin 0x1b was ignored as an invalid widget. Just add this NID to handle properly. This will add the missing mixer controls for some devices. Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 92f1af391b0eddaade98843829bc927f531ae899 Author: Suresh Siddha Date: Wed Mar 31 16:47:45 2010 -0700 sched: Fix select_idle_sibling() logic in select_task_rq_fair() commit 99bd5e2f245d8cd17d040c82d40becdb3efd9b69 upstream. Issues in the current select_idle_sibling() logic in select_task_rq_fair() in the context of a task wake-up: a) Once we select the idle sibling, we use that domain (spanning the cpu that the task is currently woken-up and the idle sibling that we found) in our wake_affine() decisions. This domain is completely different from the domain(we are supposed to use) that spans the cpu that the task currently woken-up and the cpu where the task previously ran. b) We do select_idle_sibling() check only for the cpu that the task is currently woken-up on. If select_task_rq_fair() selects the previously run cpu for waking the task, doing a select_idle_sibling() check for that cpu also helps and we don't do this currently. c) In the scenarios where the cpu that the task is woken-up is busy but with its HT siblings are idle, we are selecting the task be woken-up on the idle HT sibling instead of a core that it previously ran and currently completely idle. i.e., we are not taking decisions based on wake_affine() but directly selecting an idle sibling that can cause an imbalance at the SMT/MC level which will be later corrected by the periodic load balancer. Fix this by first going through the load imbalance calculations using wake_affine() and once we make a decision of woken-up cpu vs previously-ran cpu, then choose a possible idle sibling for waking up the task on. Signed-off-by: Suresh Siddha Signed-off-by: Peter Zijlstra LKML-Reference: <1270079265.7835.8.camel@sbs-t61.sc.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit cabe4242446ba8fdeb806601fa576fece35fc907 Author: Peter Zijlstra Date: Fri Apr 16 14:59:29 2010 +0200 sched: Pre-compute cpumask_weight(sched_domain_span(sd)) commit 669c55e9f99b90e46eaa0f98a67ec53d46dc969a upstream. Dave reported that his large SPARC machines spend lots of time in hweight64(), try and optimize some of those needless cpumask_weight() invocations (esp. with the large offstack cpumasks these are very expensive indeed). Reported-by: David Miller Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit a225add434f2b34ede4accc0a1f01eb0b388cb6f Author: Mike Galbraith Date: Thu Mar 11 17:17:16 2010 +0100 sched: Fix select_idle_sibling() commit 8b911acdf08477c059d1c36c21113ab1696c612b upstream. Don't bother with selection when the current cpu is idle. Recent load balancing changes also make it no longer necessary to check wake_affine() success before returning the selected sibling, so we now always use it. Signed-off-by: Mike Galbraith Signed-off-by: Peter Zijlstra LKML-Reference: <1268301369.6785.36.camel@marge.simson.net> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit c9ecb99443a55d80019f4f2153de26d2715f6485 Author: Daniel J Blueman Date: Tue Jun 1 14:06:13 2010 +0100 rcu: apply RCU protection to wake_affine() commit f3b577dec1f2ce32d2db6d2ca6badff7002512af upstream. The task_group() function returns a pointer that must be protected by either RCU, the ->alloc_lock, or the cgroup lock (see the rcu_dereference_check() in task_subsys_state(), which is invoked by task_group()). The wake_affine() function currently does none of these, which means that a concurrent update would be within its rights to free the structure returned by task_group(). Because wake_affine() uses this structure only to compute load-balancing heuristics, there is no reason to acquire either of the two locks. Therefore, this commit introduces an RCU read-side critical section that starts before the first call to task_group() and ends after the last use of the "tg" pointer returned from task_group(). Thanks to Li Zefan for pointing out the need to extend the RCU read-side critical section from that proposed by the original patch. Signed-off-by: Daniel J Blueman Signed-off-by: Paul E. McKenney Signed-off-by: Paul Gortmaker commit 64c0d770b67e0bdab7addafd1e19cdcd94be87e3 Author: Peter Zijlstra Date: Thu Aug 19 13:31:43 2010 +0200 sched: Fix rq->clock synchronization when migrating tasks commit 861d034ee814917a83bd5de4b26e3b8336ddeeb8 upstream. sched_fork() -- we do task placement in ->task_fork_fair() ensure we update_rq_clock() so we work with current time. We leave the vruntime in relative state, so the time delay until wake_up_new_task() doesn't matter. wake_up_new_task() -- Since task_fork_fair() left p->vruntime in relative state we can safely migrate, the activate_task() on the remote rq will call update_rq_clock() and causes the clock to be synced (enough). Tested-by: Jack Daniel Tested-by: Philby John Signed-off-by: Peter Zijlstra LKML-Reference: <1281002322.1923.1708.camel@laptop> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit d9f7ec9b3727555ba55ad14bddb056468fc7e122 Author: Peter Zijlstra Date: Fri Mar 26 12:22:14 2010 +0100 sched: Fix nr_uninterruptible count commit cc87f76a601d2d256118f7bab15e35254356ae21 upstream. The cpuload calculation in calc_load_account_active() assumes rq->nr_uninterruptible will not change on an offline cpu after migrate_nr_uninterruptible(). However the recent migrate on wakeup changes broke that and would result in decrementing the offline cpu's rq->nr_uninterruptible. Fix this by accounting the nr_uninterruptible on the waking cpu. Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 61b3749e9e41eee782bae9cfb21ba81d10f5f583 Author: Peter Zijlstra Date: Thu Mar 25 21:05:16 2010 +0100 sched: Optimize task_rq_lock() commit 65cc8e4859ff29a9ddc989c88557d6059834c2a2 upstream. Now that we hold the rq->lock over set_task_cpu() again, we can do away with most of the TASK_WAKING checks and reduce them again to set_cpus_allowed_ptr(). Removes some conditionals from scheduling hot-paths. Signed-off-by: Peter Zijlstra Cc: Oleg Nesterov LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit c7298d912a4eeaebf64b33ec60f2736fdbb49135 Author: Peter Zijlstra Date: Wed Mar 24 18:34:10 2010 +0100 sched: Fix TASK_WAKING vs fork deadlock commit 0017d735092844118bef006696a750a0e4ef6ebd upstream. Oleg noticed a few races with the TASK_WAKING usage on fork. - since TASK_WAKING is basically a spinlock, it should be IRQ safe - since we set TASK_WAKING (*) without holding rq->lock it could be there still is a rq->lock holder, thereby not actually providing full serialization. (*) in fact we clear PF_STARTING, which in effect enables TASK_WAKING. Cure the second issue by not setting TASK_WAKING in sched_fork(), but only temporarily in wake_up_new_task() while calling select_task_rq(). Cure the first by holding rq->lock around the select_task_rq() call, this will disable IRQs, this however requires that we push down the rq->lock release into select_task_rq_fair()'s cgroup stuff. Because select_task_rq_fair() still needs to drop the rq->lock we cannot fully get rid of TASK_WAKING. Reported-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 20b1d1ed393ddf313006bb5645417e55ef264a40 Author: Oleg Nesterov Date: Mon Mar 15 10:10:27 2010 +0100 sched: Make select_fallback_rq() cpuset friendly commit 9084bb8246ea935b98320554229e2f371f7f52fa upstream. Introduce cpuset_cpus_allowed_fallback() helper to fix the cpuset problems with select_fallback_rq(). It can be called from any context and can't use any cpuset locks including task_lock(). It is called when the task doesn't have online cpus in ->cpus_allowed but ttwu/etc must be able to find a suitable cpu. I am not proud of this patch. Everything which needs such a fat comment can't be good even if correct. But I'd prefer to not change the locking rules in the code I hardly understand, and in any case I believe this simple change make the code much more correct compared to deadlocks we currently have. Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091027.GA9155@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 16a938245f932bd0ccda8262bae52eb783684749 Author: Oleg Nesterov Date: Mon Mar 15 10:10:23 2010 +0100 sched: _cpu_down(): Don't play with current->cpus_allowed commit 6a1bdc1b577ebcb65f6603c57f8347309bc4ab13 upstream. _cpu_down() changes the current task's affinity and then recovers it at the end. The problems are well known: we can't restore old_allowed if it was bound to the now-dead-cpu, and we can race with the userspace which can change cpu-affinity during unplug. _cpu_down() should not play with current->cpus_allowed at all. Instead, take_cpu_down() can migrate the caller of _cpu_down() after __cpu_disable() removes the dying cpu from cpu_online_mask. Signed-off-by: Oleg Nesterov Acked-by: Rafael J. Wysocki Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091023.GA9148@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit e58c3ed611b189990521a1cd23a5576385b2b038 Author: Oleg Nesterov Date: Mon Mar 15 10:10:19 2010 +0100 sched: sched_exec(): Remove the select_fallback_rq() logic commit 30da688ef6b76e01969b00608202fff1eed2accc upstream. sched_exec()->select_task_rq() reads/updates ->cpus_allowed lockless. This can race with other CPUs updating our ->cpus_allowed, and this looks meaningless to me. The task is current and running, it must have online cpus in ->cpus_allowed, the fallback mode is bogus. And, if ->sched_class returns the "wrong" cpu, this likely means we raced with set_cpus_allowed() which was called for reason, why should sched_exec() retry and call ->select_task_rq() again? Change the code to call sched_class->select_task_rq() directly and do nothing if the returned cpu is wrong after re-checking under rq->lock. From now task_struct->cpus_allowed is always stable under TASK_WAKING, select_fallback_rq() is always called under rq-lock or the caller or the caller owns TASK_WAKING (select_task_rq). Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091019.GA9141@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 27311b45b8a074e74d670b5cc158a4f4f61eca27 Author: Oleg Nesterov Date: Mon Mar 15 10:10:14 2010 +0100 sched: move_task_off_dead_cpu(): Remove retry logic commit c1804d547dc098363443667609c272d1e4d15ee8 upstream. The previous patch preserved the retry logic, but it looks unneeded. __migrate_task() can only fail if we raced with migration after we dropped the lock, but in this case the caller of set_cpus_allowed/etc must initiate migration itself if ->on_rq == T. We already fixed p->cpus_allowed, the changes in active/online masks must be visible to racer, it should migrate the task to online cpu correctly. Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091014.GA9138@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit b7a90bb928bf71e72bd18c7ecfd44215b58ff683 Author: Oleg Nesterov Date: Mon Mar 15 10:10:10 2010 +0100 sched: move_task_off_dead_cpu(): Take rq->lock around select_fallback_rq() commit 1445c08d06c5594895b4fae952ef8a457e89c390 upstream. move_task_off_dead_cpu()->select_fallback_rq() reads/updates ->cpus_allowed lockless. We can race with set_cpus_allowed() running in parallel. Change it to take rq->lock around select_fallback_rq(). Note that it is not trivial to move this spin_lock() into select_fallback_rq(), we must recheck the task was not migrated after we take the lock and other callers do not need this lock. To avoid the races with other callers of select_fallback_rq() which rely on TASK_WAKING, we also check p->state != TASK_WAKING and do nothing otherwise. The owner of TASK_WAKING must update ->cpus_allowed and choose the correct CPU anyway, and the subsequent __migrate_task() is just meaningless because p->se.on_rq must be false. Alternatively, we could change select_task_rq() to take rq->lock right after it calls sched_class->select_task_rq(), but this looks a bit ugly. Also, change it to not assume irqs are disabled and absorb __migrate_task_irq(). Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091010.GA9131@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit b16ba66ee81f4df8466ea8aaf0f193bd87e458fc Author: Oleg Nesterov Date: Mon Mar 15 10:10:03 2010 +0100 sched: Kill the broken and deadlockable cpuset_lock/cpuset_cpus_allowed_locked code commit 897f0b3c3ff40b443c84e271bef19bd6ae885195 upstream. This patch just states the fact the cpusets/cpuhotplug interaction is broken and removes the deadlockable code which only pretends to work. - cpuset_lock() doesn't really work. It is needed for cpuset_cpus_allowed_locked() but we can't take this lock in try_to_wake_up()->select_fallback_rq() path. - cpuset_lock() is deadlockable. Suppose that a task T bound to CPU takes callback_mutex. If cpu_down(CPU) happens before T drops callback_mutex stop_machine() preempts T, then migration_call(CPU_DEAD) tries to take cpuset_lock() and hangs forever because CPU is already dead and thus T can't be scheduled. - cpuset_cpus_allowed_locked() is deadlockable too. It takes task_lock() which is not irq-safe, but try_to_wake_up() can be called from irq. Kill them, and change select_fallback_rq() to use cpu_possible_mask, like we currently do without CONFIG_CPUSETS. Also, with or without this patch, with or without CONFIG_CPUSETS, the callers of select_fallback_rq() can race with each other or with set_cpus_allowed() pathes. The subsequent patches try to to fix these problems. Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091003.GA9123@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 8a8bcc90350488ded5540d93a80afbea27be528b Author: Roland McGrath Date: Tue Sep 14 12:22:58 2010 -0700 x86-64, compat: Retruncate rax after ia32 syscall entry tracing commit eefdca043e8391dcd719711716492063030b55ac upstream. In commit d4d6715, we reopened an old hole for a 64-bit ptracer touching a 32-bit tracee in system call entry. A %rax value set via ptrace at the entry tracing stop gets used whole as a 32-bit syscall number, while we only check the low 32 bits for validity. Fix it by truncating %rax back to 32 bits after syscall_trace_enter, in addition to testing the full 64 bits as has already been added. Reported-by: Ben Hawkes Signed-off-by: Roland McGrath Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit 92d8c047c17986afef182f22b9a95a2835aadb54 Author: H. Peter Anvin Date: Tue Sep 7 16:16:18 2010 -0700 compat: Make compat_alloc_user_space() incorporate the access_ok() commit c41d68a513c71e35a14f66d71782d27a79a81ea6 upstream. compat_alloc_user_space() expects the caller to independently call access_ok() to verify the returned area. A missing call could introduce problems on some architectures. This patch incorporates the access_ok() check into compat_alloc_user_space() and also adds a sanity check on the length. The existing compat_alloc_user_space() implementations are renamed arch_compat_alloc_user_space() and are used as part of the implementation of the new global function. This patch assumes NULL will cause __get_user()/__put_user() to either fail or access userspace on all architectures. This should be followed by checking the return value of compat_access_user_space() for NULL in the callers, at which time the access_ok() in the callers can also be removed. Reported-by: Ben Hawkes Signed-off-by: H. Peter Anvin Acked-by: Benjamin Herrenschmidt Acked-by: Chris Metcalf Acked-by: David S. Miller Acked-by: Ingo Molnar Acked-by: Thomas Gleixner Acked-by: Tony Luck Cc: Andrew Morton Cc: Arnd Bergmann Cc: Fenghua Yu Cc: H. Peter Anvin Cc: Heiko Carstens Cc: Helge Deller Cc: James Bottomley Cc: Kyle McMartin Cc: Martin Schwidefsky Cc: Paul Mackerras Cc: Ralf Baechle Signed-off-by: Paul Gortmaker commit 71f45ea268894b70ef3e4a597fe78ab22a9c061a Author: H. Peter Anvin Date: Tue Sep 14 12:42:41 2010 -0700 x86-64, compat: Test %rax for the syscall number, not %eax commit 36d001c70d8a0144ac1d038f6876c484849a74de upstream. On 64 bits, we always, by necessity, jump through the system call table via %rax. For 32-bit system calls, in theory the system call number is stored in %eax, and the code was testing %eax for a valid system call number. At one point we loaded the stored value back from the stack to enforce zero-extension, but that was removed in checkin d4d67150165df8bf1cc05e532f6efca96f907cab. An actual 32-bit process will not be able to introduce a non-zero-extended number, but it can happen via ptrace. Instead of re-introducing the zero-extension, test what we are actually going to use, i.e. %rax. This only adds a handful of REX prefixes to the code. Reported-by: Ben Hawkes Signed-off-by: H. Peter Anvin Cc: Roland McGrath Cc: Andrew Morton Signed-off-by: Paul Gortmaker commit 93ce128d3700536a2fb8593f83fd6ed137a9556c Author: Peter Zijlstra Date: Fri Sep 10 22:32:53 2010 +0200 x86, tsc: Fix a preemption leak in restore_sched_clock_state() commit 55496c896b8a695140045099d4e0175cf09d4eae upstream. Doh, a real life genuine preemption leak.. This caused a suspend failure. Reported-bisected-and-tested-by-the-invaluable: Jeff Chua Acked-by: Suresh Siddha Signed-off-by: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Nico Schottelius Cc: Jesse Barnes Cc: Linus Torvalds Cc: Florian Pritz Cc: Suresh Siddha Cc: Len Brown LKML-Reference: <1284150773.402.122.camel@laptop> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit eba3b3e64f83ebb13e60552b9fb8947fb866028f Author: Johannes Berg Date: Mon Aug 30 12:24:54 2010 +0200 wireless extensions: fix kernel heap content leak commit 42da2f948d949efd0111309f5827bf0298bcc9a4 upstream. Wireless extensions have an unfortunate, undocumented requirement which requires drivers to always fill iwp->length when returning a successful status. When a driver doesn't do this, it leads to a kernel heap content leak when userspace offers a larger buffer than would have been necessary. Arguably, this is a driver bug, as it should, if it returns 0, fill iwp->length, even if it separately indicated that the buffer contents was not valid. However, we can also at least avoid the memory content leak if the driver doesn't do this by setting the iwp length to max_tokens, which then reflects how big the buffer is that the driver may fill, regardless of how big the userspace buffer is. To illustrate the point, this patch also fixes a corresponding cfg80211 bug (since this requirement isn't documented nor was ever pointed out by anyone during code review, I don't trust all drivers nor all cfg80211 handlers to implement it correctly). Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit 4bc2b2fce7a6de8df10442c73600327b6b999706 Author: John W. Linville Date: Tue Aug 24 15:27:34 2010 -0400 ath5k: check return value of ieee80211_get_tx_rate commit d8e1ba76d619dbc0be8fbeee4e6c683b5c812d3a upstream. This avoids a NULL pointer dereference as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=625889 When the WARN condition is hit in ieee80211_get_tx_rate, it will return NULL. So, we need to check the return value and avoid dereferencing it in that case. Signed-off-by: John W. Linville Acked-by: Bob Copeland Signed-off-by: Paul Gortmaker commit 4cd69d4ef59656cc77f70284ec22ecc60c39b0c3 Author: Christian Lamparter Date: Tue Aug 24 22:54:05 2010 +0200 p54: fix tx feedback status flag check commit f880c2050f30b23c9b6f80028c09f76e693bf309 upstream. Michael reported that p54* never really entered power save mode, even tough it was enabled. It turned out that upon a power save mode change the firmware will set a special flag onto the last outgoing frame tx status (which in this case is almost always the designated PSM nullfunc frame). This flag confused the driver; It erroneously reported transmission failures to the stack, which then generated the next nullfunc. and so on... Reported-by: Michael Buesch Tested-by: Michael Buesch Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit c79ed2536ec734351cd89c3cfc330112cfd7b18a Author: Frederic Weisbecker Date: Sun Aug 22 04:29:17 2010 +0200 perf: Initialize callchains roots's childen hits commit 5225c45899e872383ca39f5533d28ec63c54b39e upstream. Each histogram entry has a callchain root that stores the callchain samples. However we forgot to initialize the tracking of children hits of these roots, which then got random values on their creation. The root children hits is multiplied by the minimum percentage of hits provided by the user, and the result becomes the minimum hits expected from children branches. If the random value due to the uninitialization is big enough, then this minimum number of hits can be huge and eventually filter every children branches. The end result was invisible callchains. All we need to fix this is to initialize the children hits of the root. Reported-by: Christoph Hellwig Signed-off-by: Frederic Weisbecker Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Paul Mackerras Signed-off-by: Paul Gortmaker commit 514fe41b005efb2ad56ab5a5883e1f4ed9408254 Author: KAMEZAWA Hiroyuki Date: Thu Sep 9 16:38:01 2010 -0700 memory hotplug: fix next block calculation in is_removable commit 0dcc48c15f63ee86c2fcd33968b08d651f0360a5 upstream. next_active_pageblock() is for finding next _used_ freeblock. It skips several blocks when it finds there are a chunk of free pages lager than pageblock. But it has 2 bugs. 1. We have no lock. page_order(page) - pageblock_order can be minus. 2. pageblocks_stride += is wrong. it should skip page_order(p) of pages. Signed-off-by: KAMEZAWA Hiroyuki Cc: Michal Hocko Cc: Wu Fengguang Cc: Mel Gorman Cc: KAMEZAWA Hiroyuki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 327e9570426b36235457f86ad164b482cc48d43c Author: Dmitry Torokhov Date: Tue Aug 31 17:27:02 2010 -0700 Input: i8042 - fix device removal on unload commit af045b86662f17bf130239a65995c61a34f00a6b upstream. We need to call platform_device_unregister(i8042_platform_device) before calling platform_driver_unregister() because i8042_remove() resets i8042_platform_device to NULL. This leaves the platform device instance behind and prevents driver reload. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=16613 Reported-by: Seryodkin Victor Signed-off-by: Dmitry Torokhov Signed-off-by: Paul Gortmaker commit b1f9216a7b13b63c26573e8c31b2df700db1faaf Author: Jan Sembera Date: Thu Sep 9 16:37:54 2010 -0700 binfmt_misc: fix binfmt_misc priority commit ee3aebdd8f5f8eac41c25c80ceee3d728f920f3b upstream. Commit 74641f584da ("alpha: binfmt_aout fix") (May 2009) introduced a regression - binfmt_misc is now consulted after binfmt_elf, which will unfortunately break ia32el. ia32 ELF binaries on ia64 used to be matched using binfmt_misc and executed using wrapper. As 32bit binaries are now matched by binfmt_elf before bindmt_misc kicks in, the wrapper is ignored. The fix increases precedence of binfmt_misc to the original state. Signed-off-by: Jan Sembera Cc: Ivan Kokshaysky Cc: Al Viro Cc: Richard Henderson Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 982ce55c5ea05debc2ca705e936580f905745618 Author: Jerome Marchand Date: Thu Sep 9 16:37:59 2010 -0700 kernel/groups.c: fix integer overflow in groups_search commit 1c24de60e50fb19b94d94225458da17c720f0729 upstream. gid_t is a unsigned int. If group_info contains a gid greater than MAX_INT, groups_search() function may look on the wrong side of the search tree. This solves some unfair "permission denied" problems. Signed-off-by: Jerome Marchand Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 64efb081839bff070a0f17dbf1efa73ad02371de Author: Gary King Date: Thu Sep 9 16:38:05 2010 -0700 bounce: call flush_dcache_page() after bounce_copy_vec() commit ac8456d6f9a3011c824176bd6084d39e5f70a382 upstream. I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform cache maintenance lazily), and the root cause appears to be that the mm bouncing code is calling flush_dcache_page before it copies the bounce buffer into the bio. The bounced page needs to be flushed after data is copied into it, to ensure that architecture implementations can synchronize instruction and data caches if necessary. Signed-off-by: Gary King Cc: Tejun Heo Cc: Russell King Acked-by: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit c8188f6b72d2916736015caf96c539cb38d51dc3 Author: Guennadi Liakhovetski Date: Thu Sep 9 16:37:43 2010 -0700 mmc: fix the use of kunmap_atomic() in tmio_mmc.h commit 5600efb1bc2745d93ae0bc08130117a84f2b9d69 upstream. kunmap_atomic() takes the cookie, returned by the kmap_atomic() as its argument and not the page address, used as an argument to kmap_atomic(). This patch fixes the compile error: In file included from drivers/mmc/host/tmio_mmc.c:37: drivers/mmc/host/tmio_mmc.h: In function 'tmio_mmc_kunmap_atomic': drivers/mmc/host/tmio_mmc.h:192: error: negative width in bit-field '' Signed-off-by: Guennadi Liakhovetski Acked-by: Eric Miao Tested-by: Magnus Damm Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 4986f350e204ac1e4ca11567aec51b431d562b91 Author: Yusuke Goda Date: Thu Sep 9 16:37:39 2010 -0700 tmio_mmc: don't clear unhandled pending interrupts commit b78d6c5f51935ba89df8db33a57bacb547aa7325 upstream. Previously, it was possible for ack_mmc_irqs() to clear pending interrupt bits in the CTL_STATUS register, even though the interrupt handler had not been called. This was because of a race that existed when doing a read-modify-write sequence on CTL_STATUS. After the read step in this sequence, if an interrupt occurred (causing one of the bits in CTL_STATUS to be set) the write step would inadvertently clear it. Observed with the TMIO_STAT_RXRDY bit together with CMD53 on AR6002 and BCM4318 SDIO cards in polled mode. This patch eliminates this race by only writing to CTL_STATUS and clearing the interrupts that were passed as an argument to ack_mmc_irqs()." [matt@console-pimps.org: rewrote changelog] Signed-off-by: Yusuke Goda Acked-by: Magnus Damm " Tested-by: Arnd Hannemann " Acked-by: Ian Molton Cc: Matt Fleming Cc: Samuel Ortiz Cc: Paul Mundt Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 34afb10be8f95bf482576b2b9d82810cd45aa21d Author: Peter Oberparleiter Date: Thu Sep 9 16:37:35 2010 -0700 gcov: fix null-pointer dereference for certain module types commit 85a0fdfd0f967507f3903e8419bc7e408f5a59de upstream. The gcov-kernel infrastructure expects that each object file is loaded only once. This may not be true, e.g. when loading multiple kernel modules which are linked to the same object file. As a result, loading such kernel modules will result in incorrect gcov results while unloading will cause a null-pointer dereference. This patch fixes these problems by changing the gcov-kernel infrastructure so that multiple profiling data sets can be associated with one debugfs entry. It applies to 2.6.36-rc1. Signed-off-by: Peter Oberparleiter Reported-by: Werner Spies Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 639e5434c802fd0e3106f0049d4fa1a7a908653f Author: Dan Carpenter Date: Sat Sep 4 03:14:35 2010 +0000 irda: off by one commit cf9b94f88bdbe8a02015fc30d7c232b2d262d4ad upstream. This is an off by one. We would go past the end when we NUL terminate the "value" string at end of the function. The "value" buffer is allocated in irlan_client_parse_response() or irlan_provider_parse_command(). Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit ed6c29b8a1a35463ec9fc6843543f0a19e0af158 Author: Chris Wright Date: Thu Sep 9 16:34:59 2010 -0700 tracing: t_start: reset FTRACE_ITER_HASH in case of seek/pread commit df09162550fbb53354f0c88e85b5d0e6129ee9cc upstream. Be sure to avoid entering t_show() with FTRACE_ITER_HASH set without having properly started the iterator to iterate the hash. This case is degenerate and, as discovered by Robert Swiecki, can cause t_hash_show() to misuse a pointer. This causes a NULL ptr deref with possible security implications. Tracked as CVE-2010-3079. Cc: Robert Swiecki Cc: Eugene Teo Signed-off-by: Chris Wright Signed-off-by: Steven Rostedt Signed-off-by: Paul Gortmaker commit af54da7460bd486c7df9727efcbcb7e9e1c490f3 Author: Steven Rostedt Date: Wed Sep 8 11:20:37 2010 -0400 tracing: Do not allow llseek to set_ftrace_filter commit 9c55cb12c1c172e2d51e85fbb5a4796ca86b77e7 upstream. Reading the file set_ftrace_filter does three things. 1) shows whether or not filters are set for the function tracer 2) shows what functions are set for the function tracer 3) shows what triggers are set on any functions 3 is independent from 1 and 2. The way this file currently works is that it is a state machine, and as you read it, it may change state. But this assumption breaks when you use lseek() on the file. The state machine gets out of sync and the t_show() may use the wrong pointer and cause a kernel oops. Luckily, this will only kill the app that does the lseek, but the app dies while holding a mutex. This prevents anyone else from using the set_ftrace_filter file (or any other function tracing file for that matter). A real fix for this is to rewrite the code, but that is too much for a -rc release or stable. This patch simply disables llseek on the set_ftrace_filter() file for now, and we can do the proper fix for the next major release. Reported-by: Robert Swiecki Cc: Chris Wright Cc: Tavis Ormandy Cc: Eugene Teo Cc: vendor-sec@lst.de Signed-off-by: Steven Rostedt Signed-off-by: Paul Gortmaker commit c1652827c8578296d0e6560793bbfc213da8e0b6 Author: Li Zefan Date: Mon Aug 23 16:50:12 2010 +0800 tracing: Fix a race in function profile commit 3aaba20f26f58843e8f20611e5c0b1c06954310f upstream. While we are reading trace_stat/functionX and someone just disabled function_profile at that time, we can trigger this: divide error: 0000 [#1] PREEMPT SMP ... EIP is at function_stat_show+0x90/0x230 ... This fix just takes the ftrace_profile_lock and checks if rec->counter is 0. If it's 0, we know the profile buffer has been reset. Signed-off-by: Li Zefan LKML-Reference: <4C723644.4040708@cn.fujitsu.com> Signed-off-by: Steven Rostedt Signed-off-by: Paul Gortmaker commit d7dea4cdd7bf64eb69c4583c9daec870c722bea0 Author: Tejun Heo Date: Tue Sep 7 14:05:31 2010 +0200 libata: skip EH autopsy and recovery during suspend commit e2f3d75fc0e4a0d03c61872bad39ffa2e74a04ff upstream. For some mysterious reason, certain hardware reacts badly to usual EH actions while the system is going for suspend. As the devices won't be needed until the system is resumed, ask EH to skip usual autopsy and recovery and proceed directly to suspend. Signed-off-by: Tejun Heo Tested-by: Stephan Diestelhorst Signed-off-by: Jeff Garzik Signed-off-by: Paul Gortmaker commit 18c31e36e7e773d0dc02c515f1e517eac003a658 Author: Robert Richter Date: Wed Sep 1 14:50:50 2010 +0200 oprofile, x86: fix init_sysfs() function stub commit 269f45c25028c75fe10e6d9be86e7202ab461fbc upstream. The use of the return value of init_sysfs() with commit 10f0412 oprofile, x86: fix init_sysfs error handling discovered the following build error for !CONFIG_PM: .../linux/arch/x86/oprofile/nmi_int.c: In function ‘op_nmi_init’: .../linux/arch/x86/oprofile/nmi_int.c:784: error: expected expression before ‘do’ make[2]: *** [arch/x86/oprofile/nmi_int.o] Error 1 make[1]: *** [arch/x86/oprofile] Error 2 This patch fixes this. Reported-by: Ingo Molnar Signed-off-by: Robert Richter Signed-off-by: Paul Gortmaker commit 4773c40c1c5d5e32a403ce999f7a5622985b8c8d Author: Robert Richter Date: Mon Aug 30 10:56:18 2010 +0200 oprofile, x86: fix init_sysfs error handling commit 10f0412f57f2a76a90eff4376f59cbb0a39e4e18 upstream. On failure init_sysfs() might not properly free resources. The error code of the function is not checked. And, when reinitializing the exit function might be called twice. This patch fixes all this. Signed-off-by: Robert Richter Signed-off-by: Paul Gortmaker commit c0efd974f29d6e02c1e8c7bf598bb5b99ab97e9b Author: Robert Richter Date: Fri Aug 13 16:29:04 2010 +0200 oprofile: fix crash when accessing freed task structs commit 750d857c682f4db60d14722d430c7ccc35070962 upstream. This patch fixes a crash during shutdown reported below. The crash is caused by accessing already freed task structs. The fix changes the order for registering and unregistering notifier callbacks. All notifiers must be initialized before buffers start working. To stop buffer synchronization we cancel all workqueues, unregister the notifier callback and then flush all buffers. After all of this we finally can free all tasks listed. This should avoid accessing freed tasks. On 22.07.10 01:14:40, Benjamin Herrenschmidt wrote: > So the initial observation is a spinlock bad magic followed by a crash > in the spinlock debug code: > > [ 1541.586531] BUG: spinlock bad magic on CPU#5, events/5/136 > [ 1541.597564] Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6d03 > > Backtrace looks like: > > spin_bug+0x74/0xd4 > ._raw_spin_lock+0x48/0x184 > ._spin_lock+0x10/0x24 > .get_task_mm+0x28/0x8c > .sync_buffer+0x1b4/0x598 > .wq_sync_buffer+0xa0/0xdc > .worker_thread+0x1d8/0x2a8 > .kthread+0xa8/0xb4 > .kernel_thread+0x54/0x70 > > So we are accessing a freed task struct in the work queue when > processing the samples. Reported-by: Benjamin Herrenschmidt Signed-off-by: Robert Richter Signed-off-by: Paul Gortmaker commit 33f19e56a712a1d7c3dead0ef0fb335a25083e6d Author: Dan Carpenter Date: Wed Aug 25 09:12:29 2010 +0200 sysfs: checking for NULL instead of ERR_PTR commit 57f9bdac2510cd7fda58e4a111d250861eb1ebeb upstream. d_path() returns an ERR_PTR and it doesn't return NULL. Signed-off-by: Dan Carpenter Reviewed-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 7582f1a38302e41552204d52fbe40962f98fba8e Author: Takashi Iwai Date: Mon Sep 6 09:13:45 2010 +0200 ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open() commit 27f7ad53829f79e799a253285318bff79ece15bd upstream. The error handling in snd_seq_oss_open() has several bad codes that do dereferecing released pointers and double-free of kmalloc'ed data. The object dp is release in free_devinfo() that is called via private_free callback. The rest shouldn't touch this object any more. The patch changes delete_port() to call kfree() in any case, and gets rid of unnecessary calls of destructors in snd_seq_oss_open(). Fixes CVE-2010-3080. Reported-and-tested-by: Tavis Ormandy Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 008f9efc13497e0b6cd7b2b11ea82d08b0d47ec9 Author: Toby Gray Date: Thu Sep 2 10:46:20 2010 +0100 USB: cdc-acm: Fixing crash when ACM probing interfaces with no endpoint descriptors. commit 577045c0a76e34294f902a7d5d60e90b04d094d0 upstream. Certain USB devices, such as the Nokia X6 mobile phone, don't expose any endpoint descriptors on some of their interfaces. If the ACM driver is forced to probe all interfaces on a device the a NULL pointer dereference will occur when the ACM driver attempts to use the endpoint of the alternative settings. One way to get the ACM driver to probe all the interfaces is by using the /sys/bus/usb/drivers/cdc_acm/new_id interface. This patch checks that the endpoint pointer for the current alternate settings is non-NULL before using it. Signed-off-by: Toby Gray Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 1b6cc1718a9a203daad668fff39f8f4ba0ae1459 Author: Philippe Corbes Date: Tue Aug 31 19:31:32 2010 +0200 USB: cdc-acm: Add pseudo modem without AT command capabilities commit 5b239f0aebd4dd6f85b13decf5e18e86e35d57f0 upstream. cdc-acm.c : Manage pseudo-modem without AT commands capabilities Enable to drive electronic simple gadgets based on microcontrolers. The Interface descriptor is like this: bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 None Signed-off-by: Philippe Corbes Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 0b0c43410a922edd7894175305e837d748b0d9de Author: Toby Gray Date: Wed Sep 1 16:01:19 2010 +0100 USB: cdc-acm: Adding second ACM channel support for various Nokia and one Samsung phones commit 4035e45632c2a8bb4edae83c20447051bd9a9604 upstream. S60 phones from Nokia and Samsung expose two ACM channels. The first is a modem with a standard AT-command interface, which is picked up correctly by CDC-ACM. The second ACM port is marked as having a vendor-specific protocol. This means that the ACM driver will not claim the second channel by default. This adds support for the second ACM channel for the following devices: Nokia E63 Nokia E75 Nokia 6760 Slide Nokia E52 Nokia E55 Nokia E72 Nokia X6 Nokia N97 Mini Nokia 5800 Xpressmusic Nokia E90 Samsung GTi8510 (INNOV8) Signed-off-by: Toby Gray Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit af909188e0959217ca0143f0380b0693c1cb26a2 Author: Przemo Firszt Date: Mon Jun 28 21:29:34 2010 +0100 USB: Expose vendor-specific ACM channel on Nokia 5230 commit 83a4eae9aeed4a69e89e323a105e653ae06e7c1f upstream. Nokia S60 phones expose two ACM channels. The first is a modem, the second is 'vendor-specific' but is treated as a serial device at the S60 end, so we want to expose it on Linux too. Signed-off-by: Przemo Firszt Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 62d8c582cbf5f27cd59d85fa2ede30ff653f3972 Author: Dave Ludlow Date: Wed Sep 1 12:33:30 2010 -0400 usb: serial: mos7840: Add USB IDs to support more B&B USB/RS485 converters. commit 870408c8291015872a7a0b583673a9e56b3e73f4 upstream. Add the USB IDs needed to support the B&B USOPTL4-4P, USO9ML2-2P, and USO9ML2-4P. This patch expands and corrects a typo in the patch sent on 08-31-2010. Signed-off-by: Dave Ludlow Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 3b83a160a3919c8d75e0f1b0c2d991ebddf73223 Author: Dave Ludlow Date: Tue Aug 31 14:26:17 2010 -0400 usb: serial: mos7840: Add USB ID to support the B&B Electronics USOPTL4-2P. commit caf3a636a9f809fdca5fa746e6687096457accb1 upstream. Add the USB ID needed to support B&B Electronic's 2-port, optically-isolated, powered, USB to RS485 converter. Signed-off-by: Dave Ludlow Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit aa2f548ee565a03dcf867057ff6fc6e2ab396243 Author: Luke Lowrey Date: Thu Sep 2 11:39:49 2010 +0100 USB: ftdi_sio: Added custom PIDs for ChamSys products commit 657373883417b2618023fd4135d251ba06a2c30a upstream. Added the 0xDAF8 to 0xDAFF PID range for ChamSys limited USB interface/wing products Signed-off-by: Luke Lowrey Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit d4bbea3295237c85723f89fa030341ed1213fc23 Author: Jason Detring Date: Thu Aug 26 15:08:54 2010 -0500 USB: cp210x: Add B&G H3000 link cable ID commit 0bf7a81c5d447c21db434be35363c44c0a30f598 upstream. This is the cable between an H3000 navigation unit and a multi-function display. http://www.bandg.com/en/Products/H3000/Spares-and-Accessories/Cables/H3000-CPU-USB-Cable-Pack/ Signed-off-by: Jason Detring Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 85eec56084526a776672621827a29c72c29b4de0 Author: Craig Shelley Date: Mon Aug 23 20:50:57 2010 +0100 USB: CP210x Add new device ID commit 541e05ec3add5ab5bcf238d60161b53480280b20 upstream. New device ID added for Balluff RFID reader. Signed-off-by: Craig Shelley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 1da2dba4738c918aaa600b97886d17772e4bcfea Author: Maxim Osipov Date: Sat Aug 21 14:54:06 2010 +0400 USB: Fix kernel oops with g_ether and Windows commit 037d3656adbd7e8cb848f01cf5dec423ed76bbe7 upstream. Please find attached patch for https://bugzilla.kernel.org/show_bug.cgi?id=16023 problem. Signed-off-by: Maxim Osipov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 85f55525b262080fcbe143601947c88208c0c315 Author: Dan Carpenter Date: Sat Aug 14 11:06:19 2010 +0200 USB: ehci-ppc-of: problems in unwind commit 08a3b3b1c2e622e378d9086aee9e2e42ce37591d upstream. The iounmap(ehci->ohci_hcctrl_reg); should be the first thing we do because the ioremap() was the last thing we did. Also if we hit any of the goto statements in the original code then it would have led to a NULL dereference of "ehci". This bug was introduced in: 796bcae7361c "USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]" I modified the few lines in front a little so that my code didn't obscure the return success code path. Signed-off-by: Dan Carpenter Reviewed-by: Grant Likely Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 654a3ffcdf03dc238a23f4572544392516d6daa1 Author: Sunil Mushran Date: Thu Aug 12 16:24:26 2010 -0700 ocfs2: Fix incorrect checksum validation error commit f5ce5a08a40f2086435858ddc80cb40394b082eb upstream. For local mounts, ocfs2_read_locked_inode() calls ocfs2_read_blocks_sync() to read the inode off the disk. The latter first checks to see if that block is cached in the journal, and, if so, returns that block. That is ok. But ocfs2_read_locked_inode() goes wrong when it tries to validate the checksum of such blocks. Blocks that are cached in the journal may not have had their checksum computed as yet. We should not validate the checksums of such blocks. Fixes ossbz#1282 http://oss.oracle.com/bugzilla/show_bug.cgi?id=1282 Signed-off-by: Sunil Mushran Singed-off-by: Tao Ma Signed-off-by: Paul Gortmaker commit 5ba16d7c0e8cc1e32b00c05d08725252f33a1415 Author: Luis R. Rodriguez Date: Mon Aug 30 19:26:33 2010 -0400 ath9k_hw: fix parsing of HT40 5 GHz CTLs commit 904879748d7439a6dabdc6be9aad983e216b027d upstream. The 5 GHz CTL indexes were not being read for all hardware devices due to the masking out through the CTL_MODE_M mask being one bit too short. Without this the calibrated regulatory maximum values were not being picked up when devices operate on 5 GHz in HT40 mode. The final output power used for Atheros devices is the minimum between the calibrated CTL values and what CRDA provides. Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit d12738a6a29d69f00840113a93c5c55be8c6af97 Author: Miklos Szeredi Date: Tue Sep 7 13:42:41 2010 +0200 fuse: flush background queue on connection close commit 595afaf9e6ee1b48e13ec4b8bcc8c7dee888161a upstream. David Bartly reported that fuse can hang in fuse_get_req_nofail() when the connection to the filesystem server is no longer active. If bg_queue is not empty then flush_bg_queue() called from request_end() can put more requests on to the pending queue. If this happens while ending requests on the processing queue then those background requests will be queued to the pending list and never ended. Another problem is that fuse_dev_release() didn't wake up processes sleeping on blocked_waitq. Solve this by: a) flushing the background queue before calling end_requests() on the pending and processing queues b) setting blocked = 0 and waking up processes waiting on blocked_waitq() Thanks to David for an excellent bug report. Reported-by: David Bartley Signed-off-by: Miklos Szeredi Signed-off-by: Paul Gortmaker commit 329d5e1242c4c6c0747070b0797f940b7ddb3d0b Author: Hank Janssen Date: Wed Sep 1 11:10:41 2010 -0700 staging: hv: Fixed lockup problem with bounce_buffer scatter list commit 77c5ceaff31645ea049c6706b99e699eae81fb88 upstream. Fixed lockup problem with bounce_buffer scatter list which caused crashes in heavy loads. And minor code indentation cleanup in effected area. Removed whitespace and noted minor indentation changes in description as pointed out by Joe Perches. (Thanks for reviewing Joe) Signed-off-by: Hank Janssen Signed-off-by: Haiyang Zhang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit d63247c5dfa7fefb7ca3e22456a8306408b0cd77 Author: Hank Janssen Date: Thu Aug 5 19:30:31 2010 +0000 staging: hv: Increased storvsc ringbuffer and max_io_requests commit 15dd1c9f53b31cdc84b8072a88c23fa09527c596 upstream. Increased storvsc ringbuffer and max_io_requests. This now more closely mimics the numbers on Hyper-V. And will allow more IO requests to take place for the SCSI driver. Max_IO is set to double from what it was before, Hyper-V allows it and we have had appliance builder requests to see if it was a problem to increase the number. Ringbuffer size for storvsc is now increased because I have seen A few buffer problems on extremely busy systems. They were Set pretty low before. And since max_io_requests is increased I Really needed to increase the buffer as well. Signed-off-by: Hank Janssen Signed-off-by: Haiyang Zhang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 4aaee64045762f0cbc8c33b1ad611f4047fb6280 Author: Haiyang Zhang Date: Thu Aug 5 19:30:01 2010 +0000 staging: hv: Fixed the value of the 64bit-hole inside ring buffer commit e5fa721d1c2a54261a37eb59686e18dee34b6af6 upstream. Fixed the value of the 64bit-hole inside ring buffer, this caused a problem on Hyper-V when running checked Windows builds. Checked builds of Windows are used internally and given to external system integrators at times. They are builds that for example that all elements in a structure follow the definition of that Structure. The bug this fixed was for a field that we did not fill in at all (Because we do Not use it on the Linux side), and the checked build of windows gives errors on it internally to the Windows logs. This fixes that error. Signed-off-by:Hank Janssen Signed-off-by:Haiyang Zhang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit d79e2c12c429490b2078ca2903b5853cde7c6c27 Author: Hank Janssen Date: Thu Aug 5 19:29:44 2010 +0000 staging: hv: Fixed bounce kmap problem by using correct index commit 0c47a70a9a8a6d1ec37a53d2f9cb82f8b8ef8aa2 upstream. Fixed bounce offset kmap problem by using correct index. The symptom of the problem is that in some NAS appliances this problem represents Itself by a unresponsive VM under a load with many clients writing small files. Signed-off-by:Hank Janssen Signed-off-by:Haiyang Zhang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit aeb3e765e1b9616e0aba0b2bef44127c04367cb0 Author: Haiyang Zhang Date: Tue Aug 3 19:15:31 2010 +0000 staging: hv: Fix missing functions for net_device_ops commit b681b5886bb5d1f5b6750a0ed7c62846da7ccea4 upstream. Fix missing functions for net_device_ops. It's a bug when porting the drivers from 2.6.27 to 2.6.32. In 2.6.27, the default functions for Ethernet, like eth_change_mtu(), were assigned by ether_setup(). But in 2.6.32, these function pointers moved to net_device_ops structure and no longer be assigned in ether_setup(). So we need to set these functions in our driver code. It will ensure the MTU won't be set beyond 1500. Otherwise, this can cause an error on the server side, because the HyperV linux driver doesn't support jumbo frame yet. Signed-off-by: Haiyang Zhang Signed-off-by: Hank Janssen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 6d0651305f155028a27b052b8bd6e8217a3a09af Author: Ben Hutchings Date: Fri Jul 23 14:56:28 2010 +0100 PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc() commit 30da55242818a8ca08583188ebcbaccd283ad4d9 upstream. commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 "PCI: MSI: Remove unsafe and unnecessary hardware access" changed read_msi_msg_desc() to return the last MSI message written instead of reading it from the device, since it may be called while the device is in a reduced power state. However, the pSeries platform code really does need to read messages from the device, since they are initially written by firmware. Therefore: - Restore the previous behaviour of read_msi_msg_desc() - Add new functions get_cached_msi_msg{,_desc}() which return the last MSI message written - Use the new functions where appropriate Acked-by: Michael Ellerman Signed-off-by: Ben Hutchings Signed-off-by: Jesse Barnes Signed-off-by: Paul Gortmaker commit 0ea9d359e7be67b617e4b685fc1397afc8c9fbcb Author: Ben Hutchings Date: Thu Jun 17 20:16:36 2010 +0100 PCI: MSI: Remove unsafe and unnecessary hardware access commit fcd097f31a6ee207cc0c3da9cccd2a86d4334785 upstream. During suspend on an SMP system, {read,write}_msi_msg_desc() may be called to mask and unmask interrupts on a device that is already in a reduced power state. At this point memory-mapped registers including MSI-X tables are not accessible, and config space may not be fully functional either. While a device is in a reduced power state its interrupts are effectively masked and its MSI(-X) state will be restored when it is brought back to D0. Therefore these functions can simply read and write msi_desc::msg for devices not in D0. Further, read_msi_msg_desc() should only ever be used to update a previously written message, so it can always read msi_desc::msg and never needs to touch the hardware. Tested-by: "Michael Chan" Signed-off-by: Ben Hutchings Signed-off-by: Jesse Barnes Signed-off-by: Paul Gortmaker commit 2e4044529b09977f06acdf7a67d7d20ba6bf4528 Author: Suresh Siddha Date: Thu Aug 19 17:03:38 2010 -0700 x86, tsc, sched: Recompute cyc2ns_offset's during resume from sleep states commit cd7240c0b900eb6d690ccee088a6c9b46dae815a upstream. TSC's get reset after suspend/resume (even on cpu's with invariant TSC which runs at a constant rate across ACPI P-, C- and T-states). And in some systems BIOS seem to reinit TSC to arbitrary large value (still sync'd across cpu's) during resume. This leads to a scenario of scheduler rq->clock (sched_clock_cpu()) less than rq->age_stamp (introduced in 2.6.32). This leads to a big value returned by scale_rt_power() and the resulting big group power set by the update_group_power() is causing improper load balancing between busy and idle cpu's after suspend/resume. This resulted in multi-threaded workloads (like kernel-compilation) go slower after suspend/resume cycle on core i5 laptops. Fix this by recomputing cyc2ns_offset's during resume, so that sched_clock() continues from the point where it was left off during suspend. Reported-by: Florian Pritz Signed-off-by: Suresh Siddha Signed-off-by: Peter Zijlstra LKML-Reference: <1282262618.2675.24.camel@sbsiddha-MOBL3.sc.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 7d86e26344e7a801802922e6481be4bea5b78357 Author: Mark Lord Date: Thu Aug 19 21:40:44 2010 -0400 sata_mv: fix broken DSM/TRIM support (v2) commit 44b733809a5aba7f6b15a548d31a56d25bf3851c upstream. Fix DSM/TRIM commands in sata_mv (v2). These need to be issued using old-school "BM DMA", rather than via the EDMA host queue. Since the chips don't have proper BM DMA status, we need to be more careful with setting the ATA_DMA_INTR bit, since DSM/TRIM often has a long delay between "DMA complete" and "command complete". GEN_I chips don't have BM DMA, so no TRIM for them. Signed-off-by: Mark Lord Signed-off-by: Jeff Garzik Signed-off-by: Paul Gortmaker commit cd790692c5a3ce8fe0bc4d73b3ea4f604ab903fe Author: David Henningsson Date: Thu Jul 29 14:46:42 2010 +0200 ALSA: hda - Rename iMic to Int Mic on Lenovo NB0763 commit 150b432f448281d5518f5229d240923f9a9c5459 upstream. The non-standard name "iMic" makes PulseAudio ignore the microphone. BugLink: https://launchpad.net/bugs/605101 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 5a7d6bc2748c99a1586ae1c1e0fa11338dc108cd Author: Jeremy Fitzhardinge Date: Fri Aug 20 18:57:53 2010 -0700 xen: use percpu interrupts for IPIs and VIRQs commit aaca49642b92c8a57d3ca5029a5a94019c7af69f upstream. IPIs and VIRQs are inherently per-cpu event types, so treat them as such: - use a specific percpu irq_chip implementation, and - handle them with handle_percpu_irq This makes the path for delivering these interrupts more efficient (no masking/unmasking, no locks), and it avoid problems with attempts to migrate them. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Paul Gortmaker commit 25b3d7b1ad6b562ab4de4b459aa8ec38f61bf10a Author: Jeremy Fitzhardinge Date: Fri Aug 20 19:10:01 2010 -0700 xen: handle events as edge-triggered commit dffe2e1e1a1ddb566a76266136c312801c66dcf7 upstream. Xen events are logically edge triggered, as Xen only calls the event upcall when an event is newly set, but not continuously as it remains set. As a result, use handle_edge_irq rather than handle_level_irq. This has the important side-effect of fixing a long-standing bug of events getting lost if: - an event's interrupt handler is running - the event is migrated to a different vcpu - the event is re-triggered The most noticable symptom of these lost events is occasional lockups of blkfront. Many thanks to Tom Kopec and Daniel Stodden in tracking this down. Signed-off-by: Jeremy Fitzhardinge Cc: Tom Kopec Cc: Daniel Stodden Signed-off-by: Paul Gortmaker commit ad0db2dbc5b9528ee9237946a7407e85e77883ec Author: Andreas Herrmann Date: Wed Aug 25 15:42:12 2010 +0200 hwmon: (k8temp) Differentiate between AM2 and ASB1 commit a05e93f3b3fc2f53c1d0de3b17019e207c482349 upstream. Commit 8bf0223ed515be24de0c671eedaff49e78bebc9c (hwmon, k8temp: Fix temperature reporting for ASB1 processor revisions) fixed temperature reporting for ASB1 CPUs. But those CPU models (model 0x6b, 0x6f, 0x7f) were packaged both as AM2 (desktop) and ASB1 (mobile). Thus the commit leads to wrong temperature reporting for AM2 CPU parts. The solution is to determine the package type for models 0x6b, 0x6f, 0x7f. This is done using BrandId from CPUID Fn8000_0001_EBX[15:0]. See "Constructing the processor Name String" in "Revision Guide for AMD NPT Family 0Fh Processors" (Rev. 3.46). Cc: Rudolf Marek Reported-by: Vladislav Guberinic Signed-off-by: Andreas Herrmann Signed-off-by: Jean Delvare Signed-off-by: Paul Gortmaker commit 963912d831b606ae776dfa7ef12ed26bfd0a6ee3 Author: Eric Sandeen Date: Sun Aug 1 17:33:29 2010 -0400 ext4: fix freeze deadlock under IO commit 437f88cc031ffe7f37f3e705367f4fe1f4be8b0f upstream. [The 6b0310fb below references the mainline version of what has also been cherry picked into this 34-stable branch] Commit 6b0310fbf087ad6 caused a regression resulting in deadlocks when freezing a filesystem which had active IO; the vfs_check_frozen level (SB_FREEZE_WRITE) did not let the freeze-related IO syncing through. Duh. Changing the test to FREEZE_TRANS should let the normal freeze syncing get through the fs, but still block any transactions from starting once the fs is completely frozen. I tested this by running fsstress in the background while periodically snapshotting the fs and running fsck on the result. I ran into occasional deadlocks, but different ones. I think this is a fine fix for the problem at hand, and the other deadlocky things will need more investigation. Reported-by: Phillip Susi Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit a17fa98c4c808a8ce7d7478a7a64e108c29ca1fe Author: David Howells Date: Fri Jul 30 15:25:19 2010 +0100 CIFS: Remove __exit mark from cifs_exit_dns_resolver() commit 51c20fcced5badee0e2021c6c89f44aa3cbd72aa upstream. Remove the __exit mark from cifs_exit_dns_resolver() as it's called by the module init routine in case of error, and so may have been discarded during linkage. Signed-off-by: David Howells Acked-by: Jeff Layton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit f1da3e1315fc3a2d3ded2434a327b913d7a80092 Author: Frank Mayhar Date: Mon May 17 08:00:00 2010 -0400 ext4: Make fsync sync new parent directories in no-journal mode commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c upstream. Add a new ext4 state to tell us when a file has been newly created; use that state in ext4_sync_file in no-journal mode to tell us when we need to sync the parent directory as well as the inode and data itself. This fixes a problem in which a panic or power failure may lose the entire file even when using fsync, since the parent directory entry is lost. Addresses-Google-Bug: #2480057 Signed-off-by: Frank Mayhar Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit f510dd7e84ae263ee730a5b5db6100c6c03c087f Author: Ben Hutchings Date: Mon May 17 06:00:00 2010 -0400 ext4: Fix compat EXT4_IOC_ADD_GROUP commit 4d92dc0f00a775dc2e1267b0e00befb783902fe7 upstream. struct ext4_new_group_input needs to be converted because u64 has only 32-bit alignment on some 32-bit architectures, notably i386. Signed-off-by: Ben Hutchings Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit d5f1d8239b7bd531171478b5e76053baab657231 Author: Ben Hutchings Date: Mon May 17 05:00:00 2010 -0400 ext4: Conditionally define compat ioctl numbers commit 899ad0cea6ad7ff4ba24b16318edbc3cbbe03fad upstream. It is unnecessary, and in general impossible, to define the compat ioctl numbers except when building the filesystem with CONFIG_COMPAT defined. Signed-off-by: Ben Hutchings Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit e294c97acb0191aff9018e0a0ae9faa5b4c232b1 Author: Dmitry Monakhov Date: Mon May 17 01:00:00 2010 -0400 ext4: restart ext4_ext_remove_space() after transaction restart commit 0617b83fa239db9743a18ce6cc0e556f4d0fd567 upstream. If i_data_sem was internally dropped due to transaction restart, it is necessary to restart path look-up because extents tree was possibly modified by ext4_get_block(). https://bugzilla.kernel.org/show_bug.cgi?id=15827 Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Acked-by: Jan Kara Signed-off-by: Paul Gortmaker commit 4c5490b3020d6e4eb6190dd37073081f4d288599 Author: Theodore Ts'o Date: Mon May 17 00:00:00 2010 -0400 ext4: Clear the EXT4_EOFBLOCKS_FL flag only when warranted commit 786ec7915e530936b9eb2e3d12274145cab7aa7d upstream. Dimitry Monakhov discovered an edge case where it was possible for the EXT4_EOFBLOCKS_FL flag could get cleared unnecessarily. This is true; I have a test case that can be exercised via downloading and decompressing the file: wget ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-testcases/eofblocks-fl-test-case.img.bz2 bunzip2 eofblocks-fl-test-case.img dd if=/dev/zero of=eofblocks-fl-test-case.img bs=1k seek=17925 bs=1k count=1 conv=notrunc However, triggering it in real life is highly unlikely since it requires an extremely fragmented sparse file with a hole in exactly the right place in the extent tree. (It actually took quite a bit of work to generate this test case.) Still, it's nice to get even extreme corner cases to be correct, so this patch makes sure that we don't clear the EXT4_EOFBLOCKS_FL incorrectly even in this corner case. Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 3a58dfe3e599ca8188bd80d982f03ef202860075 Author: Theodore Ts'o Date: Sun May 16 23:00:00 2010 -0400 ext4: Avoid crashing on NULL ptr dereference on a filesystem error commit f70f362b4a6fe47c239dbfb3efc0cc2c10e4f09c upstream. If the EOFBLOCK_FL flag is set when it should not be and the inode is zero length, then eh_entries is zero, and ex is NULL, so dereferencing ex to print ex->ee_block causes a kernel OOPS in ext4_ext_map_blocks(). On top of that, the error message which is printed isn't very helpful. So we fix this by printing something more explanatory which doesn't involve trying to print ex->ee_block. Addresses-Google-Bug: #2655740 Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit bdb69261f2e22b63f5fb2fcbb0de1c3425b61acc Author: Dmitry Monakhov Date: Sun May 16 22:00:00 2010 -0400 ext4: Use bitops to read/modify i_flags in struct ext4_inode_info commit 12e9b892002d9af057655d35b44db8ee9243b0dc upstream. At several places we modify EXT4_I(inode)->i_flags without holding i_mutex (ext4_do_update_inode, ...). These modifications are racy and we can lose updates to i_flags. So convert handling of i_flags to use bitops which are atomic. https://bugzilla.kernel.org/show_bug.cgi?id=15792 Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 607d0c57aaaa1035ab69123ee87deaf9428f9818 Author: Jan Kara Date: Sun May 16 17:00:00 2010 -0400 ext4: Show journal_checksum option commit 39a4bade8c1826b658316d66ee81c09b0a4d7d42 upstream. We failed to show journal_checksum option in /proc/mounts. Fix it. Signed-off-by: Jan Kara Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit c3317c8cb549b98ecff014dcd6f718fefbf4a043 Author: Curt Wohlgemuth Date: Sun May 16 15:00:00 2010 -0400 ext4: check for a good block group before loading buddy pages commit 8a57d9d61a6e361c7bb159dda797672c1df1a691 upstream. This adds a new field in ext4_group_info to cache the largest available block range in a block group; and don't load the buddy pages until *after* we've done a sanity check on the block group. With large allocation requests (e.g., fallocate(), 8MiB) and relatively full partitions, it's easy to have no block groups with a block extent large enough to satisfy the input request length. This currently causes the loop during cr == 0 in ext4_mb_regular_allocator() to load the buddy bitmap pages for EVERY block group. That can be a lot of pages. The patch below allows us to call ext4_mb_good_group() BEFORE we load the buddy pages (although we have check again after we lock the block group). Addresses-Google-Bug: #2578108 Addresses-Google-Bug: #2704453 Signed-off-by: Curt Wohlgemuth Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 508982ae874515f1adff7c650a6067a83f790b5f Author: Nikanth Karthikesan Date: Sun May 16 14:00:00 2010 -0400 ext4: Prevent creation of files larger than RLIMIT_FSIZE using fallocate commit 6d19c42b7cf81c39632b6d4dbc514e8449bcd346 upstream. Currently using posix_fallocate one can bypass an RLIMIT_FSIZE limit and create a file larger than the limit. Add a check for that. Signed-off-by: Nikanth Karthikesan Signed-off-by: Amit Arora Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit ff75dbcebeda9646e7f05e0b99ca715fe9f54870 Author: Curt Wohlgemuth Date: Sun May 16 13:00:00 2010 -0400 ext4: Remove extraneous newlines in ext4_msg() calls commit fbe845ddf368f77f86aa7500f8fd2690f54c66a8 upstream. Addresses-Google-Bug: #2562325 Signed-off-by: Curt Wohlgemuth Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit f4dca0028caf2314d494ff3c9835126a3cf3ee06 Author: Dmitry Monakhov Date: Sun May 16 08:00:00 2010 -0400 ext4: init statistics after journal recovery commit 84061e07c5fbbbf9dc8aef8fb750fc3a2dfc31f3 upstream. Currently block/inode/dir counters initialized before journal was recovered. In fact after journal recovery this info will probably change. And freeblocks it critical for correct delalloc mode accounting. https://bugzilla.kernel.org/show_bug.cgi?id=15768 Signed-off-by: Dmitry Monakhov Acked-by: Jan Kara Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 9f12841d5b19cc45c59560cb2b13267540765ce4 Author: Dmitry Monakhov Date: Sun May 16 07:00:00 2010 -0400 ext4: clean up inode bitmaps manipulation in ext4_free_inode commit d17413c08cd2b1dd2bf2cfdbb0f7b736b2b2b15c upstream. - Reorganize locking scheme to batch two atomic operation in to one. This also allow us to state what healthy group must obey following rule ext4_free_inodes_count(sb, gdp) == ext4_count_free(inode_bitmap, NUM); - Fix possible undefined pointer dereference. - Even if group descriptor stats aren't accessible we have to update inode bitmaps. - Move non-group members update out of group_lock. Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 36e647ecd1a71a982d9c8538e400e1a3bbf1b9cc Author: Dmitry Monakhov Date: Sun May 16 06:00:00 2010 -0400 ext4: Do not zero out uninitialized extents beyond i_size commit 21ca087a3891efab4d45488db8febee474d26c68 upstream. The extents code will sometimes zero out blocks and mark them as initialized instead of splitting an extent into several smaller ones. This optimization however, causes problems if the extent is beyond i_size because fsck will complain if there are uninitialized blocks after i_size as this can not be distinguished from an inode that has an incorrect i_size field. https://bugzilla.kernel.org/show_bug.cgi?id=15742 Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit f33f28de02844deabcf785f3a0208b7c6058ff70 Author: Eric Sandeen Date: Sun May 16 04:00:00 2010 -0400 ext4: don't scan/accumulate more pages than mballoc will allocate commit c445e3e0a5c2804524dec6e55f66d63f6bc5bc3e upstream. There was a bug reported on RHEL5 that a 10G dd on a 12G box had a very, very slow sync after that. At issue was the loop in write_cache_pages scanning all the way to the end of the 10G file, even though the subsequent call to mpage_da_submit_io would only actually write a smallish amt; then we went back to the write_cache_pages loop ... wasting tons of time in calling __mpage_da_writepage for thousands of pages we would just revisit (many times) later. Upstream it's not such a big issue for sys_sync because we get to the loop with a much smaller nr_to_write, which limits the loop. However, talking with Aneesh he realized that fsync upstream still gets here with a very large nr_to_write and we face the same problem. This patch makes mpage_add_bh_to_extent stop the loop after we've accumulated 2048 pages, by setting mpd->io_done = 1; which ultimately causes the write_cache_pages loop to break. Repeating the test with a dirty_ratio of 80 (to leave something for fsync to do), I don't see huge IO performance gains, but the reduction in cpu usage is striking: 80% usage with stock, and 2% with the below patch. Instrumenting the loop in write_cache_pages clearly shows that we are wasting time here. Eventually we need to change mpage_da_map_pages() also submit its I/O to the block layer, subsuming mpage_da_submit_io(), and then change it call ext4_get_blocks() multiple times. Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 603ac51d4b7d2ba57a7ba266a37ab64d6a00fb93 Author: Eric Sandeen Date: Sun May 16 03:00:00 2010 -0400 ext4: stop issuing discards if not supported by device commit a30eec2a8650a77f754e84b2e15f062fe652baa7 upstream. Turn off issuance of discard requests if the device does not support it - similar to the action we take for barriers. This will save a little computation time if a non-discardable device is mounted with -o discard, and also makes it obvious that it's not doing what was asked at mount time ... Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 924a7b8465438c478074ce82321f3d44ef2ba67b Author: Eric Sandeen Date: Sun May 16 02:00:00 2010 -0400 ext4: don't return to userspace after freezing the fs with a mutex held commit 6b0310fbf087ad6e9e3b8392adca97cd77184084 upstream. ext4_freeze() used jbd2_journal_lock_updates() which takes the j_barrier mutex, and then returns to userspace. The kernel does not like this: ================================================ [ BUG: lock held when returning to user space! ] ------------------------------------------------ lvcreate/1075 is leaving the kernel with locks still held! 1 lock held by lvcreate/1075: #0: (&journal->j_barrier){+.+...}, at: [] jbd2_journal_lock_updates+0xe1/0xf0 Use vfs_check_frozen() added to ext4_journal_start_sb() and ext4_force_commit() instead. Addresses-Red-Hat-Bugzilla: #568503 Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 8b2b0f0ea18f2f696fc18eaff89ac3ab0e512150 Author: Dmitry Monakhov Date: Sun May 16 00:00:00 2010 -0400 ext4: fix quota accounting in case of fallocate commit 35121c9860316d7799cea0fbc359a9186e7c2747 upstream. allocated_meta_data is already included in 'used' variable. Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit d14f90a2e15b6312b5c25ec445edecbb77b3cd1c Author: Christian Borntraeger Date: Sat May 15 00:00:00 2010 -0400 ext4: allow defrag (EXT4_IOC_MOVE_EXT) in 32bit compat mode commit b684b2ee9409f2890a8b3aea98525bbe5f84e276 upstream. I have an x86_64 kernel with i386 userspace. e4defrag fails on the EXT4_IOC_MOVE_EXT ioctl because it is not wired up for the compat case. It seems that struct move_extent is compat save, only types with fixed widths are used: { __u32 reserved; /* should be zero */ __u32 donor_fd; /* donor file descriptor */ __u64 orig_start; /* logical start offset in block for orig */ __u64 donor_start; /* logical start offset in block for donor */ __u64 len; /* block length to be moved */ __u64 moved_len; /* moved block length */ }; Lets just wire up EXT4_IOC_MOVE_EXT for the compat case. Signed-off-by: Christian Borntraeger Signed-off-by: "Theodore Ts'o" Reviewed-by: Eric Sandeen CC: Akira Fujita Signed-off-by: Paul Gortmaker commit c486048538a69b481800ce677db2b714625fbfdc Author: Jing Zhang Date: Fri May 14 00:00:00 2010 -0400 ext4: rename ext4_mb_release_desc() to ext4_mb_unload_buddy() commit e39e07fdfd98be8650385f12a7b81d6adc547510 upstream. This function cleans up after ext4_mb_load_buddy(), so the renaming makes the code clearer. Signed-off-by: Jing Zhang Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit ca71bc392dcd163ae06649ad646e3d2e7533d1db Author: Jing Zhang Date: Thu May 13 00:00:00 2010 -0400 ext4: Remove unnecessary call to ext4_get_group_desc() in mballoc commit 62e823a2cba18509ee826d775270e8ef9071b5bc upstream. Signed-off-by: Jing Zhang Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit f0e3a4d72d0d88f3e0de052ed7efd3d24ec12547 Author: Jing Zhang Date: Wed May 12 00:00:00 2010 -0400 ext4: fix memory leaks in error path handling of ext4_ext_zeroout() commit b720303df7352d4a7a1f61e467e0a124913c0d41 upstream. When EIO occurs after bio is submitted, there is no memory free operation for bio, which results in memory leakage. And there is also no check against bio_alloc() for bio. Acked-by: Dave Kleikamp Signed-off-by: Jing Zhang Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 8758d50a6a0286c02af2c73ee93b7b84eaea7e1b Author: Dmitry Monakhov Date: Mon May 10 00:00:00 2010 -0400 ext4: check missed return value in ext4_sync_file() commit 0671e704658b9f26f85e78d51176daa861f955c7 upstream. Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Paul Gortmaker commit 8a711b2f4ccab57589e520787e5dfdd2f3621eb2 Author: Luis R. Rodriguez Date: Mon May 10 15:26:27 2010 -0400 ath5k: drop warning on jumbo frames commit 9637e516d16a58b13f6098cfe899e22963132be3 upstream. Jumbo frames are not supported, and if they are seen it is likely a bogus frame so just silently discard them instead of warning on them all time. Also, instead of dropping them immediately though move the check *after* we check for all sort of frame errors. This should enable us to discard these frames if the hardware picks other bogus items first. Lets see if we still get those jumbo counters increasing still with this. Jumbo frames would happen if we tell hardware we can support a small 802.11 chunks of DMA'd frame, hardware would split RX'd frames into parts and we'd have to reconstruct them in software. This is done with USB due to the bulk size but with ath5k we already provide a good limit to hardware and this should not be happening. This is reported quite often and if it fills the logs then this needs to be addressed and to avoid spurious reports. Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit d7159a6d256020f249e3038577a38280ea4576cf Author: Dan Carpenter Date: Mon May 17 14:42:35 2010 +0100 KEYS: Return more accurate error codes commit 4d09ec0f705cf88a12add029c058b53f288cfaa2 upstream. We were using the wrong variable here so the error codes weren't being returned properly. The original code returns -ENOKEY. Signed-off-by: Dan Carpenter Signed-off-by: David Howells Signed-off-by: James Morris Signed-off-by: Paul Gortmaker commit 47c966822cc5bd388358e5fe06bee8920a02bfff Author: Wei Yongjun Date: Mon May 17 22:51:58 2010 -0700 sctp: fix append error cause to ERROR chunk correctly commit 2e3219b5c8a2e44e0b83ae6e04f52f20a82ac0f2 upstream. commit 5fa782c2f5ef6c2e4f04d3e228412c9b4a4c8809 sctp: Fix skb_over_panic resulting from multiple invalid \ parameter errors (CVE-2010-1173) (v4) cause 'error cause' never be add the the ERROR chunk due to some typo when check valid length in sctp_init_cause_fixed(). Signed-off-by: Wei Yongjun Reviewed-by: Neil Horman Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker