commit 21094cfa0c0cc2ebbef5f5cdb04dbf7675aafb0e Author: Ben Hutchings Date: Wed Sep 12 03:37:38 2012 +0100 Linux 3.2.29 commit a65afe79af5181ca0fca10262908738b4f453b97 Author: Satoru Moriya Date: Tue May 29 15:06:47 2012 -0700 mm: avoid swapping out with swappiness==0 commit fe35004fbf9eaf67482b074a2e032abb9c89b1dd upstream. Sometimes we'd like to avoid swapping out anonymous memory. In particular, avoid swapping out pages of important process or process groups while there is a reasonable amount of pagecache on RAM so that we can satisfy our customers' requirements. OTOH, we can control how aggressive the kernel will swap memory pages with /proc/sys/vm/swappiness for global and /sys/fs/cgroup/memory/memory.swappiness for each memcg. But with current reclaim implementation, the kernel may swap out even if we set swappiness=0 and there is pagecache in RAM. This patch changes the behavior with swappiness==0. If we set swappiness==0, the kernel does not swap out completely (for global reclaim until the amount of free pages and filebacked pages in a zone has been reduced to something very very small (nr_free + nr_filebacked < high watermark)). Signed-off-by: Satoru Moriya Acked-by: Minchan Kim Reviewed-by: Rik van Riel Acked-by: Jerome Marchand Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: - Adjust context - vmscan_swappiness() does not have a zone parameter] Signed-off-by: Ben Hutchings commit 4bddad580a7b4d023a981e2cbdf0c9e3837f6505 Author: Phillip Lougher Date: Mon Jan 2 17:47:14 2012 +0000 Squashfs: fix mount time sanity check for corrupted superblock commit cc37f75a9ffbbfcb1c3297534f293c8284e3c5a6 upstream. A Squashfs filesystem containing nothing but an empty directory, although unusual and ultimately pointless, is still valid. The directory_table >= next_table sanity check rejects these filesystems as invalid because the directory_table is empty and equal to next_table. Signed-off-by: Phillip Lougher Signed-off-by: Ben Hutchings commit b64c7d340e491c5bbcd62bc5617c49f7ee8693e2 Author: AceLan Kao Date: Wed Jul 4 15:20:14 2012 +0800 asus-nb-wmi: add some video toggle keys commit 3766054fff4af1b58a1440a284907887f4d2e8be upstream. There are some new video switch keys that used by newer machines. 0xA0 - SDSP HDMI only 0xA1 - SDSP LCD + HDMI 0xA2 - SDSP CRT + HDMI 0xA3 - SDSP TV + HDMI But in Linux, there is no suitable userspace application to handle this, so, mapping them all to KEY_SWITCHVIDEOMODE. Signed-off-by: AceLan Kao Signed-off-by: Matthew Garrett Signed-off-by: Ben Hutchings commit 2a53885eadf4d5355a6ea4d4b156d1be5d7e9a80 Author: Trond Myklebust Date: Wed Aug 22 16:08:17 2012 -0400 NFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate Fix the following Oops in 3.5.1: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: [] nfs_lookup_revalidate+0x2d/0x480 [nfs] PGD 337c63067 PUD 0 Oops: 0000 [#1] SMP CPU 5 Modules linked in: nfs fscache nfsd lockd nfs_acl auth_rpcgss sunrpc af_packet binfmt_misc cpufreq_conservative cpufreq_userspace cpufreq_powersave dm_mod acpi_cpufreq mperf coretemp gpio_ich kvm_intel joydev kvm ioatdma hid_generic igb lpc_ich i7core_edac edac_core ptp serio_raw dca pcspkr i2c_i801 mfd_core sg pps_core usbhid crc32c_intel microcode button autofs4 uhci_hcd ttm drm_kms_helper drm i2c_algo_bit sysimgblt sysfillrect syscopyarea ehci_hcd usbcore usb_common scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh edd fan ata_piix thermal processor thermal_sys Pid: 30431, comm: java Not tainted 3.5.1-2-default #1 Supermicro X8DTT/X8DTT RIP: 0010:[] [] nfs_lookup_revalidate+0x2d/0x480 [nfs] RSP: 0018:ffff8801b418bd38 EFLAGS: 00010292 RAX: 00000000fffffff6 RBX: ffff88032016d800 RCX: 0000000000000020 RDX: ffffffff00000000 RSI: 0000000000000000 RDI: ffff8801824a7b00 RBP: ffff8801b418bdf8 R08: 7fffff0034323030 R09: fffffffff04c03ed R10: ffff8801824a7b00 R11: 0000000000000002 R12: ffff8801824a7b00 R13: ffff8801824a7b00 R14: 0000000000000000 R15: ffff8803201725d0 FS: 00002b53a46cb700(0000) GS:ffff88033fc20000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 000000020a426000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process java (pid: 30431, threadinfo ffff8801b418a000, task ffff8801b5d20600) Stack: ffff8801b418be44 ffff88032016d800 ffff8801b418bdf8 0000000000000000 ffff8801824a7b00 ffff8801b418bdd7 ffff8803201725d0 ffffffff8116a9c0 ffff8801b5c38dc0 0000000000000007 ffff88032016d800 0000000000000000 Call Trace: [] lookup_dcache+0x80/0xe0 [] __lookup_hash+0x23/0x90 [] lookup_one_len+0xc5/0x100 [] nfs_sillyrename+0xe3/0x210 [nfs] [] vfs_unlink.part.25+0x7f/0xe0 [] do_unlinkat+0x1ac/0x1d0 [] system_call_fastpath+0x16/0x1b [<00002b5348b5f527>] 0x2b5348b5f526 Code: ec 38 b8 f6 ff ff ff 4c 89 64 24 18 4c 89 74 24 28 49 89 fc 48 89 5c 24 08 48 89 6c 24 10 49 89 f6 4c 89 6c 24 20 4c 89 7c 24 30 46 38 40 0f 85 d1 00 00 00 e8 c4 c4 df e0 48 8b 58 30 49 89 RIP [] nfs_lookup_revalidate+0x2d/0x480 [nfs] RSP CR2: 0000000000000038 ---[ end trace 845113ed191985dd ]--- This Oops affects 3.5 kernels and older, and is due to lookup_one_len() calling down to the dentry revalidation code with a NULL pointer to struct nameidata. It is fixed upstream by commit 0b728e1911c (stop passing nameidata * to ->d_revalidate()) Reported-by: Richard Ems Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit fc1dd47cd57da67691c13e1f2d3cde814d857ebe Author: Christopher Brannon Date: Sat Jun 16 16:55:20 2012 -0500 Staging: speakup: fix an improperly-declared variable. commit 4ea418b8b2fa8a70d0fcc8231b65e67b3a72984b upstream. A local static variable was declared as a pointer to a string constant. We're assigning to the underlying memory, so it needs to be an array instead. Signed-off-by: Christopher Brannon Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 4422e6fe13eff3fc4337dedc76f6830e1a3b4e1a Author: Jason Wessel Date: Sun Aug 12 07:16:43 2012 -0500 pmac_zilog,kdb: Fix console poll hook to return instead of loop commit 38f8eefccf3a23c4058a570fa2938a4f553cf8e0 upstream. kdb <-> kgdb transitioning does not work properly with this UART driver because the get character routine loops indefinitely as opposed to returning NO_POLL_CHAR per the expectation of the KDB I/O driver API. The symptom is a kernel hang when trying to switch debug modes. Cc: Alan Cox Signed-off-by: Jason Wessel Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 7a42c228a86c720bced4f0a651ad86f89a8d01b3 Author: Lionel Vaux Date: Sun Jul 22 11:32:20 2012 +0200 HID: add support for Cypress barcode scanner 04B4:ED81 commit 76c9d8fe2c7fc34ffc387d8022c5828d6ff9df48 upstream. Add yet another device to the list of Cypress barcode scanners needing the CP_RDESC_SWAPPED_MIN_MAX quirk. Signed-off-by: Lionel Vaux (iouri) Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings commit 95964784565aeac65d1c03fc7b2443f8f7102340 Author: Asias He Date: Fri May 25 10:34:48 2012 +0800 virtio-blk: Reset device after blk_cleanup_queue() commit 483001c765af6892b3fc3726576cb42f17d1d6b5 upstream. blk_cleanup_queue() will call blk_drian_queue() to drain all the requests before queue DEAD marking. If we reset the device before blk_cleanup_queue() the drain would fail. 1) if the queue is stopped in do_virtblk_request() because device is full, the q->request_fn() will not be called. blk_drain_queue() { while(true) { ... if (!list_empty(&q->queue_head)) __blk_run_queue(q) { if (queue is not stoped) q->request_fn() } ... } } Do no reset the device before blk_cleanup_queue() gives the chance to start the queue in interrupt handler blk_done(). 2) In commit b79d866c8b7014a51f611a64c40546109beaf24a, We abort requests dispatched to driver before blk_cleanup_queue(). There is a race if requests are dispatched to driver after the abort and before the queue DEAD mark. To fix this, instead of aborting the requests explicitly, we can just reset the device after after blk_cleanup_queue so that the device can complete all the requests before queue DEAD marking in the drain process. Cc: Rusty Russell Cc: virtualization@lists.linux-foundation.org Cc: kvm@vger.kernel.org Signed-off-by: Asias He Acked-by: Michael S. Tsirkin Signed-off-by: Rusty Russell Signed-off-by: Ben Hutchings commit 88963fd6c66bf065c6e9c36f1f5de4dff30624a1 Author: Asias He Date: Fri May 25 10:34:47 2012 +0800 virtio-blk: Call del_gendisk() before disable guest kick commit 02e2b124943648fba0a2ccee5c3656a5653e0151 upstream. del_gendisk() might not return due to failing to remove the /sys/block/vda/serial sysfs entry when another thread (udev) is trying to read it. virtblk_remove() vdev->config->reset() : guest will not kick us through interrupt del_gendisk() device_del() kobject_del(): got stuck, sysfs entry ref count non zero sysfs_open_file(): user space process read /sys/block/vda/serial sysfs_get_active() : got sysfs entry ref count dev_attr_show() virtblk_serial_show() blk_execute_rq() : got stuck, interrupt is disabled request cannot be finished This patch fixes it by calling del_gendisk() before we disable guest's interrupt so that the request sent in virtblk_serial_show() will be finished and del_gendisk() will success. This fixes another race in hot-unplug process. It is save to call del_gendisk(vblk->disk) before flush_work(&vblk->config_work) which might access vblk->disk, because vblk->disk is not freed until put_disk(vblk->disk). Cc: virtualization@lists.linux-foundation.org Cc: kvm@vger.kernel.org Signed-off-by: Asias He Acked-by: Michael S. Tsirkin Signed-off-by: Rusty Russell Signed-off-by: Ben Hutchings commit e5000b33460e5008a3a189dc2107d274d8096eff Author: Asias He Date: Fri May 4 20:22:04 2012 +0800 virtio-blk: Fix hot-unplug race in remove method commit b79d866c8b7014a51f611a64c40546109beaf24a upstream. If we reset the virtio-blk device before the requests already dispatched to the virtio-blk driver from the block layer are finised, we will stuck in blk_cleanup_queue() and the remove will fail. blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued before DEAD marking. However it will never success if the device is already stopped. We'll have q->in_flight[] > 0, so the drain will not finish. How to reproduce the race: 1. hot-plug a virtio-blk device 2. keep reading/writing the device in guest 3. hot-unplug while the device is busy serving I/O Test: ~1000 rounds of hot-plug/hot-unplug test passed with this patch. Changes in v3: - Drop blk_abort_queue and blk_abort_request - Use __blk_end_request_all to complete request dispatched to driver Changes in v2: - Drop req_in_flight - Use virtqueue_detach_unused_buf to get request dispatched to driver Signed-off-by: Asias He Signed-off-by: Rusty Russell Signed-off-by: Ben Hutchings commit 788c8de383e3c59df49126f95343eed0cf1733ea Author: Asias He Date: Fri Mar 30 11:24:10 2012 +0800 virtio_blk: Drop unused request tracking list commit f65ca1dc6a8c81c6bd72297d4399ec5f4c1f3a01 upstream. Benchmark shows small performance improvement on fusion io device. Before: seq-read : io=1,024MB, bw=19,982KB/s, iops=39,964, runt= 52475msec seq-write: io=1,024MB, bw=20,321KB/s, iops=40,641, runt= 51601msec rnd-read : io=1,024MB, bw=15,404KB/s, iops=30,808, runt= 68070msec rnd-write: io=1,024MB, bw=14,776KB/s, iops=29,552, runt= 70963msec After: seq-read : io=1,024MB, bw=20,343KB/s, iops=40,685, runt= 51546msec seq-write: io=1,024MB, bw=20,803KB/s, iops=41,606, runt= 50404msec rnd-read : io=1,024MB, bw=16,221KB/s, iops=32,442, runt= 64642msec rnd-write: io=1,024MB, bw=15,199KB/s, iops=30,397, runt= 68991msec Signed-off-by: Asias He Signed-off-by: Rusty Russell [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 0984c4c423da091cf8221e74b030c116d865dacf Author: Michael S. Tsirkin Date: Thu Jan 12 15:44:44 2012 +1030 virtio_blk: fix config handler race commit 4678d6f970c2f7c0cbfefc0cc666432d153b321b upstream. Fix a theoretical race related to config work handler: a config interrupt might happen after we flush config work but before we reset the device. It will then cause the config work to run during or after reset. Two problems with this: - if this runs after device is gone we will get use after free - access of config while reset is in progress is racy (as layout is changing). As a solution 1. flush after reset when we know there will be no more interrupts 2. add a flag to disable config access before reset Signed-off-by: Michael S. Tsirkin Signed-off-by: Rusty Russell Signed-off-by: Ben Hutchings commit d9033bcc75a39d79411c722502665ccaab0dd4d6 Author: Tony Luck Date: Fri Jul 20 13:15:20 2012 -0700 dmi: Feed DMI table to /dev/random driver commit d114a33387472555188f142ed8e98acdb8181c6d upstream. Send the entire DMI (SMBIOS) table to the /dev/random driver to help seed its pools. Signed-off-by: Tony Luck Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit 86946487268d34e8c057e498ab01b03cc085874f Author: Tony Luck Date: Mon Jul 23 09:47:57 2012 -0700 random: Add comment to random_initialize() commit cbc96b7594b5691d61eba2db8b2ea723645be9ca upstream. Many platforms have per-machine instance data (serial numbers, asset tags, etc.) squirreled away in areas that are accessed during early system bringup. Mixing this data into the random pools has a very high value in providing better random data, so we should allow (and even encourage) architecture code to call add_device_randomness() from the setup_arch() paths. However, this limits our options for internal structure of the random driver since random_initialize() is not called until long after setup_arch(). Add a big fat comment to rand_initialize() spelling out this requirement. Suggested-by: Theodore Ts'o Signed-off-by: Tony Luck Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit 946887406e6d559a4a52fdbd836a85511b4f6486 Author: Theodore Ts'o Date: Wed Jul 4 11:32:48 2012 -0400 MAINTAINERS: Theodore Ts'o is taking over the random driver commit 330e0a01d54c2b8606c56816f99af6ebc58ec92c upstream. Matt Mackall stepped down as the /dev/random driver maintainer last year, so Theodore Ts'o is taking back the /dev/random driver. Cc: Matt Mackall Signed-off-by: "Theodore Ts'o" Signed-off-by: Ben Hutchings commit a457fb130726356e758eeadf230b21993986d0ab Author: Mathieu Desnoyers Date: Thu Apr 12 12:49:12 2012 -0700 drivers/char/random.c: fix boot id uniqueness race commit 44e4360fa3384850d65dd36fb4e6e5f2f112709b upstream. /proc/sys/kernel/random/boot_id can be read concurrently by userspace processes. If two (or more) user-space processes concurrently read boot_id when sysctl_bootid is not yet assigned, a race can occur making boot_id differ between the reads. Because the whole point of the boot id is to be unique across a kernel execution, fix this by protecting this operation with a spinlock. Given that this operation is not frequently used, hitting the spinlock on each call should not be an issue. Signed-off-by: Mathieu Desnoyers Cc: "Theodore Ts'o" Cc: Matt Mackall Signed-off-by: Eric Dumazet Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 39b78b60059ba51c89008f93139719b489639124 Author: Szymon Janc Date: Fri Jun 8 11:33:33 2012 +0200 Bluetooth: Fix using uninitialized option in RFCMode commit 8f321f853ea33330c7141977cd34804476e2e07e upstream. If remote device sends bogus RFC option with invalid length, undefined options values are used. Fix this by using defaults when remote misbehaves. This also fixes the following warning reported by gcc 4.7.0: net/bluetooth/l2cap_core.c: In function 'l2cap_config_rsp': net/bluetooth/l2cap_core.c:3302:13: warning: 'rfc.max_pdu_size' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.max_pdu_size' was declared here net/bluetooth/l2cap_core.c:3298:25: warning: 'rfc.monitor_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.monitor_timeout' was declared here net/bluetooth/l2cap_core.c:3297:25: warning: 'rfc.retrans_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.retrans_timeout' was declared here net/bluetooth/l2cap_core.c:3295:2: warning: 'rfc.mode' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.mode' was declared here Signed-off-by: Szymon Janc Signed-off-by: Gustavo Padovan Signed-off-by: Ben Hutchings commit 46d271aef8236ed77b9d17051590886c4677e882 Author: Hugh Dickins Date: Thu Aug 23 12:17:36 2012 +0200 block: replace __getblk_slow misfix by grow_dev_page fix commit 676ce6d5ca3098339c028d44fe0427d1566a4d2d upstream. Commit 91f68c89d8f3 ("block: fix infinite loop in __getblk_slow") is not good: a successful call to grow_buffers() cannot guarantee that the page won't be reclaimed before the immediate next call to __find_get_block(), which is why there was always a loop there. Yesterday I got "EXT4-fs error (device loop0): __ext4_get_inode_loc:3595: inode #19278: block 664: comm cc1: unable to read itable block" on console, which pointed to this commit. I've been trying to bisect for weeks, why kbuild-on-ext4-on-loop-on-tmpfs sometimes fails from a missing header file, under memory pressure on ppc G5. I've never seen this on x86, and I've never seen it on 3.5-rc7 itself, despite that commit being in there: bisection pointed to an irrelevant pinctrl merge, but hard to tell when failure takes between 18 minutes and 38 hours (but so far it's happened quicker on 3.6-rc2). (I've since found such __ext4_get_inode_loc errors in /var/log/messages from previous weeks: why the message never appeared on console until yesterday morning is a mystery for another day.) Revert 91f68c89d8f3, restoring __getblk_slow() to how it was (plus a checkpatch nitfix). Simplify the interface between grow_buffers() and grow_dev_page(), and avoid the infinite loop beyond end of device by instead checking init_page_buffers()'s end_block there (I presume that's more efficient than a repeated call to blkdev_max_block()), returning -ENXIO to __getblk_slow() in that case. And remove akpm's ten-year-old "__getblk() cannot fail ... weird" comment, but that is worrying: are all users of __getblk() really now prepared for a NULL bh beyond end of device, or will some oops?? Signed-off-by: Hugh Dickins Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit 5835d2dc7e82fcbe61ebc84c8a1ac47af3759144 Author: Glauber Costa Date: Wed Apr 25 16:01:48 2012 -0700 fs/buffer.c: remove BUG() in possible but rare condition commit 61065a30af8df4b8989c2ac7a1f4b4034e4df2d5 upstream. While stressing the kernel with with failing allocations today, I hit the following chain of events: alloc_page_buffers(): bh = alloc_buffer_head(GFP_NOFS); if (!bh) goto no_grow; <= path taken grow_dev_page(): bh = alloc_page_buffers(page, size, 0); if (!bh) goto failed; <= taken, consequence of the above and then the failed path BUG()s the kernel. The failure is inserted a litte bit artificially, but even then, I see no reason why it should be deemed impossible in a real box. Even though this is not a condition that we expect to see around every time, failed allocations are expected to be handled, and BUG() sounds just too much. As a matter of fact, grow_dev_page() can return NULL just fine in other circumstances, so I propose we just remove it, then. Signed-off-by: Glauber Costa Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 9bf9e4d2dd0ff4b80defa1d705ea65f3789c9ff2 Author: Alexandre Bounine Date: Tue Aug 21 16:16:12 2012 -0700 rapidio/tsi721: fix unused variable compiler warning commit 9a9a9a7adafe62a34de8b4fb48936c1c5f9bafa5 upstream. Fix unused variable compiler warning when built with CONFIG_RAPIDIO_DEBUG option off. This patch is applicable to kernel versions starting from v3.2 Signed-off-by: Alexandre Bounine Cc: Matt Porter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 61ee0199cfdfafa938150a67b490d61513a67064 Author: Alexandre Bounine Date: Tue Aug 21 16:16:11 2012 -0700 rapidio/tsi721: fix inbound doorbell interrupt handling commit 3670e7e12e582c6d67761275d148171feb7a9004 upstream. Make sure that there is no doorbell messages left behind due to disabled interrupts during inbound doorbell processing. The most common case for this bug is loss of rionet JOIN messages in systems with three or more rionet participants and MSI or MSI-X enabled. As result, requests for packet transfers may finish with "destination unreachable" error message. This patch is applicable to kernel versions starting from v3.2. Signed-off-by: Alexandre Bounine Cc: Matt Porter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 05621c97f432220a529abd1356b4b902a8e3aecd Author: Atsushi Nemoto Date: Tue Aug 21 16:16:10 2012 -0700 drivers/rtc/rtc-rs5c348.c: fix hour decoding in 12-hour mode commit 7dbfb315b2aaef0a115765946bf3026d074c33a7 upstream. Correct the offset by subtracting 20 from tm_hour before taking the modulo 12. [ "Why 20?" I hear you ask. Or at least I did. Here's the reason why: RS5C348_BIT_PM is 32, and is - stupidly - included in the RS5C348_HOURS_MASK define. So it's really subtracting out that bit to get "hour+12". But then because it does things modulo 12, it needs to add the 12 in again afterwards anyway. This code is confused. It would be much clearer if RS5C348_HOURS_MASK just didn't include the RS5C348_BIT_PM bit at all, then it wouldn't need to do the silly subtract either. Whatever. It's all just math, the end result is the same. - Linus ] Reported-by: James Nute Tested-by: James Nute Signed-off-by: Atsushi Nemoto Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 33da4c1e160850964ea658643ea4f06e508c0d2e Author: Robin Holt Date: Tue Aug 21 16:16:02 2012 -0700 drivers/misc/sgi-xp/xpc_uv.c: SGI XPC fails to load when cpu 0 is out of IRQ resources commit 7838f994b4fceff24c343f4e26a6cf4393869579 upstream. On many of our larger systems, CPU 0 has had all of its IRQ resources consumed before XPC loads. Worst cases on machines with multiple 10 GigE cards and multiple IB cards have depleted the entire first socket of IRQs. This patch makes selecting the node upon which IRQs are allocated (as well as all the other GRU Message Queue structures) specifiable as a module load param and has a default behavior of searching all nodes/cpus for an available resources. [akpm@linux-foundation.org: fix build: include cpu.h and module.h] Signed-off-by: Robin Holt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit cf727a57a1b5ba1d40e4d59a67ec7243c8f9d94a Author: Michal Hocko Date: Tue Aug 21 16:15:52 2012 -0700 mm: hugetlbfs: correctly populate shared pmd commit eb48c071464757414538c68a6033c8f8c15196f8 upstream. Each page mapped in a process's address space must be correctly accounted for in _mapcount. Normally the rules for this are straightforward but hugetlbfs page table sharing is different. The page table pages at the PMD level are reference counted while the mapcount remains the same. If this accounting is wrong, it causes bugs like this one reported by Larry Woodman: kernel BUG at mm/filemap.c:135! invalid opcode: 0000 [#1] SMP CPU 22 Modules linked in: bridge stp llc sunrpc binfmt_misc dcdbas microcode pcspkr acpi_pad acpi] Pid: 18001, comm: mpitest Tainted: G W 3.3.0+ #4 Dell Inc. PowerEdge R620/07NDJ2 RIP: 0010:[] [] __delete_from_page_cache+0x15d/0x170 Process mpitest (pid: 18001, threadinfo ffff880428972000, task ffff880428b5cc20) Call Trace: delete_from_page_cache+0x40/0x80 truncate_hugepages+0x115/0x1f0 hugetlbfs_evict_inode+0x18/0x30 evict+0x9f/0x1b0 iput_final+0xe3/0x1e0 iput+0x3e/0x50 d_kill+0xf8/0x110 dput+0xe2/0x1b0 __fput+0x162/0x240 During fork(), copy_hugetlb_page_range() detects if huge_pte_alloc() shared page tables with the check dst_pte == src_pte. The logic is if the PMD page is the same, they must be shared. This assumes that the sharing is between the parent and child. However, if the sharing is with a different process entirely then this check fails as in this diagram: parent | ------------>pmd src_pte----------> data page ^ other--------->pmd--------------------| ^ child-----------| dst_pte For this situation to occur, it must be possible for Parent and Other to have faulted and failed to share page tables with each other. This is possible due to the following style of race. PROC A PROC B copy_hugetlb_page_range copy_hugetlb_page_range src_pte == huge_pte_offset src_pte == huge_pte_offset !src_pte so no sharing !src_pte so no sharing (time passes) hugetlb_fault hugetlb_fault huge_pte_alloc huge_pte_alloc huge_pmd_share huge_pmd_share LOCK(i_mmap_mutex) find nothing, no sharing UNLOCK(i_mmap_mutex) LOCK(i_mmap_mutex) find nothing, no sharing UNLOCK(i_mmap_mutex) pmd_alloc pmd_alloc LOCK(instantiation_mutex) fault UNLOCK(instantiation_mutex) LOCK(instantiation_mutex) fault UNLOCK(instantiation_mutex) These two processes are not poing to the same data page but are not sharing page tables because the opportunity was missed. When either process later forks, the src_pte == dst pte is potentially insufficient. As the check falls through, the wrong PTE information is copied in (harmless but wrong) and the mapcount is bumped for a page mapped by a shared page table leading to the BUG_ON. This patch addresses the issue by moving pmd_alloc into huge_pmd_share which guarantees that the shared pud is populated in the same critical section as pmd. This also means that huge_pte_offset test in huge_pmd_share is serialized correctly now which in turn means that the success of the sharing will be higher as the racing tasks see the pud and pmd populated together. Race identified and changelog written mostly by Mel Gorman. {akpm@linux-foundation.org: attempt to make the huge_pmd_share() comment comprehensible, clean up coding style] Reported-by: Larry Woodman Tested-by: Larry Woodman Reviewed-by: Mel Gorman Signed-off-by: Michal Hocko Reviewed-by: Rik van Riel Cc: David Gibson Cc: Ken Chen Cc: Cong Wang Cc: Hillf Danton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit e371958b32716cd73d5f3fa01778de9c79fa550b Author: Stephen M. Cameron Date: Tue Aug 21 16:15:49 2012 -0700 cciss: fix incorrect scsi status reporting commit b0cf0b118c90477d1a6811f2cd2307f6a5578362 upstream. Delete code which sets SCSI status incorrectly as it's already been set correctly above this incorrect code. The bug was introduced in 2009 by commit b0e15f6db111 ("cciss: fix typo that causes scsi status to be lost.") Signed-off-by: Stephen M. Cameron Reported-by: Roel van Meer Tested-by: Roel van Meer Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 94fb24693f5fff6ddbbfe2efd93be7f24e47e669 Author: Dave Airlie Date: Tue Aug 21 16:29:47 2012 +1000 fbcon: fix race condition between console lock and cursor timer (v1.1) commit d8636a2717bb3da2a7ce2154bf08de90bb8c87b0 upstream. So we've had a fair few reports of fbcon handover breakage between efi/vesafb and i915 surface recently, so I dedicated a couple of days to finding the problem. Essentially the last thing we saw was the conflicting framebuffer message and that was all. So after much tracing with direct netconsole writes (printks under console_lock not so useful), I think I found the race. Thread A (driver load) Thread B (timer thread) unbind_con_driver -> | bind_con_driver -> | vc->vc_sw->con_deinit -> | fbcon_deinit -> | console_lock() | | | | fbcon_flashcursor timer fires | console_lock() <- blocked for A | | fbcon_del_cursor_timer -> del_timer_sync (BOOM) Of course because all of this is under the console lock, we never see anything, also since we also just unbound the active console guess what we never see anything. Hopefully this fixes the problem for anyone seeing vesafb->kms driver handoff. v1.1: add comment suggestion from Alan. Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 2744f4e762141d0b1233f962ebe706d60cd460d2 Author: Alex Deucher Date: Tue Aug 21 09:55:01 2012 -0400 Revert "drm/radeon: fix bo creation retry path" commit 676bc2e1e4f9072f7a640d5b7c99ffdf9709a6e7 upstream. This reverts commit d1c7871ddb1f588b8eb35affd9ee1a3d5e11cd0c. ttm_bo_init() destroys the BO on failure. So this patch makes the retry path work with freed memory. This ends up causing kernel panics when this path is hit. Signed-off-by: Alex Deucher [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 9d16d84d61a215bfce9a342cb4eb7347dae3e4c3 Author: J. Bruce Fields Date: Fri Aug 17 17:31:53 2012 -0400 svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping commit d10f27a750312ed5638c876e4bd6aa83664cccd8 upstream. The rpc server tries to ensure that there will be room to send a reply before it receives a request. It does this by tracking, in xpt_reserved, an upper bound on the total size of the replies that is has already committed to for the socket. Currently it is adding in the estimate for a new reply *before* it checks whether there is space available. If it finds that there is not space, it then subtracts the estimate back out. This may lead the subsequent svc_xprt_enqueue to decide that there is space after all. The results is a svc_recv() that will repeatedly return -EAGAIN, causing server threads to loop without doing any actual work. Reported-by: Michael Tokarev Tested-by: Michael Tokarev Signed-off-by: J. Bruce Fields Signed-off-by: Ben Hutchings commit 1057f77016b40d967d8527349ebb881311017df7 Author: J. Bruce Fields Date: Mon Aug 20 16:04:40 2012 -0400 svcrpc: sends on closed socket should stop immediately commit f06f00a24d76e168ecb38d352126fd203937b601 upstream. svc_tcp_sendto sets XPT_CLOSE if we fail to transmit the entire reply. However, the XPT_CLOSE won't be acted on immediately. Meanwhile other threads could send further replies before the socket is really shut down. This can manifest as data corruption: for example, if a truncated read reply is followed by another rpc reply, that second reply will look to the client like further read data. Symptoms were data corruption preceded by svc_tcp_sendto logging something like kernel: rpc-srv/tcp: nfsd: sent only 963696 when sending 1048708 bytes - shutting down socket Reported-by: Malahal Naineni Tested-by: Malahal Naineni Signed-off-by: J. Bruce Fields Signed-off-by: Ben Hutchings commit b4d810559cd5e73751adbd9cf05034bb8775a691 Author: J. Bruce Fields Date: Thu Aug 9 18:12:28 2012 -0400 svcrpc: fix BUG() in svc_tcp_clear_pages commit be1e44441a560c43c136a562d49a1c9623c91197 upstream. Examination of svc_tcp_clear_pages shows that it assumes sk_tcplen is consistent with sk_pages[] (in particular, sk_pages[n] can't be NULL if sk_tcplen would lead us to expect n pages of data). svc_tcp_restore_pages zeroes out sk_pages[] while leaving sk_tcplen. This is OK, since both functions are serialized by XPT_BUSY. However, that means the inconsistency must be repaired before dropping XPT_BUSY. Therefore we should be ensuring that svc_tcp_save_pages repairs the problem before exiting svc_tcp_recv_record on error. Symptoms were a BUG() in svc_tcp_clear_pages. Signed-off-by: J. Bruce Fields Signed-off-by: Ben Hutchings commit 6e6abc0339f25e0f45d85fec27aef1e8fe358897 Author: Al Viro Date: Mon Aug 20 15:28:00 2012 +0100 vfs: missed source of ->f_pos races commit 0e665d5d1125f9f4ccff56a75e814f10f88861a2 upstream. compat_sys_{read,write}v() need the same "pass a copy of file->f_pos" thing as sys_{read,write}{,v}(). Signed-off-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit a2810e5462e83ee74a5d20b68b39daa1402a4e5e Author: Trond Myklebust Date: Mon Aug 20 12:42:15 2012 -0400 NFSv3: Ensure that do_proc_get_root() reports errors correctly commit 086600430493e04b802bee6e5b3ce0458e4eb77f upstream. If the rpc call to NFS3PROC_FSINFO fails, then we need to report that error so that the mount fails. Otherwise we can end up with a superblock with completely unusable values for block sizes, maxfilesize, etc. Reported-by: Yuanming Chen Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit 61ebf0a926149cc161131470cf848cb70b3d6fe6 Author: Alex Deucher Date: Thu Aug 16 15:39:09 2012 -0400 drm/radeon: split ATRM support out from the ATPX handler (v3) commit c61e2775873f603148e8e998a938721b7d222d24 upstream. There are systems that use ATRM, but not ATPX. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41265 V2: fix #ifdefs as per Greg's comments V3: fix it harder Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit 4472ab2724f5d9caaa6d9135944a052cff916545 Author: Dave Airlie Date: Thu Feb 2 15:25:16 2012 +0000 drm/radeon: fix use after free in ATRM bios reading code. commit de47a9cd62771e3e78954d855d2304fbad4c5a44 upstream. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=45503 Reported-and-Debugged-by: mlambda@gmail.com Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 122d1fd84d1d67a466877df35a9a9c6ca531ea2e Author: Igor Murzov Date: Sun Jan 22 18:47:28 2012 +0400 drm/radeon: finish getting bios earlier commit 211fa4fc4e13492151e698d92b0dff56b29928ec upstream. Return a number of bytes read in radeon_atrm_get_bios_chunk() and properly check this value in radeon_atrm_get_bios(). If radeon_atrm_get_bios_chunk() read less bytes then were requested, it means that it finished reading bios data. Prior to this patch, condition in radeon_atrm_get_bios() was always equivalent to "if (ATRM_BIOS_PAGE <= 0)", so it was always false, thus radeon_atrm_get_bios() was trying to read past the bios data wasting boot time. On my lenovo ideapad u455 laptop this patch drops bios reading time from ~5.5s to ~1.5s. Signed-off-by: Igor Murzov Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 234fc21d076b76f895dbce5b2473828cbe6c1839 Author: Igor Murzov Date: Sun Jan 22 18:43:25 2012 +0400 drm/radeon: fix invalid memory access in radeon_atrm_get_bios() commit a3f83ab1a717c0e6c2f59a4cfdaa10707cc35c55 upstream. At a boot time I observed following bug: BUG: unable to handle kernel paging request at ffff8800a4244000 IP: [] memcpy+0xb/0x120 PGD 1816063 PUD 1fe7d067 PMD 1ff9f067 PTE 80000000a4244160 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC CPU 0 Modules linked in: btusb bluetooth brcmsmac brcmutil crc8 cordic b43 radeon(+) mac80211 cfg80211 ttm ohci_hcd drm_kms_helper rfkill drm ssb agpgart mmc_core sp5100_tco video battery ac thermal processor rtc_cmos thermal_sys snd_hda_codec_hdmi joydev snd_hda_codec_conexant button bcma pcmcia snd_hda_intel snd_hda_codec snd_hwdep snd_pcm shpchp pcmcia_core k8temp snd_timer atl1c snd psmouse hwmon i2c_piix4 i2c_algo_bit soundcore evdev i2c_core ehci_hcd sg serio_raw snd_page_alloc loop btrfs Pid: 1008, comm: modprobe Not tainted 3.3.0-rc1 #21 LENOVO 20046 /AMD CRB RIP: 0010:[] [] memcpy+0xb/0x120 RSP: 0018:ffff8800aa72db00 EFLAGS: 00010246 RAX: ffff8800a4150000 RBX: 0000000000001000 RCX: 0000000000000087 RDX: 0000000000000000 RSI: ffff8800a4244000 RDI: ffff8800a4150bc8 RBP: ffff8800aa72db78 R08: 0000000000000010 R09: ffffffff8174bbec R10: ffffffff812ee010 R11: 0000000000000001 R12: 0000000000001000 R13: 0000000000010000 R14: ffff8800a4140000 R15: ffff8800aaba1800 FS: 00007ff9a3bd4720(0000) GS:ffff8800afa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff8800a4244000 CR3: 00000000a9c18000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process modprobe (pid: 1008, threadinfo ffff8800aa72c000, task ffff8800aa0e4000) Stack: ffffffffa04e7c7b 0000000000000001 0000000000010000 ffff8800aa72db28 ffffffff00000001 0000000000001000 ffffffff8113cbef 0000000000000020 ffff8800a4243420 ffff880000000002 ffff8800aa72db08 ffff8800a9d42000 Call Trace: [] ? radeon_atrm_get_bios_chunk+0x8b/0xd0 [radeon] [] ? kmalloc_order_trace+0x3f/0xb0 [] radeon_get_bios+0x68/0x2f0 [radeon] [] rv770_init+0x40/0x280 [radeon] [] radeon_device_init+0x560/0x600 [radeon] [] radeon_driver_load_kms+0xaf/0x170 [radeon] [] drm_get_pci_dev+0x18e/0x2c0 [drm] [] radeon_pci_probe+0xad/0xb5 [radeon] [] local_pci_probe+0x5f/0xd0 [] pci_device_probe+0x88/0xb0 [] ? driver_sysfs_add+0x7a/0xb0 [] really_probe+0x68/0x180 [] driver_probe_device+0x45/0x70 [] __driver_attach+0xa3/0xb0 [] ? driver_probe_device+0x70/0x70 [] bus_for_each_dev+0x5e/0x90 [] driver_attach+0x1e/0x20 [] bus_add_driver+0xc8/0x280 [] driver_register+0x76/0x140 [] __pci_register_driver+0x66/0xe0 [] drm_pci_init+0x111/0x120 [drm] [] ? vga_switcheroo_register_handler+0x3a/0x60 [] ? 0xffffffffa0228fff [] radeon_init+0xec/0xee [radeon] [] do_one_initcall+0x42/0x180 [] sys_init_module+0x92/0x1e0 [] system_call_fastpath+0x16/0x1b Code: 58 2a 43 50 88 43 4e 48 83 c4 08 5b c9 c3 66 90 e8 cb fd ff ff eb e6 90 90 90 90 90 90 90 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c RIP [] memcpy+0xb/0x120 RSP CR2: ffff8800a4244000 ---[ end trace fcffa1599cf56382 ]--- Call to acpi_evaluate_object() not always returns 4096 bytes chunks, on my system it can return 2048 bytes chunk, so pass the length of retrieved chunk to memcpy(), not the length of the recieving buffer. Signed-off-by: Igor Murzov Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit c85b103f57465e6965364f0e07b1e9bec055eb2e Author: Alex Deucher Date: Mon Aug 20 11:06:21 2012 -0400 drm/radeon: convert radeon vfct code to use acpi_get_table_with_size commit 7c3906d04a4587dceaa78cc1ae6b14e6454ee02a upstream. Allows us to verify the table size. Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit 3bef028e010d566b6f54e6bb9358726719cc52e7 Author: Alex Deucher Date: Mon Aug 20 10:57:22 2012 -0400 ACPI: export symbol acpi_get_table_with_size commit 4f81f986761a7663db7d24d24cd6ae68008f1fc2 upstream. We need it in the radeon drm module to fetch and verify the vbios image on UEFI systems. Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit aca20e420100cda3d32d68e640d84cc02d8b45ef Author: David Lamparter Date: Thu Aug 16 15:45:20 2012 -0400 drm/radeon: implement ACPI VFCT vbios fetch (v3) commit 268ba0a99f89a84dc5eb312470896113d0709c74 upstream. This is required for pure UEFI systems. The vbios is stored in ACPI rather than at the legacy vga location. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=26891 V2: fix #ifdefs as per Greg's comments V3: fix it harder Signed-off-by: Alex Deucher Reviewed-by: Jerome Glisse Signed-off-by: Ben Hutchings commit 2b1e8d056506b172b7326734cdbe6ca0a1e703c5 Author: Tvrtko Ursulin Date: Mon Aug 20 15:16:04 2012 +0100 drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping commit 52e9b39d9a89ae33662596bd30e62dd56bddbe73 upstream. There is a more recent APU stepping with a new PCI ID shipping in the same board by Fujitsu which needs the same quirk to correctly mark the back plane connectors. Signed-off-by: Tvrtko Ursulin Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit 6be4d3002ce1d70ddaf897456ce2cf73274aaae8 Author: Alex Deucher Date: Tue Mar 20 17:17:57 2012 -0400 drm/radeon/kms: upstream atombios.h updates commit bf68adb4df2ac27a8f1b24894c007c9ef1c4195a upstream. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit bd7fe0bf97de8766db16135df93a20fdb98de89d Author: Amerigo Wang Date: Sat Aug 18 07:02:20 2012 +0000 netconsole: remove a redundant netconsole_target_put() commit 72d3eb13b5c0abe7d63efac41f39c5b644c7bbaa upstream. This netconsole_target_put() is obviously redundant, and it causes a kernel segfault when removing a bridge device which has netconsole running on it. This is caused by: commit 8d8fc29d02a33e4bd5f4fa47823c1fd386346093 Author: Amerigo Wang Date: Thu May 19 21:39:10 2011 +0000 netpoll: disable netpoll when enslave a device Cc: David Miller Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit ac38dc2a6c58b02a65fb3ca2782b3a673b0f89e0 Author: David Henningsson Date: Mon Aug 20 11:17:00 2012 +0200 ALSA: hda - don't create dysfunctional mixer controls for ca0132 commit c41999a23929f30808bae6009d8065052d4d73fd upstream. It's possible that these amps are settable somehow, e g through secret codec verbs, but for now, don't create the controls (as they won't be working anyway, and cause errors in amixer). BugLink: https://bugs.launchpad.net/bugs/1038651 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 55add10c00b8ddd4cc091fa7e5dc974a0985fd90 Author: Mel Gorman Date: Sun Aug 19 14:41:03 2012 +1200 Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts commit 67a806d9499353fabd5b5ff07337f3aa88a1c3ba upstream. The following build error occurred during an alpha build: net/core/sock.c:274:36: error: initializer element is not constant Dave Anglin says: > Here is the line in sock.i: > > struct static_key memalloc_socks = ((struct static_key) { .enabled = > ((atomic_t) { (0) }) }); The above line contains two compound literals. It also uses a designated initializer to initialize the field enabled. A compound literal is not a constant expression. The location of the above statement isn't fully clear, but if a compound literal occurs outside the body of a function, the initializer list must consist of constant expressions. Signed-off-by: Mel Gorman Signed-off-by: Fengguang Wu Signed-off-by: Michael Cree Acked-by: Matt Turner Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit c93f5803e234956a070c7c443fb5a4620d012cc8 Author: Michael Cree Date: Sun Aug 19 14:40:56 2012 +1200 alpha: Don't export SOCK_NONBLOCK to user space. commit a2fa3ccd7b43665fe14cb562761a6c3d26a1d13f upstream. Currently we export SOCK_NONBLOCK to user space but that conflicts with the definition from glibc leading to compilation errors in user programs (e.g. see Debian bug #658460). The generic socket.h restricts the definition of SOCK_NONBLOCK to the kernel, as does the MIPS specific socket.h, so let's do the same on Alpha. Signed-off-by: Michael Cree Acked-by: Matt Turner Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 76e0246b1c62a12db0c9af652be580019ee4666a Author: Sven Schnelle Date: Fri Aug 17 21:43:43 2012 +0200 USB: CDC ACM: Fix NULL pointer dereference commit 99f347caa4568cb803862730b3b1f1942639523f upstream. If a device specifies zero endpoints in its interface descriptor, the kernel oopses in acm_probe(). Even though that's clearly an invalid descriptor, we should test wether we have all endpoints. This is especially bad as this oops can be triggered by just plugging a USB device in. Signed-off-by: Sven Schnelle Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 0a97b367d2da87668e8b20f1d10d6956ed76bb1a Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:41 2012 -0700 USB: emi62: remove __devinit* from the struct usb_device_id table commit 83957df21dd94655d2b026e0944a69ff37b83988 upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Paul Gortmaker CC: Andrew Morton CC: Felipe Balbi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 754e1f26df588c4fb52ecc915afbff6452f0ff98 Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:37 2012 -0700 USB: winbond: remove __devinit* from the struct usb_device_id table commit 43a34695d9cd79c6659f09da6d3b0624f3dd169f upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Pavel Machek CC: Paul Gortmaker CC: "John W. Linville" CC: Eliad Peller CC: Devendra Naga Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e91f7b801664f7aa25d4cb7420885ee277b19b5c Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:33 2012 -0700 USB: vt6656: remove __devinit* from the struct usb_device_id table commit 4d088876f24887cd15a29db923f5f37db6a99f21 upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Forest Bond CC: Marcos Paulo de Souza CC: "David S. Miller" CC: Jesper Juhl CC: Jiri Pirko Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 6b9aa8cfb1a9731e425d385962eb3314b78f7fd7 Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:29 2012 -0700 USB: rtl8187: remove __devinit* from the struct usb_device_id table commit a3433179d0822ccfa8e80aa4d1d52843bd2dcc63 upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Herton Ronaldo Krzesinski CC: Hin-Tak Leung CC: Larry Finger CC: "John W. Linville" Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e60af62b40a97d3cfa1d8624d0e55037930bc039 Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:28 2012 -0700 USB: p54usb: remove __devinit* from the struct usb_device_id table commit b9c4167cbbafddac3462134013bc15e63e4c53ef upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Christian Lamparter CC: "John W. Linville" Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 75fc31282f88bf314ad4cee90e84f763e909da18 Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:27 2012 -0700 USB: spca506: remove __devinit* from the struct usb_device_id table commit e694d518886c7afedcdd1732477832b2e32744e4 upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Hans de Goede CC: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit ba98e0dd6eccff9cdb27e008c0a1310747e3fb8f Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:26 2012 -0700 USB: smsusb: remove __devinit* from the struct usb_device_id table commit d04dbd1c0ec17a13326c8f2279399c225836a79f upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Mauro Carvalho Chehab CC: Michael Krufky CC: Paul Gortmaker CC: Doron Cohen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 6f541ea83e4de5acecae039acebac538125871d9 Author: Mark Brown Date: Thu Aug 16 22:36:04 2012 +0100 ASoC: wm9712: Fix microphone source selection commit ccf795847a38235ee4a56a24129ce75147d6ba8f upstream. Currently the microphone input source is not selectable as while there is a DAPM widget it's not connected to anything so it won't be properly instantiated. Add something more correct for the input structure to get things going, even though it's not hooked into the rest of the routing map and so won't actually achieve anything except allowing the relevant register bits to be written. Reported-by: Christop Fritz Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit 9379931f204703f9ccdf33b9273f3e755d86f8e6 Author: Rafael J. Wysocki Date: Wed Aug 15 21:31:55 2012 +0200 PM / Runtime: Clear power.deferred_resume on success in rpm_suspend() commit 58a34de7b1a920d287d17d2ca08bc9aaf7e6d35b upstream. The power.deferred_resume can only be set if the runtime PM status of device is RPM_SUSPENDING and it should be cleared after its status has been changed, regardless of whether or not the runtime suspend has been successful. However, it only is cleared on suspend failure, while it may remain set on successful suspend and is happily leaked to rpm_resume() executed in that case. That shouldn't happen, so if power.deferred_resume is set in rpm_suspend() after the status has been changed to RPM_SUSPENDED, clear it before calling rpm_resume(). Then, it doesn't need to be cleared before changing the status to RPM_SUSPENDING any more, because it's always cleared after the status has been changed to either RPM_SUSPENDED (on success) or RPM_ACTIVE (on failure). Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern Signed-off-by: Ben Hutchings commit 68c4272d4202a6d4532aec0171594e079665a75e Author: Rafael J. Wysocki Date: Wed Aug 15 21:31:45 2012 +0200 PM / Runtime: Fix rpm_resume() return value for power.no_callbacks set commit 7f321c26c04807834fef4c524d2b21573423fc74 upstream. For devices whose power.no_callbacks flag is set, rpm_resume() should return 1 if the device's parent is already active, so that the callers of pm_runtime_get() don't think that they have to wait for the device to resume (asynchronously) in that case (the core won't queue up an asynchronous resume in that case, so there's nothing to wait for anyway). Modify the code accordingly (and make sure that an idle notification will be queued up on success, even if 1 is to be returned). Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern Signed-off-by: Ben Hutchings commit 4ac2515cf5201e7762c16303d860b6ec0e02aecb Author: Theodore Ts'o Date: Thu Aug 16 11:59:04 2012 -0400 ext4: fix long mount times on very big file systems commit 0548bbb85337e532ca2ed697c3e9b227ff2ed4b4 upstream. Commit 8aeb00ff85a: "ext4: fix overhead calculation used by ext4_statfs()" introduced a O(n**2) calculation which makes very large file systems take forever to mount. Fix this with an optimization for non-bigalloc file systems. (For bigalloc file systems the overhead needs to be set in the the superblock.) Signed-off-by: "Theodore Ts'o" Signed-off-by: Ben Hutchings commit 077bfcc044b6ec6f780bc53b206dd1ba10aa2cd3 Author: Yi Zou Date: Tue Aug 14 16:06:43 2012 -0700 target: fix NULL pointer dereference bug alloc_page() fails to get memory commit d0e27c88d795fb9647153063ec48051fd84e1731 upstream. I am hitting this bug when the target is low in memory that fails the alloc_page() for the newly submitted command. This is a sort of off-by-one bug causing NULL pointer dereference in __free_page() since 'i' here is really the counter of total pages that have been successfully allocated here. Signed-off-by: Yi Zou Cc: Andy Grover Cc: Nicholas Bellinger Cc: Open-FCoE.org Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit 93478b6b303be51b15e078ddbda862ec39300f4f Author: bjschuma@gmail.com Date: Wed Aug 8 13:57:10 2012 -0400 NFS: Alias the nfs module to nfs4 commit 425e776d93a7a5070b77d4f458a5bab0f924652c upstream. This allows distros to remove the line from their modprobe configuration. Signed-off-by: Bryan Schumaker Signed-off-by: Trond Myklebust [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 8f95230095324becad132fa3a2a2eff8f7de7bdb Author: NeilBrown Date: Thu Aug 16 16:46:12 2012 +1000 md: Don't truncate size at 4TB for RAID0 and Linear commit 667a5313ecd7308d79629c0738b0db588b0b0a4e upstream. commit 27a7b260f71439c40546b43588448faac01adb93 md: Fix handling for devices from 2TB to 4TB in 0.90 metadata. changed 0.90 metadata handling to truncated size to 4TB as that is all that 0.90 can record. However for RAID0 and Linear, 0.90 doesn't need to record the size, so this truncation is not needed and causes working arrays to become too small. So avoid the truncation for RAID0 and Linear This bug was introduced in 3.1 and is suitable for any stable kernels from then onwards. As the offending commit was tagged for 'stable', any stable kernel that it was applied to should also get this patch. That includes at least 2.6.32, 2.6.33 and 3.0. (Thanks to Ben Hutchings for providing that list). Signed-off-by: Neil Brown Signed-off-by: Ben Hutchings commit 372c463a7c5ea46eca693ea52bd95cb8512247f8 Author: Mathias Krause Date: Wed Aug 15 11:31:54 2012 +0000 dccp: check ccid before dereferencing commit 276bdb82dedb290511467a5a4fdbe9f0b52dce6f upstream. ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with a NULL ccid pointer leading to a NULL pointer dereference. This could lead to a privilege escalation if the attacker is able to map page 0 and prepare it with a fake ccid_ops pointer. Signed-off-by: Mathias Krause Cc: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit fc7834af1b974a2578440d1210a991eedd2151b1 Author: Bart Van Assche Date: Tue Aug 14 13:18:53 2012 +0000 IB/srp: Fix a race condition commit 220329916c72ee3d54ae7262b215a050f04a18fc upstream. Avoid a crash caused by the scmnd->scsi_done(scmnd) call in srp_process_rsp() being invoked with scsi_done == NULL. This can happen if a reply is received during or after a command abort. Reported-by: Joseph Glanville Reference: http://marc.info/?l=linux-rdma&m=134314367801595 Acked-by: David Dillow Signed-off-by: Bart Van Assche Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit e18b3cbd16e4d5f77f9b9138ab143b2d10db88fe Author: Rafael J. Wysocki Date: Sun Aug 12 23:26:07 2012 +0200 PCI: EHCI: Fix crash during hibernation on ASUS computers commit 0b68c8e2c3afaf9807eb1ebe0ccfb3b809570aa4 upstream. Commit dbf0e4c (PCI: EHCI: fix crash during suspend on ASUS computers) added a workaround for an ASUS suspend issue related to USB EHCI and a bug in a number of ASUS BIOSes that attempt to shut down the EHCI controller during system suspend if its PCI command register doesn't contain 0 at that time. It turns out that the same workaround is necessary in the analogous hibernation code path, so add it. References: https://bugzilla.kernel.org/show_bug.cgi?id=45811 Reported-and-tested-by: Oleksij Rempel Signed-off-by: Rafael J. Wysocki Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings commit 8dd138a98241fc7be5d89950e6e09bbc18024a53 Author: Miklos Szeredi Date: Wed Aug 15 13:01:24 2012 +0200 vfs: canonicalize create mode in build_open_flags() commit e68726ff72cf7ba5e7d789857fcd9a75ca573f03 upstream. Userspace can pass weird create mode in open(2) that we canonicalize to "(mode & S_IALLUGO) | S_IFREG" in vfs_create(). The problem is that we use the uncanonicalized mode before calling vfs_create() with unforseen consequences. So do the canonicalization early in build_open_flags(). Signed-off-by: Miklos Szeredi Tested-by: Richard W.M. Jones Signed-off-by: Ben Hutchings commit c2cc94c67ca8e3c496a790d631fd1ac38d31d522 Author: Miklos Szeredi Date: Wed Aug 15 12:55:22 2012 +0200 audit: fix refcounting in audit-tree commit a2140fc0cb0325bb6384e788edd27b9a568714e2 upstream. Refcounting of fsnotify_mark in audit tree is broken. E.g: refcount create_chunk alloc_chunk 1 fsnotify_add_mark 2 untag_chunk fsnotify_get_mark 3 fsnotify_destroy_mark audit_tree_freeing_mark 2 fsnotify_put_mark 1 fsnotify_put_mark 0 via destroy_list fsnotify_mark_destroy -1 This was reported by various people as triggering Oops when stopping auditd. We could just remove the put_mark from audit_tree_freeing_mark() but that would break freeing via inode destruction. So this patch simply omits a put_mark after calling destroy_mark or adds a get_mark before. The additional get_mark is necessary where there's no other put_mark after fsnotify_destroy_mark() since it assumes that the caller is holding a reference (or the inode is keeping the mark pinned, not the case here AFAICS). Signed-off-by: Miklos Szeredi Reported-by: Valentin Avram Reported-by: Peter Moody Acked-by: Eric Paris Signed-off-by: Ben Hutchings commit 7d78916c93c07eedb9cf37f5b09e62fbd65968cc Author: Miklos Szeredi Date: Wed Aug 15 12:55:22 2012 +0200 audit: don't free_chunk() after fsnotify_add_mark() commit 0fe33aae0e94b4097dd433c9399e16e17d638cd8 upstream. Don't do free_chunk() after fsnotify_add_mark(). That one does a delayed unref via the destroy list and this results in use-after-free. Signed-off-by: Miklos Szeredi Acked-by: Eric Paris Signed-off-by: Ben Hutchings commit 43007cdf7ef0067581def99b20ac1625e33008c9 Author: Daniel Vetter Date: Sun Aug 12 22:17:14 2012 +0200 drm/i915: reorder edp disabling to fix ivb MacBook Air commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4 upstream. eDP is tons of fun. It turns out that at least the new MacBook Air 5,1 model absolutely doesn't like the new force vdd dance we've introduced in commit 6cb49835da0426f69a2931bc2a0a8156344b0e41 Author: Daniel Vetter Date: Sun May 20 17:14:50 2012 +0200 drm/i915: enable vdd when switching off the eDP panel But that patch also tried to fix some neat edp sequence issue with the force_vdd timings. Closer inspection reveals that we've raised force_vdd only to do the aux channel communication dp_sink_dpms. If we move the edp_panel_off below that, we don't need any force_vdd for the disable sequence, which makes the Air happy. Unfortunately the reporter of the original bug that the above commit fixed is travelling, so we can't test whether this regresses things. But my theory is that since we don't check for any power-off -> force_vdd-on delays in edp_panel_vdd_on, this was the actual root-cause of this failure. With that force_vdd dance completely eliminated, I'm hopeful the original bug stays fixed, too. For reference the old bug, which hopefully doesn't get broken by this: https://bugzilla.kernel.org/show_bug.cgi?id=43163 In any case, regression fixers win over plain bugfixes, so this needs to go in asap. v2: The crucial pieces seems to be to clear the force_vdd flag uncoditionally, too, in edp_panel_off. Looks like this is left behind by the firmware somehow. v3: The Apple firmware seems to switch off the panel on it's own, hence we still need to keep force_vdd on, but properly clear it when switching the panel off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671 Tested-by: Roberto Romer Tested-by: Daniel Wagner Tested-by: Keith Packard Cc: Keith Packard Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit e3b0eeb5a6bcf203635aab88111f6821d3c2a839 Author: Christoph Bumiller Date: Thu Jul 26 20:53:19 2012 +0200 drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate commit af5e7d84b0ec45b2b614b0d6e3657cbdceaa21f9 upstream. Signed-off-by: Christoph Bumiller