kernel/linux.git, branch v3.12.20

Linux 3.12.20

2014-05-15T07:56:19+00:00

drm: cirrus: add power management support

2014-05-15T07:56:18+00:00

commit 2f1e800799bf478494cec3573cd63eb34ca89c9d upstream. cirrus kms driver lacks power management support, thus the vga display doesn't work any more after S3 resume. Fix this by adding suspend and resume functions. Also make the mode_set function unblank the screen. Signed-off-by: Gerd Hoffmann Signed-off-by: Dave Airlie Signed-off-by: Jiri Slaby

Input: synaptics - add min/max quirk for ThinkPad Edge E431

2014-05-15T07:56:18+00:00

commit 27a38856a948c3e8de30dc71647ff9e1778c99fc upstream. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Slaby

Input: synaptics - add min/max quirk for ThinkPad T431s, L440, L540, S1 Yoga and X1

2014-05-15T07:56:17+00:00

commit 46a2986ebbe18757c2d8c352f8fb6e0f4f0754e3 upstream. We expect that all the Haswell series will need such quirks, sigh. The T431s seems to be T430 hardware in a T440s case, using the T440s touchpad, with the same min/max issue. The X1 Carbon 3rd generation name says 2nd while it is a 3rd generation. The X1 and T431s share a PnPID with the T540p, but the reported ranges are closer to those of the T440s. HdG: Squashed 5 quirk patches into one. T431s + L440 + L540 are written by me, S1 Yoga and X1 are written by Benjamin Tissoires. Hdg: Standardized S1 Yoga and X1 values, Yoga uses the same touchpad as the X240, X1 uses the same touchpad as the T440. Signed-off-by: Benjamin Tissoires Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Slaby

mmc: sdhci-bcm-kona: fix build errors when built-in

2014-05-15T07:56:17+00:00

commit 4025ce24f326830135341814307c072f6c2a7738 upstream. `sdhci_bcm_kona_remove' referenced in section `.data' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o Fixes: 058feb53666f ("mmc: sdhci-bcm-kona: make linker-section warning go away") Signed-off-by: Russell King Tested-by: Markus Mayer Acked-by: Matt Porter Signed-off-by: Chris Ball Signed-off-by: Jiri Slaby

lib/percpu_counter.c: fix bad percpu counter state during suspend

2014-05-15T07:56:16+00:00

commit e39435ce68bb4685288f78b1a7e24311f7ef939f upstream. I got a bug report yesterday from Laszlo Ersek in which he states that his kvm instance fails to suspend. Laszlo bisected it down to this commit 1cf7e9c68fe8 ("virtio_blk: blk-mq support") where virtio-blk is converted to use the blk-mq infrastructure. After digging a bit, it became clear that the issue was with the queue drain. blk-mq tracks queue usage in a percpu counter, which is incremented on request alloc and decremented when the request is freed. The initial hunt was for an inconsistency in blk-mq, but everything seemed fine. In fact, the counter only returned crazy values when suspend was in progress. When a CPU is unplugged, the percpu counters merges that CPU state with the general state. blk-mq takes care to register a hotcpu notifier with the appropriate priority, so we know it runs after the percpu counter notifier. However, the percpu counter notifier only merges the state when the CPU is fully gone. This leaves a state transition where the CPU going away is no longer in the online mask, yet it still holds private values. This means that in this state, percpu_counter_sum() returns invalid results, and the suspend then hangs waiting for abs(dead-cpu-value) requests to complete which of course will never happen. Fix this by clearing the state earlier, so we never have a case where the CPU isn't in online mask but still holds private state. This bug has been there since forever, I guess we don't have a lot of users where percpu counters needs to be reliable during the suspend cycle. Signed-off-by: Jens Axboe Reported-by: Laszlo Ersek Tested-by: Laszlo Ersek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby

lockd: ensure we tear down any live sockets when socket creation fails during lockd_up

2014-05-15T07:56:16+00:00

commit 679b033df48422191c4cac52b610d9980e019f9b upstream. We had a Fedora ABRT report with a stack trace like this: kernel BUG at net/sunrpc/svc.c:550! invalid opcode: 0000 [#1] SMP [...] CPU: 2 PID: 913 Comm: rpc.nfsd Not tainted 3.13.6-200.fc20.x86_64 #1 Hardware name: Hewlett-Packard HP ProBook 4740s/1846, BIOS 68IRR Ver. F.40 01/29/2013 task: ffff880146b00000 ti: ffff88003f9b8000 task.ti: ffff88003f9b8000 RIP: 0010:[] [] svc_destroy+0x128/0x130 [sunrpc] RSP: 0018:ffff88003f9b9de0 EFLAGS: 00010206 RAX: ffff88003f829628 RBX: ffff88003f829600 RCX: 00000000000041ee RDX: 0000000000000000 RSI: 0000000000000286 RDI: 0000000000000286 RBP: ffff88003f9b9de8 R08: 0000000000017360 R09: ffff88014fa97360 R10: ffffffff8114ce57 R11: ffffea00051c9c00 R12: ffff88003f829600 R13: 00000000ffffff9e R14: ffffffff81cc7cc0 R15: 0000000000000000 FS: 00007f4fde284840(0000) GS:ffff88014fa80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4fdf5192f8 CR3: 00000000a569a000 CR4: 00000000001407e0 Stack: ffff88003f792300 ffff88003f9b9e18 ffffffffa02de02a 0000000000000000 ffffffff81cc7cc0 ffff88003f9cb000 0000000000000008 ffff88003f9b9e60 ffffffffa033bb35 ffffffff8131c86c ffff88003f9cb000 ffff8800a5715008 Call Trace: [] lockd_up+0xaa/0x330 [lockd] [] nfsd_svc+0x1b5/0x2f0 [nfsd] [] ? simple_strtoull+0x2c/0x50 [] ? write_pool_threads+0x280/0x280 [nfsd] [] write_threads+0x8b/0xf0 [nfsd] [] ? __get_free_pages+0x14/0x50 [] ? get_zeroed_page+0x16/0x20 [] ? simple_transaction_get+0xb1/0xd0 [] nfsctl_transaction_write+0x48/0x80 [nfsd] [] vfs_write+0xb4/0x1f0 [] ? putname+0x29/0x40 [] SyS_write+0x49/0xa0 [] ? __audit_syscall_exit+0x1f6/0x2a0 [] system_call_fastpath+0x16/0x1b Code: 31 c0 e8 82 db 37 e1 e9 2a ff ff ff 48 8b 07 8b 57 14 48 c7 c7 d5 c6 31 a0 48 8b 70 20 31 c0 e8 65 db 37 e1 e9 f4 fe ff ff 0f 0b <0f> 0b 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 RIP [] svc_destroy+0x128/0x130 [sunrpc] RSP Evidently, we created some lockd sockets and then failed to create others. make_socks then returned an error and we tried to tear down the svc, but svc->sv_permsocks was not empty so we ended up tripping over the BUG() in svc_destroy(). Fix this by ensuring that we tear down any live sockets we created when socket creation is going to return an error. Fixes: 786185b5f8abefa (SUNRPC: move per-net operations from...) Reported-by: Raphos Signed-off-by: Jeff Layton Reviewed-by: Stanislav Kinsbursky Signed-off-by: J. Bruce Fields Signed-off-by: Jiri Slaby

aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration

2014-05-15T07:56:15+00:00

commit fa8a53c39f3fdde98c9eace6a9b412143f0f6ed6 upstream. As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues exist in the aio ring page migration support. As a result, for example, we have the following problem: thread 1 | thread 2 | aio_migratepage() | |-> take ctx->completion_lock | |-> migrate_page_copy(new, old) | | *NOW*, ctx->ring_pages[idx] == old | | | *NOW*, ctx->ring_pages[idx] == old | aio_read_events_ring() | |-> ring = kmap_atomic(ctx->ring_pages[0]) | |-> ring->head = head; *HERE, write to the old ring page* | |-> kunmap_atomic(ring); | |-> ctx->ring_pages[idx] = new | | *BUT NOW*, the content of | | ring_pages[idx] is old. | |-> release ctx->completion_lock | As above, the new ring page will not be updated. Fix this issue, as well as prevent races in aio_ring_setup() by holding the ring_lock mutex during kioctx setup and page migration. This avoids the overhead of taking another spinlock in aio_read_events_ring() as Tang's and Gu's original fix did, pushing the overhead into the migration code. Note that to handle the nesting of ring_lock inside of mmap_sem, the migratepage operation uses mutex_trylock(). Page migration is not a 100% critical operation in this case, so the ocassional failure can be tolerated. This issue was reported by Sasha Levin. Based on feedback from Linus, avoid the extra taking of ctx->completion_lock. Instead, make page migration fully serialised by mapping->private_lock, and have aio_free_ring() simply disconnect the kioctx from the mapping by calling put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the error handling logic in aio_migratepage(), and should improve robustness. v4: always do mutex_unlock() in cases when kioctx setup fails. Reported-by: Yasuaki Ishimatsu Reported-by: Sasha Levin Signed-off-by: Benjamin LaHaise Cc: Tang Chen Cc: Gu Zheng Signed-off-by: Jiri Slaby

dma: edma: fix incorrect SG list handling

2014-05-15T07:56:15+00:00

commit 5fc68a6cad658e45dca3e0a6607df3a8e5df4ef9 upstream. The code to handle any length SG lists calls edma_resume() even before edma_start() is called. This is incorrect because edma_resume() enables edma events on the channel after which CPU (in edma_start) cannot clear posted events by writing to ECR (per the EDMA user's guide). Because of this EDMA transfers fail to start if due to some reason there is a pending EDMA event registered even before EDMA transfers are started. This can happen if an EDMA event is a byproduct of device initialization. Fix this by calling edma_resume() only if it is not the first batch of MAX_NR_SG elements. Without this patch, MMC/SD fails to function on DA850 EVM with DMA. The behaviour is triggered by specific IP and this can explain why the issue was not reported before (example with MMC/SD on AM335x). Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card. Cc: Joel Fernandes Acked-by: Joel Fernandes Tested-by: Jon Ringle Tested-by: Alexander Holler Reported-by: Jon Ringle Signed-off-by: Sekhar Nori Signed-off-by: Vinod Koul Signed-off-by: Jiri Slaby

dm thin: fix dangling bio in process_deferred_bios error path

2014-05-15T07:56:14+00:00

commit fe76cd88e654124d1431bb662a0fc6e99ca811a5 upstream. If unable to ensure_next_mapping() we must add the current bio, which was removed from the @bios list via bio_list_pop, back to the deferred_bios list before all the remaining @bios. Signed-off-by: Mike Snitzer Acked-by: Joe Thornber Signed-off-by: Jiri Slaby