commit 13817987369afc8a65c6d7590cfca57f9da4a9a2 Author: Greg Kroah-Hartman Date: Thu Sep 7 08:37:34 2017 +0200 Linux 4.12.11 commit 9c2144e80db88bb93966e4c7fb631bef9e57e3a5 Author: Oleg Nesterov Date: Fri Sep 1 18:55:33 2017 +0200 epoll: fix race between ep_poll_callback(POLLFREE) and ep_free()/ep_remove() commit 138e4ad67afd5c6c318b056b4d17c17f2c0ca5c0 upstream. The race was introduced by me in commit 971316f0503a ("epoll: ep_unregister_pollwait() can use the freed pwq->whead"). I did not realize that nothing can protect eventpoll after ep_poll_callback() sets ->whead = NULL, only whead->lock can save us from the race with ep_free() or ep_remove(). Move ->whead = NULL to the end of ep_poll_callback() and add the necessary barriers. TODO: cleanup the ewake/EPOLLEXCLUSIVE logic, it was confusing even before this patch. Hopefully this explains use-after-free reported by syzcaller: BUG: KASAN: use-after-free in debug_spin_lock_before ... _raw_spin_lock_irqsave+0x4a/0x60 kernel/locking/spinlock.c:159 ep_poll_callback+0x29f/0xff0 fs/eventpoll.c:1148 this is spin_lock(eventpoll->lock), ... Freed by task 17774: ... kfree+0xe8/0x2c0 mm/slub.c:3883 ep_free+0x22c/0x2a0 fs/eventpoll.c:865 Fixes: 971316f0503a ("epoll: ep_unregister_pollwait() can use the freed pwq->whead") Reported-by: 范龙飞 Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 38f5d65ad997efdded1ac08eeb0ca3f6190ff5f7 Author: Ben Skeggs Date: Wed Jul 19 16:49:59 2017 +1000 drm/nouveau/i2c/gf119-: add support for address-only transactions commit 13a86519202c5d119d83640d6f781f3181205d2c upstream. Since switching the I2C-over-AUX helpers, there have been regressions on some display combinations due to us not having support for "address only" transactions. This commits enables support for them for GF119 and newer. Earlier GPUs have been reverted to a custom I2C-over-AUX algorithm. Signed-off-by: Ben Skeggs Cc: Ilia Mirkin Signed-off-by: Greg Kroah-Hartman commit bdacc5fcf4f905e732fb3420e20602da333285e9 Author: Changpeng Liu Date: Thu Aug 31 11:22:49 2017 +0800 nvme: fix the definition of the doorbell buffer config support bit commit 223694b9ae8bfba99f3528d49d07a740af6ff95a upstream. NVMe 1.3 specification defines the Optional Admin Command Support feature flags, bit 8 set to '1' then the controller supports the Doorbell Buffer Config command. Bit 7 is used for Virtualization Mangement command. Signed-off-by: Changpeng Liu Reviewed-by: Sagi Grimberg Reviewed-by: Max Gurtovoy Reviewed-by: Johannes Thumshirn Signed-off-by: Christoph Hellwig Fixes: f9f38e33 ("nvme: improve performance for virtual NVMe devices") Signed-off-by: Greg Kroah-Hartman commit c6d2779d8f0d834e552ed5f022e96137b768315c Author: Xiangliang.Yu Date: Wed Aug 16 14:25:51 2017 +0800 drm/ttm: Fix accounting error when fail to get pages for pool commit 9afae2719273fa1d406829bf3498f82dbdba71c7 upstream. When fail to get needed page for pool, need to put allocated pages into pool. But current code has a miscalculation of allocated pages, correct it. Signed-off-by: Xiangliang.Yu Reviewed-by: Christian König Reviewed-by: Monk Liu Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6c5b60edd786fe18b7be96b26ca980aa2bef0428 Author: Vladis Dronov Date: Wed Aug 2 19:50:14 2017 +0200 xfrm: policy: check policy direction value commit 7bab09631c2a303f87a7eb7e3d69e888673b9b7e upstream. The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used as an array index. This can lead to an out-of-bound access, kernel lockup and DoS. Add a check for the 'dir' value. This fixes CVE-2017-11600. References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928 Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint address(es)") Reported-by: "bo Zhang" Signed-off-by: Vladis Dronov Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 6cc6f45db016886f6a4e91b249a923a61cebb996 Author: Stephan Mueller Date: Thu Aug 10 08:06:18 2017 +0200 lib/mpi: kunmap after finishing accessing buffer commit dea3eb8b452e36cf2dd572b0a797915ccf452ae6 upstream. Using sg_miter_start and sg_miter_next, the buffer of an SG is kmap'ed to *buff. The current code calls sg_miter_stop (and thus kunmap) on the SG entry before the last access of *buff. The patch moves the sg_miter_stop call after the last access to *buff to ensure that the memory pointed to by *buff is still mapped. Fixes: 4816c9406430 ("lib/mpi: Fix SG miter leak") Signed-off-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a3deff1d3285f9516b2335644588fb09eaa291a2 Author: Zhoujie Wu Date: Mon Aug 21 11:02:09 2017 -0700 mmc: sdhci-xenon: add set_power callback commit 99c14fc360dbbb583a03ab985551b12b5c5ca4f1 upstream. Xenon sdh controller requests proper SD bus voltage select bits programmed even with vmmc power supply. Any reserved value(100b-000b) programmed in this field will lead to controller ignore SD bus power bit and keep its value at zero. Add set_power callback to handle this. Signed-off-by: Zhoujie Wu Acked-by: Adrian Hunter Tested-by: Gregory CLEMENT Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality") Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d767ccb7c387b0eed712ae38100aded44710ebe5 Author: Cong Wang Date: Thu Aug 31 16:47:43 2017 +0200 wl1251: add a missing spin_lock_init() commit f581a0dd744fe32b0a8805e279c59ec1ac676d60 upstream. wl1251: add a missing spin_lock_init() This fixes the following kernel warning: [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 [ 5668.771850] lock: 0xce63ef20, .magic: 00000000, .owner: /-1, .owner_cpu: 0 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: G W 4.12.0-03002-gec979a4-dirty #40 [ 5668.772796] Hardware name: Nokia RX-51 board [ 5668.773071] Workqueue: phy1 wl1251_irq_work [ 5668.773345] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 5668.773803] [] (show_stack) from [] (do_raw_spin_lock+0x6c/0xa0) [ 5668.774230] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x10/0x18) [ 5668.774658] [] (_raw_spin_lock_irqsave) from [] (wl1251_op_tx+0x38/0x5c) [ 5668.775115] [] (wl1251_op_tx) from [] (ieee80211_tx_frags+0x188/0x1c0) [ 5668.775543] [] (ieee80211_tx_frags) from [] (__ieee80211_tx+0x6c/0x130) [ 5668.775970] [] (__ieee80211_tx) from [] (ieee80211_tx+0xdc/0x104) [ 5668.776367] [] (ieee80211_tx) from [] (__ieee80211_subif_start_xmit+0x454/0x8c8) [ 5668.776824] [] (__ieee80211_subif_start_xmit) from [] (ieee80211_subif_start_xmit+0x30/0x2fc) [ 5668.777343] [] (ieee80211_subif_start_xmit) from [] (dev_hard_start_xmit+0x80/0x118) ... by adding the missing spin_lock_init(). Reported-by: Pavel Machek Cc: Kalle Valo Signed-off-by: Cong Wang Acked-by: Pavel Machek Signed-off-by: Kalle Valo Signed-off-by: Pavel Machek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 619d31a0d2471e538f83dda6fc69ddd365b4ae06 Author: Sinclair Yeh Date: Tue Aug 29 18:55:09 2017 +0200 drm/vmwgfx: Fix F26 Wayland screen update issue commit 021aba761f2a6c12158afb9993524c300c01fae2 upstream. vmwgfx currently cannot support non-blocking commit because when vmw_*_crtc_page_flip is called, drm_atomic_nonblocking_commit() schedules the update on a thread. This means vmw_*_crtc_page_flip cannot rely on the new surface being bound before the subsequent dirty and flush operations happen. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Reviewed-by: Charmaine Lee Signed-off-by: Greg Kroah-Hartman commit 399081a50c48b3d7b205d08975c67aa53c391238 Author: Bart Van Assche Date: Wed Aug 9 11:32:12 2017 -0700 dm mpath: do not lock up a CPU with requeuing activity commit 1c23484c355ec360ca2f37914f8a4802c6baeead upstream. When using the block layer in single queue mode, get_request() returns ERR_PTR(-EAGAIN) if the queue is dying and the REQ_NOWAIT flag has been passed to get_request(). Avoid that the kernel reports soft lockup complaints in this case due to continuous requeuing activity. Fixes: 7083abbbf ("dm mpath: avoid that path removal can trigger an infinite loop") Signed-off-by: Bart Van Assche Tested-by: Laurence Oberman Reviewed-by: Christoph Hellwig Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 77ab9e7fb4312d3b377690660f757d900fa9e171 Author: Steve French Date: Sun Aug 27 16:56:08 2017 -0500 CIFS: remove endian related sparse warning commit 6e3c1529c39e92ed64ca41d53abadabbaa1d5393 upstream. Recent patch had an endian warning ie cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup() Signed-off-by: Steve French CC: Ronnie Sahlberg Acked-by: Pavel Shilovsky Signed-off-by: Greg Kroah-Hartman commit 0627f7136685595b33a20855630ce517b65fe55c Author: Pavel Shilovsky Date: Thu Aug 24 15:16:40 2017 -0700 CIFS: Fix maximum SMB2 header size commit 9e37b1784f2be9397a903307574ee565bbadfd75 upstream. Currently the maximum size of SMB2/3 header is set incorrectly which leads to hanging of directory listing operations on encrypted SMB3 connections. Fix this by setting the maximum size to 170 bytes that is calculated as RFC1002 length field size (4) + transform header size (52) + SMB2 header size (64) + create response size (56). Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Acked-by: Sachin Prabhu Signed-off-by: Greg Kroah-Hartman commit f3e9dc4504b1f11e69baaa9b3779512d9cc6d83f Author: Ben Hutchings Date: Thu Oct 1 01:35:55 2015 +0100 alpha: uapi: Add support for __SANE_USERSPACE_TYPES__ commit cec80d82142ab25c71eee24b529cfeaf17c43062 upstream. This fixes compiler errors in perf such as: tests/attr.c: In function 'store_event': tests/attr.c:66:27: error: format '%llu' expects argument of type 'long long unsigned int', but argument 6 has type '__u64 {aka long unsigned int}' [-Werror=format=] snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir, ^ Signed-off-by: Ben Hutchings Tested-by: Michael Cree Signed-off-by: Matt Turner Signed-off-by: Greg Kroah-Hartman commit ae53897e22db8139d6ad8278599a122aba8dad7d Author: Waiman Long Date: Thu Aug 24 12:04:29 2017 -0400 cpuset: Fix incorrect memory_pressure control file mapping commit 1c08c22c874ac88799cab1f78c40f46110274915 upstream. The memory_pressure control file was incorrectly set up without a private value (0, by default). As a result, this control file was treated like memory_migrate on read. By adding back the FILE_MEMORY_PRESSURE private value, the correct memory pressure value will be returned. Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Fixes: 7dbdb199d3bf ("cgroup: replace cftype->mode with CFTYPE_WORLD_WRITABLE") Signed-off-by: Greg Kroah-Hartman commit fd20ca80f807f828285b359ceedd8fc3754e64f2 Author: Tejun Heo Date: Mon Aug 28 14:51:27 2017 -0700 cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs commit b339752d054fb32863418452dff350a1086885b1 upstream. When !NUMA, cpumask_of_node(@node) equals cpu_online_mask regardless of @node. The assumption seems that if !NUMA, there shouldn't be more than one node and thus reporting cpu_online_mask regardless of @node is correct. However, that assumption was broken years ago to support DISCONTIGMEM and whether a system has multiple nodes or not is separately controlled by NEED_MULTIPLE_NODES. This means that, on a system with !NUMA && NEED_MULTIPLE_NODES, cpumask_of_node() will report cpu_online_mask for all possible nodes, indicating that the CPUs are associated with multiple nodes which is an impossible configuration. This bug has been around forever but doesn't look like it has caused any noticeable symptoms. However, it triggers a WARN recently added to workqueue to verify NUMA affinity configuration. Fix it by reporting empty cpumask on non-zero nodes if !NUMA. Signed-off-by: Tejun Heo Reported-and-tested-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3d7aeba120fde73756a231e54c80a7bb3f435d23 Author: Yan, Zheng Date: Fri Aug 4 11:22:31 2017 +0800 ceph: fix readpage from fscache commit dd2bc473482eedc60c29cf00ad12568ce40ce511 upstream. ceph_readpage() unlocks page prematurely prematurely in the case that page is reading from fscache. Caller of readpage expects that page is uptodate when it get unlocked. So page shoule get locked by completion callback of fscache_read_or_alloc_pages() Signed-off-by: "Yan, Zheng" Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit b3010084e111013917c5b53ad564bc9711810576 Author: Mel Gorman Date: Thu Aug 31 16:15:30 2017 -0700 mm, madvise: ensure poisoned pages are removed from per-cpu lists commit c461ad6a63b37ba74632e90c063d14823c884247 upstream. Wendy Wang reported off-list that a RAS HWPOISON-SOFT test case failed and bisected it to the commit 479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated from the PCP"). The problem is that a page that was poisoned with madvise() is reused. The commit removed a check that would trigger if DEBUG_VM was enabled but re-enabling the check only fixes the problem as a side-effect by printing a bad_page warning and recovering. The root of the problem is that an madvise() can leave a poisoned page on the per-cpu list. This patch drains all per-cpu lists after pages are poisoned so that they will not be reused. Wendy reports that the test case in question passes with this patch applied. While this could be done in a targeted fashion, it is over-complicated for such a rare operation. Link: http://lkml.kernel.org/r/20170828133414.7qro57jbepdcyz5x@techsingularity.net Fixes: 479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated from the PCP") Signed-off-by: Mel Gorman Reported-by: Wang, Wendy Tested-by: Wang, Wendy Acked-by: David Rientjes Acked-by: Vlastimil Babka Cc: "Hansen, Dave" Cc: "Luck, Tony" Cc: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8c46edd78de9ca55082d65a4646646748e8630a3 Author: Eric Biggers Date: Thu Aug 31 16:15:26 2017 -0700 mm, uprobes: fix multiple free of ->uprobes_state.xol_area commit 355627f518978b5167256d27492fe0b343aaf2f2 upstream. Commit 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for write killable") made it possible to kill a forking task while it is waiting to acquire its ->mmap_sem for write, in dup_mmap(). However, it was overlooked that this introduced an new error path before the new mm_struct's ->uprobes_state.xol_area has been set to NULL after being copied from the old mm_struct by the memcpy in dup_mm(). For a task that has previously hit a uprobe tracepoint, this resulted in the 'struct xol_area' being freed multiple times if the task was killed at just the right time while forking. Fix it by setting ->uprobes_state.xol_area to NULL in mm_init() rather than in uprobe_dup_mmap(). With CONFIG_UPROBE_EVENTS=y, the bug can be reproduced by the same C program given by commit 2b7e8665b4ff ("fork: fix incorrect fput of ->exe_file causing use-after-free"), provided that a uprobe tracepoint has been set on the fork_thread() function. For example: $ gcc reproducer.c -o reproducer -lpthread $ nm reproducer | grep fork_thread 0000000000400719 t fork_thread $ echo "p $PWD/reproducer:0x719" > /sys/kernel/debug/tracing/uprobe_events $ echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable $ ./reproducer Here is the use-after-free reported by KASAN: BUG: KASAN: use-after-free in uprobe_clear_state+0x1c4/0x200 Read of size 8 at addr ffff8800320a8b88 by task reproducer/198 CPU: 1 PID: 198 Comm: reproducer Not tainted 4.13.0-rc7-00015-g36fde05f3fb5 #255 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014 Call Trace: dump_stack+0xdb/0x185 print_address_description+0x7e/0x290 kasan_report+0x23b/0x350 __asan_report_load8_noabort+0x19/0x20 uprobe_clear_state+0x1c4/0x200 mmput+0xd6/0x360 do_exit+0x740/0x1670 do_group_exit+0x13f/0x380 get_signal+0x597/0x17d0 do_signal+0x99/0x1df0 exit_to_usermode_loop+0x166/0x1e0 syscall_return_slowpath+0x258/0x2c0 entry_SYSCALL_64_fastpath+0xbc/0xbe ... Allocated by task 199: save_stack_trace+0x1b/0x20 kasan_kmalloc+0xfc/0x180 kmem_cache_alloc_trace+0xf3/0x330 __create_xol_area+0x10f/0x780 uprobe_notify_resume+0x1674/0x2210 exit_to_usermode_loop+0x150/0x1e0 prepare_exit_to_usermode+0x14b/0x180 retint_user+0x8/0x20 Freed by task 199: save_stack_trace+0x1b/0x20 kasan_slab_free+0xa8/0x1a0 kfree+0xba/0x210 uprobe_clear_state+0x151/0x200 mmput+0xd6/0x360 copy_process.part.8+0x605f/0x65d0 _do_fork+0x1a5/0xbd0 SyS_clone+0x19/0x20 do_syscall_64+0x22f/0x660 return_from_SYSCALL_64+0x0/0x7a Note: without KASAN, you may instead see a "Bad page state" message, or simply a general protection fault. Link: http://lkml.kernel.org/r/20170830033303.17927-1-ebiggers3@gmail.com Fixes: 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for write killable") Signed-off-by: Eric Biggers Reported-by: Oleg Nesterov Acked-by: Oleg Nesterov Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Dmitry Vyukov Cc: Ingo Molnar Cc: Konstantin Khlebnikov Cc: Mark Rutland Cc: Michal Hocko Cc: Peter Zijlstra Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 726bd348ead3883880912f686144854c8f2cf817 Author: Stephan Mueller Date: Wed Aug 16 11:56:24 2017 +0200 crypto: algif_skcipher - only call put_page on referenced and used pages commit 445a582738de6802669aeed9c33ca406c23c3b1f upstream. For asynchronous operation, SGs are allocated without a page mapped to them or with a page that is not used (ref-counted). If the SGL is freed, the code must only call put_page for an SG if there was a page assigned and ref-counted in the first place. This fixes a kernel crash when using io_submit with more than one iocb using the sendmsg and sendpage (vmsplice/splice) interface. Signed-off-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 44c6b4a966258bd8d05817f7c994789120a34958 Author: Stephen Douthit Date: Mon Aug 7 17:11:00 2017 -0400 i2c: ismt: Return EMSGSIZE for block reads with bogus length commit ba201c4f5ebe13d7819081756378777d8153f23e upstream. Compare the number of bytes actually seen on the wire to the byte count field returned by the slave device. Previously we just overwrote the byte count returned by the slave with the real byte count and let the caller figure out if the message was sane. Signed-off-by: Stephen Douthit Tested-by: Dan Priamo Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 7a90bfae634537530e1997fc352f8691127e6454 Author: Stephen Douthit Date: Mon Aug 7 17:10:59 2017 -0400 i2c: ismt: Don't duplicate the receive length for block reads commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream. According to Table 15-14 of the C2000 EDS (Intel doc #510524) the rx data pointed to by the descriptor dptr contains the byte count. desc->rxbytes reports all bytes read on the wire, including the "byte count" byte. So if a device sends 4 bytes in response to a block read, on the wire and in the DMA buffer we see: count data1 data2 data3 data4 0x04 0xde 0xad 0xbe 0xef That's what we want to return in data->block to the next level. Instead we were actually prefixing that with desc->rxbytes: bad count count data1 data2 data3 data4 0x05 0x04 0xde 0xad 0xbe 0xef This was discovered while developing a BMC solution relying on the ipmi_ssif.c driver which was trying to interpret the bogus length field as part of the IPMI response. Signed-off-by: Stephen Douthit Tested-by: Dan Priamo Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 6fb972d037512f59e4a9fffffe89ce59e815d8c4 Author: Ard Biesheuvel Date: Mon Aug 14 14:28:14 2017 +0100 crypto: chacha20 - fix handling of chunked input commit 4de437265eaac18f880d827f8e105b10de9b87a3 upstream. Commit 9ae433bc79f9 ("crypto: chacha20 - convert generic and x86 versions to skcipher") ported the existing chacha20 code to use the new skcipher API, and introduced a bug along the way. Unfortunately, the tcrypt tests did not catch the error, and it was only found recently by Tobias. Stefan kindly diagnosed the error, and proposed a fix which is similar to the one below, with the exception that 'walk.stride' is used rather than the hardcoded block size. This does not actually matter in this case, but it's a better example of how to use the skcipher walk API. Fixes: 9ae433bc79f9 ("crypto: chacha20 - convert generic and x86 ...") Cc: Steffen Klassert Reported-by: Tobias Brunner Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 6b31ae8707a7b988ad9d56059b57cb361041bdbc Author: Cameron Gutman Date: Thu Aug 31 11:52:20 2017 -0700 Input: xpad - fix PowerA init quirk for some gamepad models commit f5308d1b83eba20e69df5e0926ba7257c8dd9074 upstream. The PowerA gamepad initialization quirk worked with the PowerA wired gamepad I had around (0x24c6:0x543a), but a user reported [0] that it didn't work for him, even though our gamepads shared the same vendor and product IDs. When I initially implemented the PowerA quirk, I wanted to avoid actually triggering the rumble action during init. My tests showed that my gamepad would work correctly even if it received a rumble of 0 intensity, so that's what I went with. Unfortunately, this apparently isn't true for all models (perhaps a firmware difference?). This non-working gamepad seems to require the real magic rumble packet that the Microsoft driver sends, which actually vibrates the gamepad. To counteract this effect, I still send the old zero-rumble PowerA quirk packet which cancels the rumble effect before the motors can spin up enough to vibrate. [0]: https://github.com/paroj/xpad/issues/48#issuecomment-313904867 Reported-by: Kyle Beauchamp Tested-by: Kyle Beauchamp Fixes: 81093c9848a7 ("Input: xpad - support some quirky Xbox One pads") Signed-off-by: Cameron Gutman Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 2ed56448f555a1ceb8f3568d0bc49eb0a37f09ec Author: Anthony Martin Date: Mon Aug 28 10:26:12 2017 -0700 Input: synaptics - fix device info appearing different on reconnect commit 3f9db52dc87b003a1732f3e03f7f5fc8701ef4ad upstream. User-modified input settings no longer survive a suspend/resume cycle. Starting with 4.12, the touchpad is reinitialized on every reconnect because the hardware appears to be different. This can be reproduced by running the following as root: echo -n reconnect >/sys/devices/platform/i8042/serio1/drvctl A line like the following will show up in dmesg: [30378.295794] psmouse serio1: synaptics: hardware appears to be different: id(149271-149271), model(114865-114865), caps(d047b3-d047b1), ext(b40000-b40000). Note the single bit difference in caps: bit 1 (SYN_CAP_MULTIFINGER). This happens because we modify our stored copy of the device info capabilities when we enable advanced gesture mode but this change is not reflected in the actual hardware capabilities. It worked in the past because synaptics_query_hardware used to modify the stored synaptics_device_info struct instead of filling in a new one, as it does now. Fix it by no longer faking the SYN_CAP_MULTIFINGER bit when setting advanced gesture mode. This necessitated a small refactoring. Fixes: 6c53694fb222 ("Input: synaptics - split device info into a separate structure") Signed-off-by: Anthony Martin Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 55a5a10ce349eb7a033532ad61f0b327b218c02e Author: James Hogan Date: Sat Aug 12 21:36:09 2017 -0700 irqchip: mips-gic: SYNC after enabling GIC region commit 2c0e8382386f618c85d20cb05e7cf7df8cdd382c upstream. A SYNC is required between enabling the GIC region and actually trying to use it, even if the first access is a read, otherwise its possible depending on the timing (and in my case depending on the precise alignment of certain kernel code) to hit CM bus errors on that first access. Add the SYNC straight after setting the GIC base. [paul.burton@imgtec.com: Changes later in this series increase our likelihood of hitting this by reducing the amount of code that runs between enabling the GIC & accessing it.] Fixes: a7057270c280 ("irqchip: mips-gic: Add device-tree support") Signed-off-by: James Hogan Signed-off-by: Paul Burton Acked-by: Marc Zyngier Cc: Thomas Gleixner Cc: Jason Cooper Cc: James Hogan Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17019/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 6912089798119d9abd39c4954aa7bce1d640f11e Author: Arnd Bergmann Date: Wed Jul 19 14:53:02 2017 +0200 x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl commit 7206f9bf108eb9513d170c73f151367a1bdf3dbf upstream. The x86 version of insb/insw/insl uses an inline assembly that does not have the target buffer listed as an output. This can confuse the compiler, leading it to think that a subsequent access of the buffer is uninitialized: drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’: drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used uninitialized in this function [-Werror=uninitialized] drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/net/sb1000.c: In function 'sb1000_rx': drivers/net/sb1000.c:775:9: error: 'st[0]' is used uninitialized in this function [-Werror=uninitialized] drivers/net/sb1000.c:776:10: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/net/sb1000.c:784:11: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized] I tried to mark the exact input buffer as an output here, but couldn't figure it out. As suggested by Linus, marking all memory as clobbered however is good enough too. For the outs operations, I also add the memory clobber, to force the input to be written to local variables. This is probably already guaranteed by the "asm volatile", but it can't hurt to do this for symmetry. Suggested-by: Linus Torvalds Signed-off-by: Arnd Bergmann Acked-by: Linus Torvalds Cc: Borislav Petkov Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tom Lendacky Link: http://lkml.kernel.org/r/20170719125310.2487451-5-arnd@arndb.de Link: https://lkml.org/lkml/2017/7/12/605 Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 34ed350889ddd2023e70bfc33511971acf436b8d Author: Mark Rutland Date: Tue Jul 11 15:19:22 2017 +0100 arm64: mm: abort uaccess retries upon fatal signal commit 289d07a2dc6c6b6f3e4b8a62669320d99dbe6c3d upstream. When there's a fatal signal pending, arm64's do_page_fault() implementation returns 0. The intent is that we'll return to the faulting userspace instruction, delivering the signal on the way. However, if we take a fatal signal during fixing up a uaccess, this results in a return to the faulting kernel instruction, which will be instantly retried, resulting in the same fault being taken forever. As the task never reaches userspace, the signal is not delivered, and the task is left unkillable. While the task is stuck in this state, it can inhibit the forward progress of the system. To avoid this, we must ensure that when a fatal signal is pending, we apply any necessary fixup for a faulting kernel instruction. Thus we will return to an error path, and it is up to that code to make forward progress towards delivering the fatal signal. Cc: Catalin Marinas Cc: Laura Abbott Reviewed-by: Steve Capper Tested-by: Steve Capper Reviewed-by: James Morse Tested-by: James Morse Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman