commit 104d68b9d65d75e8269fb7f265d7047fcfa406b6 Author: Greg Kroah-Hartman Date: Wed Feb 20 10:29:16 2019 +0100 Linux 4.20.11 commit 35a050710f8401e37ffaff3c4fbe6ec92fbb5ade Author: Joonas Lahtinen Date: Thu Feb 7 10:54:53 2019 +0200 drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set commit 2e7bd10e05afb866b5fb13eda25095c35d7a27cc upstream. Make sure the underlying VMA in the process address space is the same as it was during vm_mmap to avoid applying WC to wrong VMA. A more long-term solution would be to have vm_mmap_locked variant in linux/mmap.h for when caller wants to hold mmap_sem for an extended duration. v2: - Refactor the compare function Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings for objects") Reported-by: Adam Zabrocki Suggested-by: Linus Torvalds Signed-off-by: Joonas Lahtinen Cc: # v4.0+ Cc: Akash Goel Cc: Chris Wilson Cc: Tvrtko Ursulin Cc: Adam Zabrocki Reviewed-by: Chris Wilson Reviewed-by: Tvrtko Ursulin #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20190207085454.10598-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 5c4604e757ba9b193b09768d75a7d2105a5b883f) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 25e25a437ef4f1167baa8ac100a50d5880f26841 Author: Lyude Paul Date: Tue Jan 29 14:09:59 2019 -0500 drm/i915: Block fbdev HPD processing during suspend commit e8a8fedd57fdcebf0e4f24ef0fc7e29323df8e66 upstream. When resuming, we check whether or not any previously connected MST topologies are still present and if so, attempt to resume them. If this fails, we disable said MST topologies and fire off a hotplug event so that userspace knows to reprobe. However, sending a hotplug event involves calling drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a connector reprobe in the caller's thread - something we can't do at the point in which i915 calls drm_dp_mst_topology_mgr_resume() since hotplugging hasn't been fully initialized yet. This currently causes some rather subtle but fatal issues. For example, on my T480s the laptop dock connected to it usually disappears during a suspend cycle, and comes back up a short while after the system has been resumed. This guarantees pretty much every suspend and resume cycle, drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn, a connector hotplug will occur. Now it's Rute Goldberg time: when the connector hotplug occurs, i915 reprobes /all/ of the connectors, including eDP. However, eDP probing requires that we power on the panel VDD which in turn, grabs a wakeref to the appropriate power domain on the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where things start breaking, since this all happens before intel_power_domains_enable() is called we end up leaking the wakeref that was acquired and never releasing it later. Come next suspend/resume cycle, this causes us to fail to shut down the GPU properly, which causes it not to resume properly and die a horrible complicated death. (as a note: this only happens when there's both an eDP panel and MST topology connected which is removed mid-suspend. One or the other seems to always be OK). We could try to fix the VDD wakeref leak, but this doesn't seem like it's worth it at all since we aren't able to handle hotplug detection while resuming anyway. So, let's go with a more robust solution inspired by nouveau: block fbdev from handling hotplug events until we resume fbdev. This allows us to still send sysfs hotplug events to be handled later by user space while we're resuming, while also preventing us from actually processing any hotplug events we receive until it's safe. This fixes the wakeref leak observed on the T480s and as such, also fixes suspend/resume with MST topologies connected on this machine. Changes since v2: * Don't call drm_fb_helper_hotplug_event() under lock, do it after lock (Chris Wilson) * Don't call drm_fb_helper_hotplug_event() in intel_fbdev_output_poll_changed() under lock (Chris Wilson) * Always set ifbdev->hpd_waiting (Chris Wilson) Signed-off-by: Lyude Paul Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)") Cc: Todd Previte Cc: Dave Airlie Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Imre Deak Cc: intel-gfx@lists.freedesktop.org Cc: # v3.17+ Reviewed-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com (cherry picked from commit fe5ec65668cdaa4348631d8ce1766eed43b33c10) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 02edc9fd969fda27dad1c3f52aef68205428beb2 Author: Eric Anholt Date: Fri Dec 7 11:16:53 2018 -0800 drm/sched: Always trace the dependencies we wait on, to fix a race. commit 82abf33766712d8446ea137a3400165e31bd12c7 upstream. The entity->dependency can go away completely once we've called drm_sched_entity_add_dependency_cb() (if the cb is called before we get around to tracing). The tracepoint is more useful if we trace every dependency instead of just ones that get callbacks installed, anyway, so just do that. Fixes any easy-to-produce OOPS when tracing the scheduler on V3D with "perf record -a -e gpu_scheduler:.\* glxgears" and DEBUG_SLAB enabled. Signed-off-by: Eric Anholt Reviewed-by: Christian König Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0887f86fd20d1aae062fb46942f97c5fccc00e6b Author: Rodrigo Siqueira Date: Wed Feb 6 12:01:16 2019 -0200 drm/vkms: Fix license inconsistent commit 7fd56e0260a22c0cfaf9adb94a2427b76e239dd0 upstream. Fixes license inconsistent related to the VKMS driver and remove the redundant boilerplate comment. Fixes: 854502fa0a38 ("drm/vkms: Add basic CRTC initialization") Cc: stable@vger.kernel.org Signed-off-by: Rodrigo Siqueira Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190206140116.7qvy2lpwbcd7wds6@smtp.gmail.com Signed-off-by: Greg Kroah-Hartman commit eee667bf128011f70d3ad350784dfa77d7050661 Author: Matthew Wilcox Date: Thu Feb 14 11:03:48 2019 -0800 drm: Use array_size() when creating lease commit 69ef943dbc14b21987c79f8399ffea08f9a1b446 upstream. Passing an object_count of sufficient size will make object_count * 4 wrap around to be very small, then a later function will happily iterate off the end of the object_ids array. Using array_size() will saturate at SIZE_MAX, the kmalloc() will fail and we'll return an -ENOMEM to the norty userspace. Fixes: 62884cd386b8 ("drm: Add four ioctls for managing drm mode object leases [v7]") Signed-off-by: Matthew Wilcox Acked-by: Kees Cook Acked-by: Daniel Vetter Cc: # v4.15+ Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e161e0ef3bbb2ffacd38bdc12c17d4ee6d764cb4 Author: Nikos Tsironis Date: Thu Feb 14 20:38:47 2019 +0200 dm thin: fix bug where bio that overwrites thin block ignores FUA commit 4ae280b4ee3463fa57bbe6eede26b97daff8a0f1 upstream. When provisioning a new data block for a virtual block, either because the block was previously unallocated or because we are breaking sharing, if the whole block of data is being overwritten the bio that triggered the provisioning is issued immediately, skipping copying or zeroing of the data block. When this bio completes the new mapping is inserted in to the pool's metadata by process_prepared_mapping(), where the bio completion is signaled to the upper layers. This completion is signaled without first committing the metadata. If the bio in question has the REQ_FUA flag set and the system crashes right after its completion and before the next metadata commit, then the write is lost despite the REQ_FUA flag requiring that I/O completion for this request must only be signaled after the data has been committed to non-volatile storage. Fix this by deferring the completion of overwrite bios, with the REQ_FUA flag set, until after the metadata has been committed. Cc: stable@vger.kernel.org Signed-off-by: Nikos Tsironis Acked-by: Joe Thornber Acked-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 8e15ceeb303f86a1523ae6eada108ad845fd6b2f Author: Mikulas Patocka Date: Fri Feb 8 10:52:07 2019 -0500 dm crypt: don't overallocate the integrity tag space commit ff0c129d3b5ecb3df7c8f5e2236582bf745b6c5f upstream. bio_sectors() returns the value in the units of 512-byte sectors (no matter what the real sector size of the device). dm-crypt multiplies bio_sectors() by on_disk_tag_size to calculate the space allocated for integrity tags. If dm-crypt is running with sector size larger than 512b, it allocates more data than is needed. Device Mapper trims the extra space when passing the bio to dm-integrity, so this bug didn't result in any visible misbehavior. But it must be fixed to avoid wasteful memory allocation for the block integrity payload. Fixes: ef43aa38063a6 ("dm crypt: add cryptographic data integrity protection (authenticated encryption)") Cc: stable@vger.kernel.org # 4.12+ Reported-by: Milan Broz Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit e6da3966d3d5c0237bbadb6d125bbe933f16c0e9 Author: Scott Mayhew Date: Fri Feb 15 13:42:02 2019 -0500 sunrpc: fix 4 more call sites that were using stack memory with a scatterlist commit e7afe6c1d486b516ed586dcc10b3e7e3e85a9c2b upstream. While trying to reproduce a reported kernel panic on arm64, I discovered that AUTH_GSS basically doesn't work at all with older enctypes on arm64 systems with CONFIG_VMAP_STACK enabled. It turns out there still a few places using stack memory with scatterlists, causing krb5_encrypt() and krb5_decrypt() to produce incorrect results (or a BUG if CONFIG_DEBUG_SG is enabled). Tested with cthon on v4.0/v4.1/v4.2 with krb5/krb5i/krb5p using des3-cbc-sha1 and arcfour-hmac-md5. Signed-off-by: Scott Mayhew Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit d6924af7705103617514b0e57103f53772751217 Author: Borislav Petkov Date: Tue Feb 12 14:28:03 2019 +0100 x86/a.out: Clear the dump structure initially commit 10970e1b4be9c74fce8ab6e3c34a7d718f063f2c upstream. dump_thread32() in aout_core_dump() does not clear the user32 structure allocated on the stack as the first thing on function entry. As a result, the dump.u_comm, dump.u_ar0 and dump.signal which get assigned before the clearing, get overwritten. Rename that function to fill_dump() to make it clear what it does and call it first thing. This was caught while staring at a patch by Derek Robson . Signed-off-by: Borislav Petkov Cc: Derek Robson Cc: Linus Torvalds Cc: Michael Matz Cc: x86@kernel.org Cc: Link: https://lkml.kernel.org/r/20190202005512.3144-1-robsonde@gmail.com Signed-off-by: Greg Kroah-Hartman commit d3028da7d556a7a0e2cd80ea3f31d67659296912 Author: Nate Dailey Date: Thu Feb 7 14:19:01 2019 -0500 md/raid1: don't clear bitmap bits on interrupted recovery. commit dfcc34c99f3ebc16b787b118763bf9cb6b1efc7a upstream. sync_request_write no longer submits writes to a Faulty device. This has the unfortunate side effect that bitmap bits can be incorrectly cleared if a recovery is interrupted (previously, end_sync_write would have prevented this). This means the next recovery may not copy everything it should, potentially corrupting data. Add a function for doing the proper md_bitmap_end_sync, called from end_sync_write and the Faulty case in sync_request_write. backport note to 4.14: s/md_bitmap_end_sync/bitmap_end_sync Cc: stable@vger.kernel.org 4.14+ Fixes: 0c9d5b127f69 ("md/raid1: avoid reusing a resync bio after error handling.") Reviewed-by: Jack Wang Tested-by: Jack Wang Signed-off-by: Nate Dailey Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit f2be76753b93473ccc86541b99544294df08392a Author: Gilad Ben-Yossef Date: Thu Feb 7 15:36:11 2019 +0200 crypto: ccree - fix resume race condition on init commit 1358c13a48c43f5e4de0c1835291837a27b9720c upstream. We were enabling autosuspend, which is using data set by the hash module, prior to the hash module being inited, casuing a crash on resume as part of the startup sequence if the race was lost. This was never a real problem because the PM infra was using low res timers so we were always winning the race, until commit 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") changed that :-) Fix this by seperating the PM setup and enablement and doing the latter only at the end of the init sequence. Signed-off-by: Gilad Ben-Yossef Cc: Vincent Guittot Cc: stable@kernel.org # v4.20 Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 303d5580fded225ae6f727a883b306a37a943099 Author: Eric W. Biederman Date: Mon Feb 11 23:27:42 2019 -0600 signal: Restore the stop PTRACE_EVENT_EXIT commit cf43a757fd49442bc38f76088b70c2299eed2c2f upstream. In the middle of do_exit() there is there is a call "ptrace_event(PTRACE_EVENT_EXIT, code);" That call places the process in TACKED_TRACED aka "(TASK_WAKEKILL | __TASK_TRACED)" and waits for for the debugger to release the task or SIGKILL to be delivered. Skipping past dequeue_signal when we know a fatal signal has already been delivered resulted in SIGKILL remaining pending and TIF_SIGPENDING remaining set. This in turn caused the scheduler to not sleep in PTACE_EVENT_EXIT as it figured a fatal signal was pending. This also caused ptrace_freeze_traced in ptrace_check_attach to fail because it left a per thread SIGKILL pending which is what fatal_signal_pending tests for. This difference in signal state caused strace to report strace: Exit of unknown pid NNNNN ignored Therefore update the signal handling state like dequeue_signal would when removing a per thread SIGKILL, by removing SIGKILL from the per thread signal mask and clearing TIF_SIGPENDING. Acked-by: Oleg Nesterov Reported-by: Oleg Nesterov Reported-by: Ivan Delalande Cc: stable@vger.kernel.org Fixes: 35634ffa1751 ("signal: Always notice exiting tasks") Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 341b0947fb40b69b12a9a0192f90c1414cd09a75 Author: James Bottomley Date: Tue Feb 12 08:05:25 2019 -0800 scsi: sd: fix entropy gathering for most rotational disks commit e4a056987c86f402f1286e050b1dee3f4ce7c7eb upstream. The problem is that the default for MQ is not to gather entropy, whereas the default for the legacy queue was always to gather it. The original attempt to fix entropy gathering for rotational disks under MQ added an else branch in sd_read_block_characteristics(). Unfortunately, the entire check isn't reached if the device has no characteristics VPD page. Since this page was only introduced in SBC-3 and its optional anyway, most less expensive rotational disks don't have one, meaning they all stopped gathering entropy when we made MQ the default. In a wholly unrelated change, openssl and openssh won't function until the random number generator is initialised, meaning lots of people have been seeing large delays before they could log into systems with default MQ kernels due to this lack of entropy, because it now can take tens of minutes to initialise the kernel random number generator. The fix is to set the non-rotational and add-randomness flags unconditionally early on in the disk initialization path, so they can be reset only if the device actually reports being non-rotational via the VPD page. Reported-by: Mikael Pettersson Fixes: 83e32a591077 ("scsi: sd: Contribute to randomness when running rotational device") Cc: stable@vger.kernel.org Signed-off-by: James Bottomley Reviewed-by: Jens Axboe Reviewed-by: Xuewei Zhang Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6e3e38226e70ae92af3ce8bff411147619963e54 Author: Michael Ellerman Date: Thu Feb 14 15:00:36 2019 +1100 powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present() commit a58007621be33e9f7c7bed5d5ff8ecb914e1044a upstream. In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT rather than just checking that the value is non-zero, e.g.: static inline int pgd_present(pgd_t pgd) { - return !pgd_none(pgd); + return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT)); } Unfortunately this is broken on big endian, as the result of the bitwise & is truncated to int, which is always zero because _PAGE_PRESENT is 0x8000000000000000ul. This means pgd_present() and pud_present() are always false at compile time, and the compiler elides the subsequent code. Remarkably with that bug present we are still able to boot and run with few noticeable effects. However under some work loads we are able to trigger a warning in the ext4 code: WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927 .ext4_set_page_dirty+0x70/0xb0 CPU: 11 PID: 29593 Comm: debugedit Not tainted 4.20.0-rc1 #1 ... NIP .ext4_set_page_dirty+0x70/0xb0 LR .set_page_dirty+0xa0/0x150 Call Trace: .set_page_dirty+0xa0/0x150 .unmap_page_range+0xbf0/0xe10 .unmap_vmas+0x84/0x130 .unmap_region+0xe8/0x190 .__do_munmap+0x2f0/0x510 .__vm_munmap+0x80/0x110 .__se_sys_munmap+0x14/0x30 system_call+0x5c/0x70 The fix is simple, we need to convert the result of the bitwise & to an int before returning it. Thanks to Erhard, Jan Kara and Aneesh for help with debugging. Fixes: da7ad366b497 ("powerpc/mm/book3s: Update pmd_present to look at _PAGE_PRESENT bit") Cc: stable@vger.kernel.org # v4.20+ Reported-by: Erhard F. Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 0a4908fafb770024606629c98ee7c8ae866add1b Author: Hedi Berriche Date: Wed Feb 13 19:34:13 2019 +0000 x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream. Calls into UV firmware must be protected against concurrency, expose the efi_runtime_lock to the UV platform, and use it to serialise UV BIOS calls. Signed-off-by: Hedi Berriche Signed-off-by: Borislav Petkov Reviewed-by: Ard Biesheuvel Reviewed-by: Russ Anderson Reviewed-by: Dimitri Sivanich Reviewed-by: Mike Travis Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Darren Hart Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: linux-efi Cc: platform-driver-x86@vger.kernel.org Cc: stable@vger.kernel.org # v4.9+ Cc: Steve Wahl Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berriche@hpe.com Signed-off-by: Greg Kroah-Hartman commit ebf5838d6da6a525c78ed55b3ee54c1a4e868d67 Author: Andreas Ziegler Date: Wed Feb 6 20:00:13 2019 +0100 tracing: probeevent: Correctly update remaining space in dynamic area commit f6675872db57305fa957021efc788f9983ed3b67 upstream. Commit 9178412ddf5a ("tracing: probeevent: Return consumed bytes of dynamic area") improved the string fetching mechanism by returning the number of required bytes after copying the argument to the dynamic area. However, this return value is now only used to increment the pointer inside the dynamic area but misses updating the 'maxlen' variable which indicates the remaining space in the dynamic area. This means that fetch_store_string() always reads the *total* size of the dynamic area from the data_loc pointer instead of the *remaining* size (and passes it along to strncpy_from_{user,unsafe}) even if we're already about to copy data into the middle of the dynamic area. Link: http://lkml.kernel.org/r/20190206190013.16405-1-andreas.ziegler@fau.de Cc: Ingo Molnar Cc: stable@vger.kernel.org Fixes: 9178412ddf5a ("tracing: probeevent: Return consumed bytes of dynamic area") Acked-by: Masami Hiramatsu Signed-off-by: Andreas Ziegler Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 4bbf187b4297f34b8cc3dca5cb2cb03c9343fd29 Author: Harald Freudenberger Date: Wed Jan 23 13:41:35 2019 +0100 s390/zcrypt: fix specification exception on z196 during ap probe commit 8f9aca0c45322a807a343fc32f95f2500f83b9ae upstream. The older machines don't have the QCI instruction available. With support for up to 256 crypto cards the probing of each card has been extended to check card ids from 0 up to 255. For machines with QCI support there is a filter limiting the range of probed cards. The older machines (z196 and older) don't have this filter and so since support for 256 cards is in the driver all cards are probed. However, these machines also require to have the card id fit into 6 bits. Exceeding this limit results in a specification exception which happens on every kernel startup even when there is no crypto configured and used at all. This fix limits the range of probed crypto cards to 64 if there is no QCI instruction available to obey to the older ap architecture and so fixes the specification exceptions on z196 machines. Cc: stable@vger.kernel.org # v4.17+ Fixes: af4a72276d49 ("s390/zcrypt: Support up to 256 crypto adapters.") Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit a5cf1ba495568bde0454eef408d4e921b51480d0 Author: Martin Schwidefsky Date: Thu Jan 17 11:20:28 2019 +0100 s390/suspend: fix stack setup in swsusp_arch_suspend commit 634692ab7007e8e3fec758ab0b26e65abf7c79e0 upstream. The patch that added support for the virtually mapped kernel stacks changed swsusp_arch_suspend to switch to the nodat-stack as the vmap stack is not available while going in and out of suspend. Unfortunately the switch to the nodat-stack is incorrect which breaks suspend to disk. Cc: stable@vger.kernel.org # v4.20 Fixes: ce3dc447493f ("s390: add support for virtually mapped kernel stacks") Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 67fcf0ff2eeb388b26c6eefbf76d30676db312fe Author: Meelis Roos Date: Fri Oct 12 12:27:51 2018 +0300 alpha: Fix Eiger NR_IRQS to 128 commit bfc913682464f45bc4d6044084e370f9048de9d5 upstream. Eiger machine vector definition has nr_irqs 128, and working 2.6.26 boot shows SCSI getting IRQ-s 64 and 65. Current kernel boot fails because Symbios SCSI fails to request IRQ-s and does not find the disks. It has been broken at least since 3.18 - the earliest I could test with my gcc-5. The headers have moved around and possibly another order of defines has worked in the past - but since 128 seems to be correct and used, fix arch/alpha/include/asm/irq.h to have NR_IRQS=128 for Eiger. This fixes 4.19-rc7 boot on my Force Flexor A264 (Eiger subarch). Cc: stable@vger.kernel.org # v3.18+ Signed-off-by: Meelis Roos Signed-off-by: Matt Turner Signed-off-by: Greg Kroah-Hartman commit 5e7a7fe3dac6362fd979da4c1ecc876d278f6009 Author: Sergei Trofimovich Date: Mon Dec 31 11:53:55 2018 +0000 alpha: fix page fault handling for r16-r18 targets commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream. Fix page fault handling code to fixup r16-r18 registers. Before the patch code had off-by-two registers bug. This bug caused overwriting of ps,pc,gp registers instead of fixing intended r16,r17,r18 (see `struct pt_regs`). More details: Initially Dmitry noticed a kernel bug as a failure on strace test suite. Test passes unmapped userspace pointer to io_submit: ```c #include #include #include #include int main(void) { unsigned long ctx = 0; if (syscall(__NR_io_setup, 1, &ctx)) err(1, "io_setup"); const size_t page_size = sysconf(_SC_PAGESIZE); const size_t size = page_size * 2; void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (MAP_FAILED == ptr) err(1, "mmap(%zu)", size); if (munmap(ptr, size)) err(1, "munmap"); syscall(__NR_io_submit, ctx, 1, ptr + page_size); syscall(__NR_io_destroy, ctx); return 0; } ``` Running this test causes kernel to crash when handling page fault: ``` Unable to handle kernel paging request at virtual address ffffffffffff9468 CPU 3 aio(26027): Oops 0 pc = [] ra = [] ps = 0000 Not tainted pc is at sys_io_submit+0x108/0x200 ra is at sys_io_submit+0x6c/0x200 v0 = fffffc00c58e6300 t0 = fffffffffffffff2 t1 = 000002000025e000 t2 = fffffc01f159fef8 t3 = fffffc0001009640 t4 = fffffc0000e0f6e0 t5 = 0000020001002e9e t6 = 4c41564e49452031 t7 = fffffc01f159c000 s0 = 0000000000000002 s1 = 000002000025e000 s2 = 0000000000000000 s3 = 0000000000000000 s4 = 0000000000000000 s5 = fffffffffffffff2 s6 = fffffc00c58e6300 a0 = fffffc00c58e6300 a1 = 0000000000000000 a2 = 000002000025e000 a3 = 00000200001ac260 a4 = 00000200001ac1e8 a5 = 0000000000000001 t8 = 0000000000000008 t9 = 000000011f8bce30 t10= 00000200001ac440 t11= 0000000000000000 pv = fffffc00006fd320 at = 0000000000000000 gp = 0000000000000000 sp = 00000000265fd174 Disabling lock debugging due to kernel taint Trace: [] entSys+0xa4/0xc0 ``` Here `gp` has invalid value. `gp is s overwritten by a fixup for the following page fault handler in `io_submit` syscall handler: ``` __se_sys_io_submit ... ldq a1,0(t1) bne t0,4280 <__se_sys_io_submit+0x180> ``` After a page fault `t0` should contain -EFALUT and `a1` is 0. Instead `gp` was overwritten in place of `a1`. This happens due to a off-by-two bug in `dpf_reg()` for `r16-r18` (aka `a0-a2`). I think the bug went unnoticed for a long time as `gp` is one of scratch registers. Any kernel function call would re-calculate `gp`. Dmitry tracked down the bug origin back to 2.1.32 kernel version where trap_a{0,1,2} fields were inserted into struct pt_regs. And even before that `dpf_reg()` contained off-by-one error. Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: linux-alpha@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reported-and-reviewed-by: "Dmitry V. Levin" Cc: stable@vger.kernel.org # v2.1.32+ Bug: https://bugs.gentoo.org/672040 Signed-off-by: Sergei Trofimovich Signed-off-by: Matt Turner Signed-off-by: Greg Kroah-Hartman commit effdc720834e58e9775c1ec78e0675f16eba460f Author: Sandeep Patil Date: Tue Feb 12 15:36:11 2019 -0800 mm: proc: smaps_rollup: fix pss_locked calculation commit 27dd768ed8db48beefc4d9e006c58e7a00342bde upstream. The 'pss_locked' field of smaps_rollup was being calculated incorrectly. It accumulated the current pss everytime a locked VMA was found. Fix that by adding to 'pss_locked' the same time as that of 'pss' if the vma being walked is locked. Link: http://lkml.kernel.org/r/20190203065425.14650-1-sspatil@android.com Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup") Signed-off-by: Sandeep Patil Acked-by: Vlastimil Babka Reviewed-by: Joel Fernandes (Google) Cc: Alexey Dobriyan Cc: Daniel Colascione Cc: [4.14.x, 4.19.x] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3aea1d1b31f14f5c49e8e7df6cbfe4b0055e6bde Author: Dave Chinner Date: Tue Feb 12 15:35:55 2019 -0800 Revert "mm: slowly shrink slabs with a relatively small number of objects" commit a9a238e83fbb0df31c3b9b67003f8f9d1d1b6c96 upstream. This reverts commit 172b06c32b9497 ("mm: slowly shrink slabs with a relatively small number of objects"). This change changes the agressiveness of shrinker reclaim, causing small cache and low priority reclaim to greatly increase scanning pressure on small caches. As a result, light memory pressure has a disproportionate affect on small caches, and causes large caches to be reclaimed much faster than previously. As a result, it greatly perturbs the delicate balance of the VFS caches (dentry/inode vs file page cache) such that the inode/dentry caches are reclaimed much, much faster than the page cache and this drives us into several other caching imbalance related problems. As such, this is a bad change and needs to be reverted. [ Needs some massaging to retain the later seekless shrinker modifications.] Link: http://lkml.kernel.org/r/20190130041707.27750-3-david@fromorbit.com Fixes: 172b06c32b9497 ("mm: slowly shrink slabs with a relatively small number of objects") Signed-off-by: Dave Chinner Cc: Wolfgang Walter Cc: Roman Gushchin Cc: Spock Cc: Rik van Riel Cc: Michal Hocko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 01b7eccaee41704ffe3cfbd441a1fed6367dc602 Author: Dave Chinner Date: Tue Feb 12 15:35:51 2019 -0800 Revert "mm: don't reclaim inodes with many attached pages" commit 69056ee6a8a3d576ed31e38b3b14c70d6c74edcc upstream. This reverts commit a76cf1a474d7d ("mm: don't reclaim inodes with many attached pages"). This change causes serious changes to page cache and inode cache behaviour and balance, resulting in major performance regressions when combining worklaods such as large file copies and kernel compiles. https://bugzilla.kernel.org/show_bug.cgi?id=202441 This change is a hack to work around the problems introduced by changing how agressive shrinkers are on small caches in commit 172b06c32b94 ("mm: slowly shrink slabs with a relatively small number of objects"). It creates more problems than it solves, wasn't adequately reviewed or tested, so it needs to be reverted. Link: http://lkml.kernel.org/r/20190130041707.27750-2-david@fromorbit.com Fixes: a76cf1a474d7d ("mm: don't reclaim inodes with many attached pages") Signed-off-by: Dave Chinner Cc: Wolfgang Walter Cc: Roman Gushchin Cc: Spock Cc: Rik van Riel Cc: Michal Hocko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 01e62eb792ca97e66977fa9d2cb12612f705fc1b Author: J. Bruce Fields Date: Thu Feb 14 12:33:19 2019 -0500 Revert "nfsd4: return default lease period" commit 3bf6b57ec2ec945e5a6edf5c202a754f1e852ecd upstream. This reverts commit d6ebf5088f09472c1136cd506bdc27034a6763f8. I forgot that the kernel's default lease period should never be decreased! After a kernel upgrade, the kernel has no way of knowing on its own what the previous lease time was. Unless userspace tells it otherwise, it will assume the previous lease period was the same. So if we decrease this value in a kernel upgrade, we end up enforcing a grace period that's too short, and clients will fail to reclaim state in time. Symptoms may include EIO and log messages like "NFS: nfs4_reclaim_open_state: Lock reclaim failed!" There was no real justification for the lease period decrease anyway. Reported-by: Donald Buczek Fixes: d6ebf5088f09 "nfsd4: return default lease period" Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 7618600f3e08dd7ef85d7bad797852315db6351a Author: Matti Kurkela Date: Thu Feb 7 23:49:23 2019 -0800 Input: elantech - enable 3rd button support on Fujitsu CELSIUS H780 commit e8b22d0a329f0fb5c7ef95406872d268f01ee3b1 upstream. Like Fujitsu CELSIUS H760, the H780 also has a three-button Elantech touchpad, but the driver needs to be told so to enable the middle touchpad button. The elantech_dmi_force_crc_enabled quirk was not necessary with the H780. Also document the fw_version and caps values detected for both H760 and H780 models. Signed-off-by: Matti Kurkela Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f2ffc237268a158dfece0b3e926a4a1e45657efa Author: Jonathan Bakker Date: Wed Feb 6 10:45:37 2019 -0800 Input: bma150 - register input device after setting private data commit 90cc55f067f6ca0e64e5e52883ece47d8af7b67b upstream. Otherwise we introduce a race condition where userspace can request input before we're ready leading to null pointer dereference such as input: bma150 as /devices/platform/i2c-gpio-2/i2c-5/5-0038/input/input3 Unable to handle kernel NULL pointer dereference at virtual address 00000018 pgd = (ptrval) [00000018] *pgd=55dac831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT ARM Modules linked in: bma150 input_polldev [last unloaded: bma150] CPU: 0 PID: 2870 Comm: accelerometer Not tainted 5.0.0-rc3-dirty #46 Hardware name: Samsung S5PC110/S5PV210-based board PC is at input_event+0x8/0x60 LR is at bma150_report_xyz+0x9c/0xe0 [bma150] pc : [<80450f70>] lr : [<7f0a614c>] psr: 800d0013 sp : a4c1fd78 ip : 00000081 fp : 00020000 r10: 00000000 r9 : a5e2944c r8 : a7455000 r7 : 00000016 r6 : 00000101 r5 : a7617940 r4 : 80909048 r3 : fffffff2 r2 : 00000000 r1 : 00000003 r0 : 00000000 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 54e34019 DAC: 00000051 Process accelerometer (pid: 2870, stack limit = 0x(ptrval)) Stackck: (0xa4c1fd78 to 0xa4c20000) fd60: fffffff3 fc813f6c fd80: 40410581 d7530ce3 a5e2817c a7617f00 a5e29404 a5e2817c 00000000 7f008324 fda0: a5e28000 8044f59c a5fdd9d0 a5e2945c a46a4a00 a5e29668 a7455000 80454f10 fdc0: 80909048 a5e29668 a5fdd9d0 a46a4a00 806316d0 00000000 a46a4a00 801df5f0 fde0: 00000000 d7530ce3 a4c1fec0 a46a4a00 00000000 a5fdd9d0 a46a4a08 801df53c fe00: 00000000 801d74bc a4c1fec0 00000000 a4c1ff70 00000000 a7038da8 00000000 fe20: a46a4a00 801e91fc a411bbe0 801f2e88 00000004 00000000 80909048 00000041 fe40: 00000000 00020000 00000000 dead4ead a6a88da0 00000000 ffffe000 806fcae8 fe60: a4c1fec8 00000000 80909048 00000002 a5fdd9d0 a7660110 a411bab0 00000001 fe80: dead4ead ffffffff ffffffff a4c1fe8c a4c1fe8c d7530ce3 20000013 80909048 fea0: 80909048 a4c1ff70 00000001 fffff000 a4c1e000 00000005 00026038 801eabd8 fec0: a7660110 a411bab0 b9394901 00000006 a696201b 76fb3000 00000000 a7039720 fee0: a5fdd9d0 00000101 00000002 00000096 00000000 00000000 00000000 a4c1ff00 ff00: a6b310f4 805cb174 a6b310f4 00000010 00000fe0 00000010 a4c1e000 d7530ce3 ff20: 00000003 a5f41400 a5f41424 00000000 a6962000 00000000 00000003 00000002 ff40: ffffff9c 000a0000 80909048 d7530ce3 a6962000 00000003 80909048 ffffff9c ff60: a6962000 801d890c 00000000 00000000 00020000 a7590000 00000004 00000100 ff80: 00000001 d7530ce3 000288b8 00026320 000288b8 00000005 80101204 a4c1e000 ffa0: 00000005 80101000 000288b8 00026320 000288b8 000a0000 00000000 00000000 ffc0: 000288b8 00026320 000288b8 00000005 7eef3bac 000264e8 00028ad8 00026038 ffe0: 00000005 7eef3300 76f76e91 76f78546 800d0030 000288b8 00000000 00000000 [<80450f70>] (input_event) from [] (0xa5e2817c) Code: e1a08148 eaffffa8 e351001f 812fff1e (e590c018) ---[ end trace 1c691ee85f2ff243 ]--- Signed-off-by: Jonathan Bakker Signed-off-by: Paweł Chmiel Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 1fdf7b8b061251324af0e53046605c478024f95f Author: Zachary Hays Date: Thu Feb 7 10:03:08 2019 -0500 mmc: block: handle complete_work on separate workqueue commit dcf6e2e38a1c7ccbc535de5e1d9b14998847499d upstream. The kblockd workqueue is created with the WQ_MEM_RECLAIM flag set. This generates a rescuer thread for that queue that will trigger when the CPU is under heavy load and collect the uncompleted work. In the case of mmc, this creates the possibility of a deadlock when there are multiple partitions on the device as other blk-mq work is also run on the same queue. For example: - worker 0 claims the mmc host to work on partition 1 - worker 1 attempts to claim the host for partition 2 but has to wait for worker 0 to finish - worker 0 schedules complete_work to release the host - rescuer thread is triggered after time-out and collects the dangling work - rescuer thread attempts to complete the work in order starting with claim host - the task to release host is now blocked by a task to claim it and will never be called The above results in multiple hung tasks that lead to failures to mount partitions. Handling complete_work on a separate workqueue avoids this by keeping the work completion tasks separate from the other blk-mq work. This allows the host to be released without getting blocked by other tasks attempting to claim the host. Signed-off-by: Zachary Hays Fixes: 81196976ed94 ("mmc: block: Add blk-mq support") Cc: Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit cb384113e6146db1c951abeb75852b77972c570f Author: Chen-Yu Tsai Date: Tue Feb 5 23:42:24 2019 +0800 mmc: sunxi: Filter out unsupported modes declared in the device tree commit d6f11e7d91f2ac85f66194fe3ef8789b49901d64 upstream. The MMC device tree bindings include properties used to signal various signalling speed modes. Until now the sunxi driver was accepting them without any further filtering, while the sunxi device trees were not actually using them. Since some of the H5 boards can not run at higher speed modes stably, we are resorting to declaring the higher speed modes per-board. Regardless, having boards declare modes and blindly following them, even without proper support in the driver, is generally a bad thing. Filter out all unsupported modes from the capabilities mask after the device tree properties have been parsed. Cc: Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit b60a14889ba2bc4a4c20fde1b6bb436c61cdd485 Author: Chen-Yu Tsai Date: Tue Feb 5 23:42:23 2019 +0800 mmc: sunxi: Disable HS-DDR mode for H5 eMMC controller by default commit d49d92ace4974510dd5845ff91860823cf30dc08 upstream. Some H5 boards seem to not have proper trace lengths for eMMC to be able to use the default setting for the delay chains under HS-DDR mode. These include the Bananapi M2+ H5 and NanoPi NEO Core2. However the Libre Computer ALL-H3-CC-H5 works just fine. For the H5 (at least for now), default to not enabling HS-DDR modes in the driver, and expect the device tree to signal HS-DDR capability on boards that work. Reported-by: Chris Blake Fixes: 07bafc1e3536 ("mmc: sunxi: Use new timing mode for A64 eMMC controller") Cc: Acked-by: Maxime Ripard Signed-off-by: Chen-Yu Tsai Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 85374e1d594e4a5de40771351ebd68854be8662c Author: Xiaoyao Li Date: Thu Feb 14 12:08:58 2019 +0800 kvm: vmx: Fix entry number check for add_atomic_switch_msr() commit 98ae70cc476e833332a2c6bb72f941a25f0de226 upstream. Commit ca83b4a7f2d068da79a0 ("x86/KVM/VMX: Add find_msr() helper function") introduces the helper function find_msr(), which returns -ENOENT when not find the msr in vmx->msr_autoload.guest/host. Correct checking contion of no more available entry in vmx->msr_autoload. Fixes: ca83b4a7f2d0 ("x86/KVM/VMX: Add find_msr() helper function") Cc: stable@vger.kernel.org Signed-off-by: Xiaoyao Li Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit dbb8a5c24afa00e5e519c8457fa6c2af29916c96 Author: Vitaly Kuznetsov Date: Thu Feb 7 11:42:14 2019 +0100 x86/kvm/nVMX: read from MSR_IA32_VMX_PROCBASED_CTLS2 only when it is available commit 6b1971c694975e49af302229202c0043568b1791 upstream. SDM says MSR_IA32_VMX_PROCBASED_CTLS2 is only available "If (CPUID.01H:ECX.[5] && IA32_VMX_PROCBASED_CTLS[63])". It was found that some old cpus (namely "Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (family: 0x6, model: 0xf, stepping: 0x6") don't have it. Add the missing check. Reported-by: Zdenek Kaspar Tested-by: Zdenek Kaspar Signed-off-by: Vitaly Kuznetsov Reviewed-by: Jim Mattson Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 09b2a6a55c2a239fb77a266b1093418e8de4c445 Author: Stefan O'Rear Date: Sun Dec 16 13:03:36 2018 -0500 riscv: Add pte bit to distinguish swap from invalid commit e3613bb8afc2a9474c9214d65c8326c5ac02135e upstream. Previously, invalid PTEs and swap PTEs had the same binary representation, causing errors when attempting to unmap PROT_NONE mappings, including implicit unmap on exit. Typical error: swap_info_get: Bad swap file entry 40000000007a9879 BUG: Bad page map in process a.out pte:3d4c3cc0 pmd:3e521401 Cc: stable@vger.kernel.org Signed-off-by: Stefan O'Rear Reviewed-by: Christoph Hellwig Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 24e99fcdc91a96e1ba5eafc6e17f12eaf2fd6d09 Author: Bob Tracy Date: Mon Jan 21 21:09:14 2019 -0800 tools uapi: fix Alpha support commit 842fc0f5dc5c9f9bd91f891554996d903c40cf35 upstream. Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Bob Tracy Signed-off-by: Matt Turner Signed-off-by: Greg Kroah-Hartman commit 0a611997a9737c99f2bb5eefda836e0b5738a3d7 Author: Russell King Date: Thu Jan 17 17:32:05 2019 +0000 ASoC: hdmi-codec: fix oops on re-probe commit 0ce23d6d42147a692768e6baaaa3db75c44f4235 upstream. hdmi-codec oopses the kernel when it is unbound from a successfully bound audio subsystem, and is then rebound: Unable to handle kernel NULL pointer dereference at virtual address 0000001c pgd = ee3f0000 [0000001c] *pgd=3cc59831 Internal error: Oops: 817 [#1] PREEMPT ARM Modules linked in: ext2 snd_soc_spdif_tx vmeta dove_thermal snd_soc_kirkwood ofpart marvell_cesa m25p80 orion_wdt mtd spi_nor des_generic gpio_ir_recv snd_soc_kirkwood_spdif bmm_dmabuf auth_rpcgss nfsd autofs4 etnaviv thermal_sys hwmon gpu_sched tda9950 CPU: 0 PID: 1005 Comm: bash Not tainted 4.20.0+ #1762 Hardware name: Marvell Dove (Cubox) PC is at hdmi_dai_probe+0x68/0x80 LR is at find_held_lock+0x20/0x94 pc : [] lr : [] psr: 600f0013 sp : ee15bd28 ip : eebd8b1c fp : c093b488 r10: ee048000 r9 : eebdab18 r8 : ee048600 r7 : 00000001 r6 : 00000000 r5 : 00000000 r4 : ee82c100 r3 : 00000006 r2 : 00000001 r1 : c067e38c r0 : ee82c100 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none[ 297.318599] Control: 10c5387d Table: 2e3f0019 DAC: 00000051 Process bash (pid: 1005, stack limit = 0xee15a248) ... [] (hdmi_dai_probe) from [] (soc_probe_dai.part.9+0x34/0x70) [] (soc_probe_dai.part.9) from [] (snd_soc_instantiate_card+0x734/0xc9c) [] (snd_soc_instantiate_card) from [] (snd_soc_add_component+0x29c/0x378) [] (snd_soc_add_component) from [] (snd_soc_register_component+0x44/0x54) [] (snd_soc_register_component) from [] (devm_snd_soc_register_component+0x48/0x84) [] (devm_snd_soc_register_component) from [] (hdmi_codec_probe+0x150/0x260) [] (hdmi_codec_probe) from [] (platform_drv_probe+0x48/0x98) This happens because hdmi_dai_probe() attempts to access the HDMI codec private data, but this has not been assigned by hdmi_dai_probe() before it calls devm_snd_soc_register_component(). Move the call to dev_set_drvdata() before devm_snd_soc_register_component() to avoid this oops. Signed-off-by: Russell King Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1529b10ad0a01885510e7d4513bca06e95caa0e9 Author: Takashi Iwai Date: Wed Feb 6 07:30:44 2019 +0100 ALSA: pcm: Revert capture stream behavior change in blocking mode commit 00a399cad1a063e7665f06b6497a807db20441fd upstream. In the commit 62ba568f7aef ("ALSA: pcm: Return 0 when size < start_threshold in capture"), we changed the behavior of __snd_pcm_lib_xfer() to return immediately with 0 when a capture stream has a high start_threshold. This was intended to be a correction of the behavior consistency and looked harmless, but this was the culprit of the recent breakage reported by syzkaller, which was fixed by the commit e190161f96b8 ("ALSA: pcm: Fix tight loop of OSS capture stream"). At the time for the OSS fix, I didn't touch the behavior for ALSA native API, as assuming that this behavior actually is good. But this turned out to be also broken actually for a similar deployment, e.g. one thread goes to a write loop in blocking mode while another thread controls the start/stop of the stream manually. Overall, the original commit is harmful, and it brings less merit to keep that behavior. Let's revert it. Fixes: 62ba568f7aef ("ALSA: pcm: Return 0 when size < start_threshold in capture") Fixes: e190161f96b8 ("ALSA: pcm: Fix tight loop of OSS capture stream") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 80084a4dcc4a8858f8d0ac1dd7b5d42d59dad92c Author: Manuel Reinhardt Date: Thu Jan 31 15:32:35 2019 +0100 ALSA: usb-audio: Fix implicit fb endpoint setup by quirk commit 2bc16b9f3223d049b57202ee702fcb5b9b507019 upstream. The commit a60945fd08e4 ("ALSA: usb-audio: move implicit fb quirks to separate function") introduced an error in the handling of quirks for implicit feedback endpoints. This commit fixes this. If a quirk successfully sets up an implicit feedback endpoint, usb-audio no longer tries to find the implicit fb endpoint itself. Fixes: a60945fd08e4 ("ALSA: usb-audio: move implicit fb quirks to separate function") Signed-off-by: Manuel Reinhardt Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5610fd7da5e36daae7a5fd4e1331c50d3431dda5 Author: Jurica Vukadin Date: Thu Feb 7 16:29:37 2019 +0100 ALSA: hda - Add quirk for HP EliteBook 840 G5 commit 4cd3016ce996494f78fdfd87ea35c8ca5d0b413e upstream. This enables mute LED support and fixes switching jacks when the laptop is docked. Signed-off-by: Jurica Vukadin Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6a66c2d00018fad3b79b75980c0f3602c5d188fc Author: Jiri Olsa Date: Mon Feb 4 13:35:32 2019 +0100 perf/x86: Add check_period PMU callback commit 81ec3f3c4c4d78f2d3b6689c9816bfbdf7417dbb upstream. Vince (and later on Ravi) reported crashes in the BTS code during fuzzing with the following backtrace: general protection fault: 0000 [#1] SMP PTI ... RIP: 0010:perf_prepare_sample+0x8f/0x510 ... Call Trace: ? intel_pmu_drain_bts_buffer+0x194/0x230 intel_pmu_drain_bts_buffer+0x160/0x230 ? tick_nohz_irq_exit+0x31/0x40 ? smp_call_function_single_interrupt+0x48/0xe0 ? call_function_single_interrupt+0xf/0x20 ? call_function_single_interrupt+0xa/0x20 ? x86_schedule_events+0x1a0/0x2f0 ? x86_pmu_commit_txn+0xb4/0x100 ? find_busiest_group+0x47/0x5d0 ? perf_event_set_state.part.42+0x12/0x50 ? perf_mux_hrtimer_restart+0x40/0xb0 intel_pmu_disable_event+0xae/0x100 ? intel_pmu_disable_event+0xae/0x100 x86_pmu_stop+0x7a/0xb0 x86_pmu_del+0x57/0x120 event_sched_out.isra.101+0x83/0x180 group_sched_out.part.103+0x57/0xe0 ctx_sched_out+0x188/0x240 ctx_resched+0xa8/0xd0 __perf_event_enable+0x193/0x1e0 event_function+0x8e/0xc0 remote_function+0x41/0x50 flush_smp_call_function_queue+0x68/0x100 generic_smp_call_function_single_interrupt+0x13/0x30 smp_call_function_single_interrupt+0x3e/0xe0 call_function_single_interrupt+0xf/0x20 The reason is that while event init code does several checks for BTS events and prevents several unwanted config bits for BTS event (like precise_ip), the PERF_EVENT_IOC_PERIOD allows to create BTS event without those checks being done. Following sequence will cause the crash: If we create an 'almost' BTS event with precise_ip and callchains, and it into a BTS event it will crash the perf_prepare_sample() function because precise_ip events are expected to come in with callchain data initialized, but that's not the case for intel_pmu_drain_bts_buffer() caller. Adding a check_period callback to be called before the period is changed via PERF_EVENT_IOC_PERIOD. It will deny the change if the event would become BTS. Plus adding also the limit_period check as well. Reported-by: Vince Weaver Signed-off-by: Jiri Olsa Acked-by: Peter Zijlstra Cc: Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Naveen N. Rao Cc: Ravi Bangoria Cc: Stephane Eranian Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20190204123532.GA4794@krava Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit d26f63553b274355a18c515b891927b916beeba5 Author: Ingo Molnar Date: Wed Feb 13 07:57:02 2019 +0100 perf/core: Fix impossible ring-buffer sizes warning commit 528871b456026e6127d95b1b2bd8e3a003dc1614 upstream. The following commit: 9dff0aa95a32 ("perf/core: Don't WARN() for impossible ring-buffer sizes") results in perf recording failures with larger mmap areas: root@skl:/tmp# perf record -g -a failed to mmap with 12 (Cannot allocate memory) The root cause is that the following condition is buggy: if (order_base_2(size) >= MAX_ORDER) goto fail; The problem is that @size is in bytes and MAX_ORDER is in pages, so the right test is: if (order_base_2(size) >= PAGE_SHIFT+MAX_ORDER) goto fail; Fix it. Reported-by: "Jin, Yao" Bisected-by: Borislav Petkov Analyzed-by: Peter Zijlstra Cc: Julien Thierry Cc: Mark Rutland Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Fixes: 9dff0aa95a32 ("perf/core: Don't WARN() for impossible ring-buffer sizes") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 89e5eb10b65b79259b4c8e1ac9c7ebce86270df5 Author: Tony Lindgren Date: Tue Jan 15 10:09:38 2019 -0800 ARM: OMAP5+: Fix inverted nirq pin interrupts with irq_set_type commit d0243693fbf6fbd48b4efb2ba7210765983b03e3 upstream. Commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") started warning about incorrect dts usage for irqs. ARM GIC only supports active-high interrupts for SPI (Shared Peripheral Interrupts), and the Palmas PMIC by default is active-low. Palmas PMIC allows changing the interrupt polarity using register PALMAS_POLARITY_CTRL_INT_POLARITY, but configuring sys_nirq1 with a pull-down and setting PALMAS_POLARITY_CTRL_INT_POLARITY made the Palmas RTC interrupts stop working. This can be easily tested with kernel tools rtctest.c. Turns out the SoC inverts the sys_nirq pins for GIC as they do not go through a peripheral device but go directly to the MPUSS wakeupgen. I've verified this by muxing the interrupt line temporarily to gpio_wk16 instead of sys_nirq1. with a gpio, the interrupt works fine both active-low and active-high with the SoC internal pull configured and palmas polarity configured. But as sys_nirq1, the interrupt only works when configured ACTIVE_LOW for palmas, and ACTIVE_HIGH for GIC. Note that there was a similar issue earlier with tegra114 and palmas interrupt polarity that got fixed by commit df545d1cd01a ("mfd: palmas: Provide irq flags through DT/platform data"). However, the difference between omap5 and tegra114 is that tegra inverts the palmas interrupt twice, once when entering tegra PMC, and again when exiting tegra PMC to GIC. Let's fix the issue by adding a custom wakeupgen_irq_set_type() for wakeupgen and invert any interrupts with wrong polarity. Let's also warn about any non-sysnirq pins using wrong polarity. Note that we also need to update the dts for the level as IRQ_TYPE_NONE never has irq_set_type() called, and let's add some comments and use proper pin nameing to avoid more confusion later on. Cc: Belisko Marek Cc: Dmitry Lifshitz Cc: "Dr. H. Nikolaus Schaller" Cc: Jon Hunter Cc: Keerthy Cc: Laxman Dewangan Cc: Nishanth Menon Cc: Peter Ujfalusi Cc: Richard Woodruff Cc: Santosh Shilimkar Cc: Tero Kristo Cc: Thierry Reding Cc: stable@vger.kernel.org # v4.17+ Reported-by: Belisko Marek Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit be0b53574ed31b4f572d53fdd68c003ad6b5c520 Author: Dmitry Voytik Date: Tue Jan 22 23:38:48 2019 +0100 arm64: dts: rockchip: enable usb-host regulators at boot on rk3328-rock64 commit 26e2d7b03ea7ff254bf78305aa44dda62e70b78e upstream. After commit ef05bcb60c1a, boot from USB drives is broken. Fix this problem by enabling usb-host regulators during boot time. Fixes: ef05bcb60c1a ("arm64: dts: rockchip: fix vcc_host1_5v pin assign on rk3328-rock64") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Voytik Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 8e954647a700f27ddd57d80f65c4fe15315520eb Author: Mauro Ciancio Date: Mon Jan 14 10:24:53 2019 -0300 Input: elan_i2c - add ACPI ID for touchpad in Lenovo V330-15ISK commit 7ad222b3aed350adfc27ee7eec4587ffe55dfdce upstream. This adds ELAN0617 to the ACPI table to support Elan touchpad found in Lenovo V330-15ISK. Signed-off-by: Mauro Ciancio Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit b383c5e3707b51b76a51a43dc9a2516b422a17ac Author: Dmitry Torokhov Date: Mon Feb 11 14:32:40 2019 -0800 Revert "Input: elan_i2c - add ACPI ID for touchpad in ASUS Aspire F5-573G" commit f420c54e4b12c1361c6ed313002ee7bd7ac58362 upstream. This reverts commit 7db54c89f0b30a101584e09d3729144e6170059d as it breaks Acer Aspire V-371 and other devices. According to Elan: "Acer Aspire F5-573G is MS Precision touchpad which should use hid multitouch driver. ELAN0501 should not be added in elan_i2c." Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202503 Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 54e04aac37f454a2d6acf8f0f1b3a68554bfdcc2 Author: Anson Huang Date: Sun Feb 17 23:05:33 2019 +0100 gpio: mxc: move gpio noirq suspend/resume to syscore phase commit 1a5287a3dbc34cd0c02c8f64c9131bd23cdfe2bb upstream. During noirq suspend/resume phase, GPIO irq could arrive and its registers like IMR will be changed by irq handle process, to make the GPIO registers exactly when it is powered ON after resume, move the GPIO noirq suspend/resume callback to syscore suspend/resume phase, local irq is disabled at this phase so GPIO registers are atomic. Fixes: c19fdaeea0aa ("gpio: mxc: add power management support") Signed-off-by: Anson Huang Signed-off-by: Linus Walleij Signed-off-by: Martin Hundebøll Cc: # 4.19.x+ Signed-off-by: Sasha Levin commit 75d2ac0c0432e93362ab7fb7b250068ef772fba0 Author: Pavel Shilovsky Date: Wed Jan 16 11:48:42 2019 -0800 CIFS: Fix mounts if the client is low on credits [ Upstream commit 6a9cbdd1ceca1dc2359ddf082efe61b97c3e752b ] If the server doesn't grant us at least 3 credits during the mount we won't be able to complete it because query path info operation requires 3 credits. Use the cached file handle if possible to allow the mount to succeed. Signed-off-by: Pavel Shilovsky Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 8beb5d8df1481932d35450ca7a328a240916f419 Author: Pavel Shilovsky Date: Tue Jan 15 15:08:48 2019 -0800 CIFS: Do not assume one credit for async responses [ Upstream commit 0fd1d37b0501efc6e295f56ab55cdaff784aa50c ] If we don't receive a response we can't assume that the server granted one credit. Assume zero credits in such cases. Signed-off-by: Pavel Shilovsky Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7cb453e5a88169b2a5cec1e00778fc969efd1a77 Author: Pavel Shilovsky Date: Tue Jan 22 16:50:21 2019 -0800 CIFS: Fix credit calculations in compound mid callback [ Upstream commit 3d3003fce8e837acc4e3960fe3cbabebc356dcb5 ] The current code doesn't do proper accounting for credits in SMB1 case: it adds one credit per response only if we get a complete response while it needs to return it unconditionally. Fix this and also include malformed responses for SMB2+ into accounting for credits because such responses have Credit Granted field, thus nothing prevents to get a proper credit value from them. Signed-off-by: Pavel Shilovsky Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit fe182af7767ae01c87b5673ddb7697723673063e Author: David Rientjes Date: Wed Jan 2 12:56:33 2019 -0800 kvm: sev: Fail KVM_SEV_INIT if already initialized [ Upstream commit 3f14a89d1132dcae3c8ce6721c6ef51f6e6d9b5f ] By code inspection, it was found that multiple calls to KVM_SEV_INIT could deplete asid bits and overwrite kvm_sev_info's regions_list. Multiple calls to KVM_SVM_INIT is not likely to occur with QEMU, but this should likely be fixed anyway. This code is serialized by kvm->lock. Fixes: 1654efcbc431 ("KVM: SVM: Add KVM_SEV_INIT command") Reported-by: Cfir Cohen Signed-off-by: David Rientjes Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 5443a09712e7962a10d8f5801a1cc4598aaa2966 Author: Pavel Shilovsky Date: Tue Jan 8 11:15:28 2019 -0800 CIFS: Fix error paths in writeback code [ Upstream commit 9a66396f1857cc1de06f4f4771797315e1a4ea56 ] This patch aims to address writeback code problems related to error paths. In particular it respects EINTR and related error codes and stores and returns the first error occurred during writeback. Signed-off-by: Pavel Shilovsky Acked-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3c57a0be487088b08d9c88998f911eb4a7ba36e4 Author: Pavel Shilovsky Date: Thu Jan 3 15:53:10 2019 -0800 CIFS: Move credit processing to mid callbacks for SMB3 [ Upstream commit ee258d79159afed52ca9372aeb9c1a51e89b32ee ] Currently we account for credits in the thread initiating a request and waiting for a response. The demultiplex thread receives the response, wakes up the thread and the latter collects credits from the response buffer and add them to the server structure on the client. This approach is not accurate, because it may race with reconnect events in the demultiplex thread which resets the number of credits. Fix this by moving credit processing to new mid callbacks that collect credits granted by the server from the response in the demultiplex thread. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 75d8ed18255ee379e7441812b5a8e7e28a452d21 Author: Pavel Shilovsky Date: Thu Jan 3 16:45:27 2019 -0800 CIFS: Fix credits calculation for cancelled requests [ Upstream commit 8a26f0f781f56d3016b34a2217e346973d067e7b ] If a request is cancelled, we can't assume that the server returns 1 credit back. Instead we need to wait for a response and process the number of credits granted by the server. Create a separate mid callback for cancelled request, parse the number of credits in a response buffer and add them to the client's credits. If the didn't get a response (no response buffer available) assume 0 credits granted. The latter most probably happens together with session reconnect, so the client's credits are adjusted anyway. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f3c42f9b10ce13bd52b167c045399df1619b5080 Author: Ross Lagerwall Date: Tue Jan 8 18:30:56 2019 +0000 cifs: Limit memory used by lock request calls to a page [ Upstream commit 92a8109e4d3a34fb6b115c9098b51767dc933444 ] The code tries to allocate a contiguous buffer with a size supplied by the server (maxBuf). This could fail if memory is fragmented since it results in high order allocations for commonly used server implementations. It is also wasteful since there are probably few locks in the usual case. Limit the buffer to be no larger than a page to avoid memory allocation failures due to fragmentation. Signed-off-by: Ross Lagerwall Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 90704aa91207c16fd44f0144b5b8f93e94ea695f Author: Ilia Mirkin Date: Thu Dec 13 22:44:08 2018 -0500 drm/nouveau/falcon: avoid touching registers if engine is off [ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit b81259d9bf437640f99cf9129f08d6146037a5b9 Author: Takashi Iwai Date: Wed Sep 12 12:58:43 2018 +0200 drm/nouveau: Don't disable polling in fallback mode [ Upstream commit 118780066e30c34de3d9349710b51780bfa0ba83 ] When a fan is controlled via linear fallback without cstate, we shouldn't stop polling. Otherwise it won't be adjusted again and keeps running at an initial crazy pace. Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan control is specified in the vbios") Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447 Reported-by: Thomas Blume Signed-off-by: Takashi Iwai Reviewed-by: Martin Peres Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 771e153fd2a8513033980659f6d872ce6bea5025 Author: Nicholas Mc Guire Date: Sat Dec 1 12:57:18 2018 +0100 gpio: pl061: handle failed allocations [ Upstream commit df209c43a0e8258e096fb722dfbdae4f0dd13fde ] devm_kzalloc(), devm_kstrdup() and devm_kasprintf() all can fail internal allocation and return NULL. Using any of the assigned objects without checking is not safe. As this is early in the boot phase and these allocations really should not fail, any failure here is probably an indication of a more serious issue so it makes little sense to try and rollback the previous allocated resources or try to continue; but rather the probe function is simply exited with -ENOMEM. Signed-off-by: Nicholas Mc Guire Fixes: 684284b64aae ("ARM: integrator: add MMCI device to IM-PD1") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e18ea11e82e00c44ea8e5f58836234555fa41b7c Author: Guo Ren Date: Thu Jan 10 20:28:39 2019 +0800 csky: fixup compile error with CPU 810. [ Upstream commit 70c25259537c073584eb906865307687275b527f ] This bug is from commit f553aa1c13cb ("csky: fixup relocation error with 807 & 860"). I forgot to compile with 810 for that patch. Signed-off-by: Guo Ren Cc: Arnd Bergmann Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 66500030d11242614d85c9805401c84a74ae357a Author: Linus Walleij Date: Tue Jan 8 00:08:18 2019 +0100 ARM: dts: kirkwood: Fix polarity of GPIO fan lines [ Upstream commit b5f034845e70916fd33e172fad5ad530a29c10ab ] These two lines are active high, not active low. The bug was found when we changed the kernel to respect the polarity defined in the device tree. Fixes: 1b90e06b1429 ("ARM: kirkwood: Use devicetree to define DNS-32[05] fan") Cc: Jamie Lentin Cc: Guenter Roeck Cc: Jason Cooper Cc: Andrew Lunn Cc: Gregory Clement Cc: Sebastian Hesselbarth Cc: Julien D'Ascenzio Reviewed-by: Andrew Lunn Tested-by: Jamie Lentin Reported-by: Julien D'Ascenzio Tested-by: Julien D'Ascenzio Signed-off-by: Linus Walleij Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 45ce4c5d958386e88ca5410d98f6042092ec0df7 Author: Peter Ujfalusi Date: Wed Dec 19 13:47:26 2018 +0200 ARM: dts: da850-lcdk: Correct the sound card name [ Upstream commit c25748acc5c20786ecb7518bfeae8fcef93472d6 ] To avoid the following error: asoc-simple-card sound: ASoC: Failed to create card debugfs directory Which is because the card name contains '/' character, which can not be used in file or directory names. Signed-off-by: Peter Ujfalusi Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin commit c1f3bde3395c356036781d4c1b6183eb9f4eb792 Author: Peter Ujfalusi Date: Wed Dec 19 13:47:25 2018 +0200 ARM: dts: da850-lcdk: Correct the audio codec regulators [ Upstream commit bd540ebe68c3017194a1caa38e075bbbc0832749 ] Add the board level fixed regulators for 3.3V and 1.8V which is used to power - among other things - the tlv320aic3106 codec. Apart from removing the following warning during boot: tlv320aic3x-codec 0-0018: Invalid supply voltage(s) AVDD: -22, DVDD: -22 With the correct voltages the driver can select correct OCMV value to reduce pop noise. Signed-off-by: Peter Ujfalusi Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin commit eebd24a76b4ac552e254a47124a91d4166f07935 Author: Peter Ujfalusi Date: Wed Dec 19 13:47:24 2018 +0200 ARM: dts: da850-evm: Correct the sound card name [ Upstream commit 7fca69d4e43fa1ae9cb4f652772c132dc5a659c6 ] To avoid the following error: asoc-simple-card sound: ASoC: Failed to create card debugfs directory Which is because the card name contains '/' character, which can not be used in file or directory names. Signed-off-by: Peter Ujfalusi Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin commit 5692bc9e0b582ea949b2bec059db92b04bbe8b7a Author: Peter Ujfalusi Date: Wed Dec 19 13:47:23 2018 +0200 ARM: dts: da850-evm: Correct the audio codec regulators [ Upstream commit 706edaa88835e3d8de8920584ad5da76dd3d6666 ] Add the board level fixed regulators for 3.3V and 1.8V which is used to power - among other things - the tlv320aic3106 codec. Apart from removing the following warning during boot: tlv320aic3x-codec 0-0018: Too high supply voltage(s) AVDD: 5000000, DVDD: 5000000 With the correct voltages the driver can select correct OCMV value to reduce pop noise. Signed-off-by: Peter Ujfalusi Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin commit 70bc65fecc6b0ca6886d29ef257add506a4f0694 Author: Christian König Date: Mon Jan 7 14:43:55 2019 +0100 drm/amdgpu: disable system memory page tables for now [ Upstream commit 1c1eba86339c8517814863bc7dd21e2661a84e77 ] We hit a problem with IOMMU with that. Disable until we have time to debug further. Signed-off-by: Christian König Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 34701cd7f91cb9ebfb207afb48bcac0e877cd2ac Author: Jim Qu Date: Mon Dec 17 17:00:50 2018 +0800 drm/amdgpu: set WRITE_BURST_LENGTH to 64B to workaround SDMA1 hang [ Upstream commit 0c6c8125582714e1fd3544983eba3d750db0f5b8 ] effect asics: VEGA10 and VEGA12 Signed-off-by: Jim Qu Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 03092a0e26c2b4f23f93482399dbf2eb39833e22 Author: Tao Zhou Date: Tue Jan 8 15:08:44 2019 +0800 drm/amdgpu: fix CPDMA hang in PRT mode for VEGA20 [ Upstream commit 3e958fe67720b37d04ab8ef81b9d507a56a09bbc ] Fix CPDMA hang in PRT mode for both VEGA10 and VEGA20 Signed-off-by: Tao Zhou Tested-by: Yukun.Li Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b9453f9bb66e864f8b7d7e112aea475bdd7a4e2b Author: James Dingwall Date: Tue Jan 8 10:20:51 2019 -0700 nvme: introduce NVME_QUIRK_IGNORE_DEV_SUBNQN [ Upstream commit 6299358d198a0635da2dd3c4b3ec37789e811e44 ] If a device provides an NQN it is expected to be globally unique. Unfortunately some firmware revisions for Intel 760p/Pro 7600p devices did not satisfy this requirement. In these circumstances if a system has >1 affected device then only one device is enabled. If this quirk is enabled then the device supplied subnqn is ignored and we fallback to generating one as if the field was empty. In this case we also suppress the version check so we don't print a warning when the quirk is enabled. Reviewed-by: Keith Busch Signed-off-by: James Dingwall Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit cedcbfdde6d5e7336abc4592ac00846f78a9127a Author: Keith Busch Date: Tue Jan 8 09:37:43 2019 -0700 nvme: pad fake subsys NQN vid and ssvid with zeros [ Upstream commit 3da584f57133e51aeb84aaefae5e3d69531a1e4f ] We need to preserve the leading zeros in the vid and ssvid when generating a unique NQN. Truncating these may lead to naming collisions. Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 846cdc1a0305a77154fed0a86cf21b9f4e7a6c74 Author: Hannes Reinecke Date: Tue Jan 8 12:46:58 2019 +0100 nvme-multipath: zero out ANA log buffer [ Upstream commit c7055fd15ff46d92eb0dd1c16a4fe010d58224c8 ] When nvme_init_identify() fails the ANA log buffer is deallocated but _not_ set to NULL. This can cause double free oops when this controller is deleted without ever being reconnected. Signed-off-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c4a6f6e7ef64e2cedfe6f4381c86b83f6687ec20 Author: Hongbo Yao Date: Mon Jan 7 10:22:07 2019 +0800 nvme-pci: fix out of bounds access in nvme_cqe_pending [ Upstream commit dcca1662727220d18fa351097ddff33f95f516c5 ] There is an out of bounds array access in nvme_cqe_peding(). When enable irq_thread for nvme interrupt, there is racing between the nvmeq->cq_head updating and reading. nvmeq->cq_head is updated in nvme_update_cq_head(), if nvmeq->cq_head equals nvmeq->q_depth and before its value set to zero, nvme_cqe_pending() uses its value as an array index, the index will be out of bounds. Signed-off-by: Hongbo Yao [hch: slight coding style update] Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e0b9c20716648530f1982314ffe0cb42d72b84fc Author: Liviu Dudau Date: Sat Dec 29 17:23:43 2018 +0000 nvme-pci: use the same attributes when freeing host_mem_desc_bufs. [ Upstream commit cc667f6d5de023ee131e96bb88e5cddca23272bd ] When using HMB the PCIe host driver allocates host_mem_desc_bufs using dma_alloc_attrs() but frees them using dma_free_coherent(). Use the correct dma_free_attrs() function to free the buffers. Signed-off-by: Liviu Dudau Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a86d2c87080343b565c1bca10010d05805616cd5 Author: Tomi Valkeinen Date: Thu Jan 3 13:59:53 2019 +0200 drm/bridge: tc358767: fix output H/V syncs [ Upstream commit 7923e09c7a766e2d58de7fc395bb84c18e5bc625 ] The H and V syncs of the DP output are always set to active high. This patch fixes the syncs by configuring them according to the videomode. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-7-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin commit b5e7155ec99377b62fd3b09cc0c185396ee47968 Author: Tomi Valkeinen Date: Thu Jan 3 13:59:52 2019 +0200 drm/bridge: tc358767: reject modes which require too much BW [ Upstream commit 51b9e62eb6950c762162ab7eb8390990179be067 ] The current driver accepts any videomode with pclk < 154MHz. This is not correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be supported. Add code to reject modes that require more bandwidth that is available. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-6-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin commit 57781d8b77cc3941da7e2f1e3d0d50349c0a328c Author: Tomi Valkeinen Date: Thu Jan 3 13:59:51 2019 +0200 drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value [ Upstream commit 9a63bd6fe1b5590ffa42ae2ed22ee21363293e31 ] Initially DP0_SRCCTRL is set to a static value which includes DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of 1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number. This patch changes the configuration as follows: Configure DP0_SRCCTRL by using tc_srcctrl() which provides the correct value. DP1_SRCCTRL needs two bits to be set to the same value as DP0_SRCCTRL: SSCG and BW27. All other bits can be zero. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-5-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin commit 6a8313d4205db2c5ab762259969d86a86d9ad6c5 Author: Tomi Valkeinen Date: Thu Jan 3 13:59:50 2019 +0200 drm/bridge: tc358767: fix single lane configuration [ Upstream commit 4d9d54a730434cc068dd3515ba6116697196f77b ] PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use. Set PHY_2LANE only when 2 lanes are used. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-4-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin commit f80008911228814cc3e8c3028070d2f078d21f04 Author: Tomi Valkeinen Date: Thu Jan 3 13:59:49 2019 +0200 drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE [ Upstream commit adf4109896bbee27fd2ac3b48d22d6a0062fe517 ] DP1_SRCCTRL register and PHY_2LANE field did not have matching defines. Add these. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-3-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin commit e1685cf9469ef8836563722979bccdf5601c0369 Author: Tomi Valkeinen Date: Thu Jan 3 13:59:48 2019 +0200 drm/bridge: tc358767: add bus flags [ Upstream commit 4842379cbe6e851de914a7132f76f4e200b9a98b ] tc358767 driver does not set DRM bus_flags, even if it does configures the polarity settings into its registers. This means that the DPI source can't configure the polarities correctly. Add sync flags accordingly. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-2-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin commit 2b1887057fd6610a55099ac9b595145f14252159 Author: Evan Quan Date: Tue Jan 8 10:33:35 2019 +0800 drm/amd/powerplay: avoid possible buffer overflow [ Upstream commit fff0d3f7686942bd544b53a48d1b76bd62c46946 ] Make sure the clock level enforced is within the allowed ranges. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Reviewed-by: Likun Gao Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dad4502dd23f106eecc881dee1f9a09111dac0cd Author: Guo Ren Date: Tue Jan 8 20:49:24 2019 +0800 irqchip/csky: fixup handle_irq_perbit break irq [ Upstream commit 56752b21755aef598709d143684cb363db98a7d2 ] The handle_irq_perbit function loop every bit in hwirq local variable. handle_irq_perbit(hwirq) { for_everyt_bit_in(hwirq) { handle_domain_irq() ->irq_exit() ->invoke_softirq() ->__do_softirq() ->local_irq_enable() // Here will cause new interrupt. } } When new interrupt coming at local_irq_enable, it will finish another interrupt handler and pull down the interrupt source. But hwirq is the local variable for handle_irq_perbit(), it can't get new interrupt controller pending reg status. So we need update hwirq with pending reg in every loop. Also change write_relax to writel could prevent stw from fast retire. When local_irq is enabled, intc regs is really set-in. Signed-off-by: Guo Ren Cc: Lu Baoquan Signed-off-by: Sasha Levin commit e4a8a44034ee4cb1cf1165601ede1e345b1618cc Author: Guo Ren Date: Tue Jan 8 20:17:49 2019 +0800 csky: fixup CACHEV1 store instruction fast retire [ Upstream commit 96354ad79e2e59f9d620669c8e1ac2452440c260 ] For I/O access, 810/807 store instruction fast retire will cause wrong primitive. For example: stw (clear interrupt source) stw (unmask interrupt controller) enable interrupt stw is fast retire instruction. When PC is run at enable interrupt stage, the clear interrupt source hasn't finished. It will cause another wrong irq-enter. So use mb() to prevent above. Signed-off-by: Guo Ren Cc: Lu Baoquan Signed-off-by: Sasha Levin commit 66535eab9d5705acd2accc572b0da9c0e14d3b61 Author: Guo Ren Date: Tue Jan 8 19:52:22 2019 +0800 csky: fixup relocation error with 807 & 860 [ Upstream commit f553aa1c13cbc29aaf420349a28fc33ca98440e5 ] 810 doesn't support jsri instruction and csky-as will leave jsri + nop for relocation. Module-probe need replace them with lrw + jsr. Signed-off-by: Guo Ren Cc: Hui Kai Signed-off-by: Sasha Levin commit cafd389b81df7b4d0c94c33ecdaba7d80cd1d275 Author: Sudeep Holla Date: Mon Jan 7 18:51:53 2019 +0000 cpufreq: check if policy is inactive early in __cpufreq_get() [ Upstream commit 2f66196208c98b3d1b4294edffb2c5a8197be899 ] cpuinfo_cur_freq gets current CPU frequency as detected by hardware while scaling_cur_freq last known CPU frequency. Some platforms may not allow checking the CPU frequency of an offline CPU or the associated resources may have been released via cpufreq_exit when the CPU gets offlined, in which case the policy would have been invalidated already. If we attempt to get current frequency from the hardware, it may result in hang or crash. For example on Juno, I see: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000188 [0000000000000188] pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 5 PID: 4202 Comm: cat Not tainted 4.20.0-08251-ga0f2c0318a15-dirty #87 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform pstate: 40000005 (nZcv daif -PAN -UAO) pc : scmi_cpufreq_get_rate+0x34/0xb0 lr : scmi_cpufreq_get_rate+0x34/0xb0 Call trace: scmi_cpufreq_get_rate+0x34/0xb0 __cpufreq_get+0x34/0xc0 show_cpuinfo_cur_freq+0x24/0x78 show+0x40/0x60 sysfs_kf_seq_show+0xc0/0x148 kernfs_seq_show+0x44/0x50 seq_read+0xd4/0x480 kernfs_fop_read+0x15c/0x208 __vfs_read+0x60/0x188 vfs_read+0x94/0x150 ksys_read+0x6c/0xd8 __arm64_sys_read+0x24/0x30 el0_svc_common+0x78/0x100 el0_svc_handler+0x38/0x78 el0_svc+0x8/0xc ---[ end trace 3d1024e58f77f6b2 ]--- So fix the issue by checking if the policy is invalid early in __cpufreq_get before attempting to get the current frequency. Signed-off-by: Sudeep Holla Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4830f352e9157ad0d4e4bf8b5ecd41db05f2bc3c Author: David Abdurachmanov Date: Thu Dec 6 16:26:34 2018 +0100 riscv: fix trace_sys_exit hook [ Upstream commit 775800b0f1d7303d4fd8ce0e0d9eca4ff2f338f2 ] Fix compilation error. Signed-off-by: David Abdurachmanov Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 7e710bfd7530fa5780854062824e0602f9659e82 Author: Aurelien Jarno Date: Tue Dec 25 15:46:24 2018 +0100 tools uapi: fix RISC-V 64-bit support [ Upstream commit d0df00e30e4bf9bc27ddbd092ad683ff6121b360 ] The BPF library is not built on 64-bit RISC-V, as the BPF feature is not detected. Looking more in details, feature/test-bpf.c fails to build with the following error: | In file included from /tmp/linux-4.19.12/tools/include/uapi/asm/bitsperlong.h:17, | from /tmp/linux-4.19.12/tools/include/uapi/asm-generic/unistd.h:2, | from /usr/include/riscv64-linux-gnu/asm/unistd.h:1, | from test-bpf.c:2: | /tmp/linux-4.19.12/tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h | #error Inconsistent word size. Check asm/bitsperlong.h | ^~~~~ The UAPI from the tools directory is missing RISC-V support, therefore bitsperlong.h from asm-generic is used, defaulting to 32 bits. Fix that by adding tools/arch/riscv/include/uapi/asm/bitsperlong.h as a copy of arch/riscv/include/uapi/asm/bitsperlong.h and by updating tools/include/uapi/asm/bitsperlong.h. Signed-off-by: Aurelien Jarno Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit b11683186ec19f38f8c1ca2fa46c0c73eddf3d06 Author: Biju Das Date: Wed Dec 12 12:17:11 2018 +0000 soc: renesas: r8a774c0-sysc: Fix initialization order of 3DG-{A,B} [ Upstream commit a64597227d0de5610407fcc95dc835745a53f5d0 ] The workaround for the wrong hierarchy of the 3DG-{A,B} power domains on RZ/G2E ES1.0 corrected the parent domains. However, the 3DG-{A,B} power domains were still initialized and powered in the wrong order, causing 3DG operation to fail. Fix this by changing the order in the table at runtime, when running on an affected SoC. This work is based on the work done by Geert for R-Car E3. Fixes: f37d211c687588328 ("soc: renesas: rcar-sysc: Add r8a774c0 support") Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Signed-off-by: Simon Horman Signed-off-by: Sasha Levin commit 87d4f6ac96ce7debc714eddd5d2c847c6b781415 Author: Arnaldo Carvalho de Melo Date: Fri Jan 4 15:10:00 2019 -0300 perf test shell: Use a fallback to get the pathname in vfs_getname [ Upstream commit 03fa483821c0b4db7c2b1453d3332f397d82313f ] Some kernels, like 4.19.13-300.fc29.x86_64 in fedora 29, fail with the existing probe definition asking for the contents of result->name, working when we ask for the 'filename' variable instead, so add a fallback to that. Now those tests are back working on fedora 29 systems with that kernel: # perf test vfs_getname 65: Use vfs_getname probe to get syscall args filenames : Ok 66: Add vfs_getname probe to get syscall args filenames : Ok 67: Check open filename arg using perf trace + vfs_getname: Ok # Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-klt3n0i58dfqttveti09q3fi@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 394fc1c6bde5ecb0868bb50fd3df6186541f6981 Author: Jin Yao Date: Fri Jan 4 14:10:30 2019 +0800 perf report: Fix wrong iteration count in --branch-history [ Upstream commit a3366db06bb656cef2e03f30f780d93059bcc594 ] By calculating the removed loops, we can get the iteration count. But the iteration count could be reported incorrectly, reporting impossibly high counts. That's because previous code uses the number of removed LBR entries for the iteration count. That's not good. Fix this by increasing the iteration count when a loop is detected. When matching the chain, the iteration count would be added up, finally we need to compute the average value when printing out. For example, $ perf report --branch-history --stdio --no-children Before: ---f2 +0 | |--33.62%--f1 +9 (cycles:1) | f1 +0 | main +22 (cycles:1) | main +17 | main +38 (cycles:1) | main +27 | f1 +26 (cycles:1) | f1 +24 | f2 +27 (cycles:7) | f2 +0 | f1 +19 (cycles:1) | f1 +14 | f2 +27 (cycles:11) | f2 +0 | f1 +9 (cycles:1 iter:2968 avg_cycles:3) | f1 +0 | main +22 (cycles:1 iter:2968 avg_cycles:3) | main +17 | main +38 (cycles:1 iter:2968 avg_cycles:3) 2968 is an impossible high iteration count and avg_cycles is too small. After: ---f2 +0 | |--33.62%--f1 +9 (cycles:1) | f1 +0 | main +22 (cycles:1) | main +17 | main +38 (cycles:1) | main +27 | f1 +26 (cycles:1) | f1 +24 | f2 +27 (cycles:7) | f2 +0 | f1 +19 (cycles:1) | f1 +14 | f2 +27 (cycles:11) | f2 +0 | f1 +9 (cycles:1 iter:1 avg_cycles:23) | f1 +0 | main +22 (cycles:1 iter:1 avg_cycles:23) | main +17 | main +38 (cycles:1 iter:1 avg_cycles:23) avg_cycles:23 is the average cycles of this iteration. Fixes: c4ee06251d42 ("perf report: Calculate the average cycles of iterations") Signed-off-by: Jin Yao Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1546582230-17507-1-git-send-email-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 3902b972ee890d52d07730410c568d46b7958b7d Author: Jin Yao Date: Thu Jan 3 15:40:45 2019 +0800 perf stat: Fix endless wait for child process [ Upstream commit 8a99255a50c0b4c2a449b96fd8d45fcc8d72c701 ] We hit a 'perf stat' issue by using following script: #!/bin/bash sleep 1000 & exec perf stat -a -e cycles -I1000 -- sleep 5 Since "perf stat" is launched by exec, the "sleep 1000" would be the child process of "perf stat". The wait4() call will not return because it's waiting for the child process "sleep 1000" to end. So 'perf stat' doesn't return even after 5s passes. This patch lets 'perf stat' return when the specified child process ends (in this case, the specified child process is "sleep 5"). Committer testing: # cat test.sh #!/bin/bash sleep 10 & exec perf stat -a -e cycles -I1000 -- sleep 5 # Before: # time ./test.sh # time counts unit events 1.001113090 108,453,351 cycles 2.002062196 142,075,435 cycles 3.002896194 164,801,068 cycles 4.003731666 107,062,140 cycles 5.002068867 112,241,832 cycles real 0m10.066s user 0m0.016s sys 0m0.101s # After: # time ./test.sh # time counts unit events 1.001016096 91,412,027 cycles 2.002014963 124,063,708 cycles 3.002883964 125,993,929 cycles 4.003706470 120,465,734 cycles 5.002006778 163,560,355 cycles real 0m5.123s user 0m0.014s sys 0m0.105s # Signed-off-by: Jin Yao Reviewed-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Andi Kleen Cc: Kan Liang Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1546501245-4512-1-git-send-email-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 82f61afa5b934898c9afca86dd4a4fcabec4aca5 Author: Chao Fan Date: Wed Dec 26 11:34:50 2018 +0800 ACPI: NUMA: Use correct type for printing addresses on i386-PAE [ Upstream commit b9ced18acf68dffebe6888c7ec765a2b1db7a039 ] The addresses of NUMA nodes are not printed correctly on i386-PAE which is misleading. Here is a debian9-32bit with PAE in a QEMU guest having more than 4G of memory: qemu-system-i386 \ -hda /var/lib/libvirt/images/debian32.qcow2 \ -m 5G \ -enable-kvm \ -smp 10 \ -numa node,mem=512M,nodeid=0,cpus=0 \ -numa node,mem=512M,nodeid=1,cpus=1 \ -numa node,mem=512M,nodeid=2,cpus=2 \ -numa node,mem=512M,nodeid=3,cpus=3 \ -numa node,mem=512M,nodeid=4,cpus=4 \ -numa node,mem=512M,nodeid=5,cpus=5 \ -numa node,mem=512M,nodeid=6,cpus=6 \ -numa node,mem=512M,nodeid=7,cpus=7 \ -numa node,mem=512M,nodeid=8,cpus=8 \ -numa node,mem=512M,nodeid=9,cpus=9 \ -serial stdio Because of the wrong value type, it prints as below: [ 0.021049] ACPI: SRAT Memory (0x0 length 0xa0000) in proximity domain 0 enabled [ 0.021740] ACPI: SRAT Memory (0x100000 length 0x1ff00000) in proximity domain 0 enabled [ 0.022425] ACPI: SRAT Memory (0x20000000 length 0x20000000) in proximity domain 1 enabled [ 0.023092] ACPI: SRAT Memory (0x40000000 length 0x20000000) in proximity domain 2 enabled [ 0.023764] ACPI: SRAT Memory (0x60000000 length 0x20000000) in proximity domain 3 enabled [ 0.024431] ACPI: SRAT Memory (0x80000000 length 0x20000000) in proximity domain 4 enabled [ 0.025104] ACPI: SRAT Memory (0xa0000000 length 0x20000000) in proximity domain 5 enabled [ 0.025791] ACPI: SRAT Memory (0x0 length 0x20000000) in proximity domain 6 enabled [ 0.026412] ACPI: SRAT Memory (0x20000000 length 0x20000000) in proximity domain 7 enabled [ 0.027118] ACPI: SRAT Memory (0x40000000 length 0x20000000) in proximity domain 8 enabled [ 0.027802] ACPI: SRAT Memory (0x60000000 length 0x20000000) in proximity domain 9 enabled The upper half of the start address of the NUMA domains between 6 and 9 inclusive was cut, so the printed values are incorrect. Fix the value type, to get the correct values in the log as follows: [ 0.023698] ACPI: SRAT Memory (0x0 length 0xa0000) in proximity domain 0 enabled [ 0.024325] ACPI: SRAT Memory (0x100000 length 0x1ff00000) in proximity domain 0 enabled [ 0.024981] ACPI: SRAT Memory (0x20000000 length 0x20000000) in proximity domain 1 enabled [ 0.025659] ACPI: SRAT Memory (0x40000000 length 0x20000000) in proximity domain 2 enabled [ 0.026317] ACPI: SRAT Memory (0x60000000 length 0x20000000) in proximity domain 3 enabled [ 0.026980] ACPI: SRAT Memory (0x80000000 length 0x20000000) in proximity domain 4 enabled [ 0.027635] ACPI: SRAT Memory (0xa0000000 length 0x20000000) in proximity domain 5 enabled [ 0.028311] ACPI: SRAT Memory (0x100000000 length 0x20000000) in proximity domain 6 enabled [ 0.028985] ACPI: SRAT Memory (0x120000000 length 0x20000000) in proximity domain 7 enabled [ 0.029667] ACPI: SRAT Memory (0x140000000 length 0x20000000) in proximity domain 8 enabled [ 0.030334] ACPI: SRAT Memory (0x160000000 length 0x20000000) in proximity domain 9 enabled Signed-off-by: Chao Fan [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 75189d2870adb9ee1f3bec70d7cda23e423c8e8b Author: Emily Deng Date: Sat Dec 29 17:46:05 2018 +0800 drm/amdgpu/sriov:Correct pfvf exchange logic [ Upstream commit b8cf66182eddb22e9c7539821ed6eecdb4f86d1a ] The pfvf exchange need be in exclusive mode. And add pfvf exchange in gpu reset. Signed-off-by: Emily Deng Reviewed-By: Xiangliang Yu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 74712cec904c7dffc7c31dcd12d8da5f5ca01a0b Author: Jianchao Wang Date: Wed Jan 30 17:01:56 2019 +0800 blk-mq: fix a hung issue when fsync [ Upstream commit 85bd6e61f34dffa8ec2dc75ff3c02ee7b2f1cbce ] Florian reported a io hung issue when fsync(). It should be triggered by following race condition. data + post flush a flush blk_flush_complete_seq case REQ_FSEQ_DATA blk_flush_queue_rq issued to driver blk_mq_dispatch_rq_list try to issue a flush req failed due to NON-NCQ command .queue_rq return BLK_STS_DEV_RESOURCE request completion req->end_io // doesn't check RESTART mq_flush_data_end_io case REQ_FSEQ_POSTFLUSH blk_kick_flush do nothing because previous flush has not been completed blk_mq_run_hw_queue insert rq to hctx->dispatch due to RESTART is still set, do nothing To fix this, replace the blk_mq_run_hw_queue in mq_flush_data_end_io with blk_mq_sched_restart to check and clear the RESTART flag. Fixes: bd166ef1 (blk-mq-sched: add framework for MQ capable IO schedulers) Reported-by: Florian Stecker Tested-by: Florian Stecker Signed-off-by: Jianchao Wang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f93db166770224a85e8dd68b9c77854413665a94 Author: Adrian Bunk Date: Thu Nov 29 21:58:58 2018 +0200 eeprom: at24: add support for 24c2048 [ Upstream commit 37cf28d3b5bca1b532a0b6aac722e7f2788a9294 ] Works with ST M24M02. Signed-off-by: Adrian Bunk Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 815dbc22fcae41bc62bf22b9c8ee211b57231538 Author: Adrian Bunk Date: Thu Nov 29 21:58:57 2018 +0200 dt-bindings: eeprom: at24: add "atmel,24c2048" compatible string [ Upstream commit 6c0c5dc33ff42af49243e94842d0ebdb153189ea ] Add new compatible to the device tree bindings. Signed-off-by: Adrian Bunk Acked-by: Rob Herring Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin