commit 2a5f80c5bd72487ddf35638c078c6a753894db87 Author: Greg Kroah-Hartman Date: Wed Dec 19 19:19:54 2018 +0100 Linux 4.19.11 commit d92c66b30f9368e83aa85b30cc921e23ca0b28b4 Author: Masahiro Yamada Date: Wed Dec 5 15:27:19 2018 +0900 x86/build: Fix compiler support check for CONFIG_RETPOLINE commit 25896d073d8a0403b07e6dec56f58e6c33678207 upstream. It is troublesome to add a diagnostic like this to the Makefile parse stage because the top-level Makefile could be parsed with a stale include/config/auto.conf. Once you are hit by the error about non-retpoline compiler, the compilation still breaks even after disabling CONFIG_RETPOLINE. The easiest fix is to move this check to the "archprepare" like this commit did: 829fe4aa9ac1 ("x86: Allow generating user-space headers without a compiler") Reported-by: Meelis Roos Tested-by: Meelis Roos Signed-off-by: Masahiro Yamada Acked-by: Zhenzhong Duan Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Zhenzhong Duan Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support") Link: http://lkml.kernel.org/r/1543991239-18476-1-git-send-email-yamada.masahiro@socionext.com Link: https://lkml.org/lkml/2018/12/4/206 Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Cc: Gi-Oh Kim Signed-off-by: Greg Kroah-Hartman commit 228f6f28d478215120a0ae23cdf4cda83eeddba8 Author: Damien Le Moal Date: Fri Nov 30 15:31:48 2018 +0900 dm zoned: Fix target BIO completion handling commit d57f9da890696af1484f4a47f7f123560197865a upstream. struct bioctx includes the ref refcount_t to track the number of I/O fragments used to process a target BIO as well as ensure that the zone of the BIO is kept in the active state throughout the lifetime of the BIO. However, since decrementing of this reference count is done in the target .end_io method, the function bio_endio() must be called multiple times for read and write target BIOs, which causes problems with the value of the __bi_remaining struct bio field for chained BIOs (e.g. the clone BIO passed by dm core is large and splits into fragments by the block layer), resulting in incorrect values and inconsistencies with the BIO_CHAIN flag setting. This is turn triggers the BUG_ON() call: BUG_ON(atomic_read(&bio->__bi_remaining) <= 0); in bio_remaining_done() called from bio_endio(). Fix this ensuring that bio_endio() is called only once for any target BIO by always using internal clone BIOs for processing any read or write target BIO. This allows reference counting using the target BIO context counter to trigger the target BIO completion bio_endio() call once all data, metadata and other zone work triggered by the BIO complete. Overall, this simplifies the code too as the target .end_io becomes unnecessary and differences between read and write BIO issuing and completion processing disappear. Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 7b942bad38183fe7453dc7f04fe1eea0af257fda Author: Junwei Zhang Date: Fri Dec 7 15:15:03 2018 +0800 drm/amdgpu: update SMC firmware image for polaris10 variants commit d55d8be0747c96db28a1d08fc24d22ccd9b448ac upstream. Some new variants require different firmwares. Signed-off-by: Junwei Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3ae86cfbbbf64a06ee20bface750eb7e1a23e58e Author: Alex Deucher Date: Wed Oct 17 11:24:26 2018 -0500 drm/amdgpu: update smu firmware images for VI variants (v2) commit 153573d8870e1c173721bdc1ced72b3ad0d85de4 upstream. Some new variants require updated firmware. V2: add MODULE_FIRMWARE for new firmwares Reviewed-by: Huang Rui (v1) Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2732df872c635e3803ef7d41aee59fc024599154 Author: Alex Deucher Date: Fri Dec 7 15:58:23 2018 -0500 drm/amdgpu: add some additional vega10 pci ids commit 2244b5887c6865b9e9cf14ee12a312b776aeeb58 upstream. New vega ids. Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 95baf54676a81f01f863fb7694a12bf928f34174 Author: Alex Deucher Date: Fri Dec 7 16:23:19 2018 -0500 drm/amdkfd: add new vega10 pci ids commit 756e16bf79f2815e7c83a04881b5545b55a99fd3 upstream. New vega10 ids. Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d68d2ad5447482a09933e9206ab94c75ee99daf8 Author: Kenneth Feng Date: Thu Dec 6 11:56:14 2018 +0800 drm/amdgpu/powerplay: Apply avfs cks-off voltages on VI commit cf4197ed5796234a53beb71228198c7d1e678947 upstream. Instead of EVV cks-off voltages, avfs cks-off voltages can avoid the overshoot voltages when switching sclk. Signed-off-by: Kenneth Feng Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f0e9995f7eed78c699bc7ea87af8bc9ab4da6e6c Author: Chris Wilson Date: Thu Dec 6 08:44:31 2018 +0000 drm/i915/execlists: Apply a full mb before execution for Braswell commit cf66b8a0ba142fbd1bf10ac8f3ae92d1b0cb7b8f upstream. Braswell is really picky about having our writes posted to memory before we execute or else the GPU may see stale values. A wmb() is insufficient as it only ensures the writes are visible to other cores, we need a full mb() to ensure the writes are in memory and visible to the GPU. The most frequent failure in flushing before execution is that we see stale PTE values and execute the wrong pages. References: 987abd5c62f9 ("drm/i915/execlists: Force write serialisation into context image vs execution") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20181206084431.9805-3-chris@chris-wilson.co.uk (cherry picked from commit 490b8c65b9db45896769e1095e78725775f47b3e) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit d6ebe485da3d9ac4cd5456066f23caf004dc2f52 Author: Tina Zhang Date: Mon Dec 3 16:29:23 2018 +0800 drm/i915/gvt: Fix tiled memory decoding bug on BDW commit a40fa231bb64b33e2cd54cf8ef44a9f89875fa11 upstream. Commit b244ffa15c8b ("drm/i915/gvt: Fix drm_format_mod value for vGPU plane") introduced a regression issue to the tiled memory decoding on BDW. This patch can fix this issue. Here is the issue detail: https://github.com/intel/gvt-linux/issues/61 v1->v2: - Refine the commit message. (Zhenyu) Fixes: b244ffa15c8b("drm/i915/gvt: Fix drm_format_mod value for vGPU plane") Signed-off-by: Tina Zhang Cc: stable@vger.kernel.org # v4.19+ Cc: Zhenyu Wang Signed-off-by: Zhenyu Wang Signed-off-by: Greg Kroah-Hartman commit 683ef526234f0c228530e58dea699758b6346149 Author: Brian Norris Date: Wed Dec 5 10:16:57 2018 -0800 Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec" commit 63238173b2faf3d6b85a416f1c69af6c7be2413f upstream. This reverts commit 7f3ef5dedb146e3d5063b6845781ad1bb59b92b5. It causes new warnings [1] on shutdown when running the Google Kevin or Scarlet (RK3399) boards under Chrome OS. Presumably our usage of DRM is different than what Marc and Heiko test. We're looking at a different approach (e.g., [2]) to replace this, but IMO the revert should be taken first, as it already propagated to -stable. [1] Report here: http://lkml.kernel.org/lkml/20181205030127.GA200921@google.com WARNING: CPU: 4 PID: 2035 at drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x1c4/0x294 ... Call trace: drm_mode_config_cleanup+0x1c4/0x294 rockchip_drm_unbind+0x4c/0x8c component_master_del+0x88/0xb8 rockchip_drm_platform_remove+0x2c/0x44 rockchip_drm_platform_shutdown+0x20/0x2c platform_drv_shutdown+0x2c/0x38 device_shutdown+0x164/0x1b8 kernel_restart_prepare+0x40/0x48 kernel_restart+0x20/0x68 ... Memory manager not clean during takedown. WARNING: CPU: 4 PID: 2035 at drivers/gpu/drm/drm_mm.c:950 drm_mm_takedown+0x34/0x44 ... drm_mm_takedown+0x34/0x44 rockchip_drm_unbind+0x64/0x8c component_master_del+0x88/0xb8 rockchip_drm_platform_remove+0x2c/0x44 rockchip_drm_platform_shutdown+0x20/0x2c platform_drv_shutdown+0x2c/0x38 device_shutdown+0x164/0x1b8 kernel_restart_prepare+0x40/0x48 kernel_restart+0x20/0x68 ... [2] https://patchwork.kernel.org/patch/10556151/ https://www.spinics.net/lists/linux-rockchip/msg21342.html [PATCH] drm/rockchip: shutdown drm subsystem on shutdown Fixes: 7f3ef5dedb14 ("drm/rockchip: Allow driver to be shutdown on reboot/kexec") Cc: Jeffy Chen Cc: Robin Murphy Cc: Vicente Bergas Cc: Marc Zyngier Cc: Heiko Stuebner Cc: stable@vger.kernel.org Signed-off-by: Brian Norris Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20181205181657.177703-1-briannorris@chromium.org Signed-off-by: Greg Kroah-Hartman commit 4d5907f70ec1b3fb7295e4cab930a649854446ba Author: Ben Skeggs Date: Wed Dec 12 16:51:17 2018 +1000 drm/nouveau/kms/nv50-: also flush fb writes when rewinding push buffer commit 970a5ee41c72df46e3b0f307528c7d8ef7734a2e upstream. Should hopefully fix a regression some people have been seeing since EVO push buffers were moved to VRAM by default on Pascal GPUs. Fixes: d00ddd9da ("drm/nouveau/kms/nv50-: allocate push buffers in vidmem on pascal") Signed-off-by: Ben Skeggs Cc: # 4.19+ Signed-off-by: Greg Kroah-Hartman commit d7fde95b7f3f3d695bca2fea03fea1fd5638d96b Author: Lyude Paul Date: Tue Dec 11 18:56:20 2018 -0500 drm/nouveau/kms: Fix memory leak in nv50_mstm_del() commit 24199c5436f267399afed0c4f1f57663c0408f57 upstream. Noticed this while working on redoing the reference counting scheme in the DP MST helpers. Nouveau doesn't attempt to call drm_dp_mst_topology_mgr_destroy() at all, which leaves it leaking all of the resources for drm_dp_mst_topology_mgr and it's children mstbs+ports. Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Signed-off-by: Lyude Paul Cc: # v4.10+ Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit c97c353e5f298be520c0154fd06fb36c7223dfd1 Author: Benjamin Herrenschmidt Date: Fri Nov 30 14:54:09 2018 +1100 powerpc: Look for "stdout-path" when setting up legacy consoles commit bf3d6afbb234156749b640b6c50f714967a85964 upstream. Commit 78e5dfea84dc ("powerpc: dts: replace 'linux,stdout-path' with 'stdout-path'") broke the default console on a number of embedded PowerPC systems, because it failed to also update the code in arch/powerpc/kernel/legacy_serial.c to look for that property in addition to the old one. This fixes it. Fixes: 78e5dfea84dc ("powerpc: dts: replace 'linux,stdout-path' with 'stdout-path'") Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Rob Herring Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 73732de1579f535a7d8a9dd77a0e2b56ca6d11b4 Author: Radu Rendec Date: Tue Nov 27 22:20:48 2018 -0500 powerpc/msi: Fix NULL pointer access in teardown code commit 78e7b15e17ac175e7eed9e21c6f92d03d3b0a6fa upstream. The arch_teardown_msi_irqs() function assumes that controller ops pointers were already checked in arch_setup_msi_irqs(), but this assumption is wrong: arch_teardown_msi_irqs() can be called even when arch_setup_msi_irqs() returns an error (-ENOSYS). This can happen in the following scenario: - msi_capability_init() calls pci_msi_setup_msi_irqs() - pci_msi_setup_msi_irqs() returns -ENOSYS - msi_capability_init() notices the error and calls free_msi_irqs() - free_msi_irqs() calls pci_msi_teardown_msi_irqs() This is easier to see when CONFIG_PCI_MSI_IRQ_DOMAIN is not set and pci_msi_setup_msi_irqs() and pci_msi_teardown_msi_irqs() are just aliases to arch_setup_msi_irqs() and arch_teardown_msi_irqs(). The call to free_msi_irqs() upon pci_msi_setup_msi_irqs() failure seems legit, as it does additional cleanup; e.g. list_del(&entry->list) and kfree(entry) inside free_msi_irqs() do happen (MSI descriptors are allocated before pci_msi_setup_msi_irqs() is called and need to be cleaned up if that fails). Fixes: 6b2fd7efeb88 ("PCI/MSI/PPC: Remove arch_msi_check_device()") Cc: stable@vger.kernel.org # v3.18+ Signed-off-by: Radu Rendec Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 13e318b8680ea1df97ab121bc9bd29e9bd484e60 Author: Hans Verkuil Date: Wed Nov 28 03:37:43 2018 -0500 media: vb2: don't call __vb2_queue_cancel if vb2_start_streaming failed commit 04990215dec43c424daff00d1f622167b8aafd1f upstream. vb2_start_streaming() already rolls back the buffers, so there is no need to call __vb2_queue_cancel(). Especially since __vb2_queue_cancel() does too much, such as zeroing the q->queued_count value, causing vb2 to think that no buffers have been queued. It appears that this call to __vb2_queue_cancel() is a left-over from before commit b3379c6201bb3. Fixes: b3379c6201bb3 ('vb2: only call start_streaming if sufficient buffers are queued') Signed-off-by: Hans Verkuil Cc: # for v4.16 and up Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ee310e8ebb9eb53ff3294f36f72554e7c1d7ae54 Author: Steven Rostedt (VMware) Date: Mon Dec 10 23:58:01 2018 -0500 tracing: Fix memory leak of instance function hash filters commit 2840f84f74035e5a535959d5f17269c69fa6edc5 upstream. The following commands will cause a memory leak: # cd /sys/kernel/tracing # mkdir instances/foo # echo schedule > instance/foo/set_ftrace_filter # rmdir instances/foo The reason is that the hashes that hold the filters to set_ftrace_filter and set_ftrace_notrace are not freed if they contain any data on the instance and the instance is removed. Found by kmemleak detector. Cc: stable@vger.kernel.org Fixes: 591dffdade9f ("ftrace: Allow for function tracing instance to filter functions") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 8f01f990b19fdd143f2fe0b6fdc285b148a14f4f Author: Steven Rostedt (VMware) Date: Sun Dec 9 21:17:30 2018 -0500 tracing: Fix memory leak in set_trigger_filter() commit 3cec638b3d793b7cacdec5b8072364b41caeb0e1 upstream. When create_event_filter() fails in set_trigger_filter(), the filter may still be allocated and needs to be freed. The caller expects the data->filter to be updated with the new filter, even if the new filter failed (we could add an error message by setting set_str parameter of create_event_filter(), but that's another update). But because the error would just exit, filter was left hanging and nothing could free it. Found by kmemleak detector. Cc: stable@vger.kernel.org Fixes: bac5fb97a173a ("tracing: Add and use generic set_trigger_filter() implementation") Reviewed-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 470cc678a12b58b449433d706703e417e8aa4921 Author: Steven Rostedt (VMware) Date: Sat Dec 8 21:10:04 2018 -0500 tracing: Fix memory leak in create_filter() commit b61c19209c2c35ea2a2fe502d484703686eba98c upstream. The create_filter() calls create_filter_start() which allocates a "parse_error" descriptor, but fails to call create_filter_finish() that frees it. The op_stack and inverts in predicate_parse() were also not freed. Found by kmemleak detector. Cc: stable@vger.kernel.org Fixes: 80765597bc587 ("tracing: Rewrite filter logic to be simpler and faster") Reviewed-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit b543b5c0ac1c78c81f1ab3270d9464f6f45fd09e Author: Mike Snitzer Date: Mon Dec 3 16:47:21 2018 -0500 dm: call blk_queue_split() to impose device limits on bios commit 89f5fa47476eda56402e29fff3c5097f5c2a1e19 upstream. Otherwise the incoming bios, of various types, won't be shaped based on the DM device's advertised limits. Depends-on: af67c31fba ("blk: remove bio_set arg from blk_queue_split()") Fixes: 744889b7cb ("block: don't deal with discard limit in blkdev_issue_discard()") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 09bc666fb4112d0e4482fdf0abcd7352601a159c Author: Mike Snitzer Date: Fri Nov 9 11:56:03 2018 -0500 dm cache metadata: verify cache has blocks in blocks_are_clean_separate_dirty() commit 687cf4412a343a63928a5c9d91bdc0f522939d43 upstream. Otherwise dm_bitset_cursor_begin() return -ENODATA. Other calls to dm_bitset_cursor_begin() have similar negative checks. Fixes inability to create a cache in passthrough mode (even though doing so makes no sense). Fixes: 0d963b6e65 ("dm cache metadata: fix metadata2 format's blocks_are_clean_separate_dirty") Cc: stable@vger.kernel.org Reported-by: David Teigland Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 809c692c665d5f4acc20583329b32b8112b30ec9 Author: Mike Snitzer Date: Tue Dec 11 13:31:40 2018 -0500 dm thin: send event about thin-pool state change _after_ making it commit f6c367585d0d851349d3a9e607c43e5bea993fa1 upstream. Sending a DM event before a thin-pool state change is about to happen is a bug. It wasn't realized until it became clear that userspace response to the event raced with the actual state change that the event was meant to notify about. Fix this by first updating internal thin-pool state to reflect what the DM event is being issued about. This fixes a long-standing racey/buggy userspace device-mapper-test-suite 'resize_io' test that would get an event but not find the state it was looking for -- so it would just go on to hang because no other events caused the test to reevaluate the thin-pool's state. Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit bea8a160c621d19f7f78b13e14e03f4b8e44cd4b Author: Stefan Wahren Date: Mon Dec 3 19:37:08 2018 +0100 ARM: dts: bcm2837: Fix polarity of wifi reset GPIOs commit e25b6783c7b1bb79103d4617336879423f86b05e upstream. The commit b1b8f45b3130 ("ARM: dts: bcm2837: Add missing GPIOs of Expander") introduced a wifi power sequence. Unfortunately the polarity of the reset GPIOs were wrong and broke the wifi support on Raspberry Pi 3 B and later in 3 B+. This wasn't discovered before since the power sequence takes only effect in case the relevant MMC driver is compiled as a module. Fixes: b1b8f45b3130 ("ARM: dts: bcm2837: Add missing GPIOs of Expander") Cc: stable@vger.kernel.org Reported-by: Matthias Lueschner Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911443 Signed-off-by: Stefan Wahren Reviewed-by: Eric Anholt Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 0017698d34b08d221a02dbb92d57f9d654b929ae Author: Lubomir Rintel Date: Sun Dec 2 12:12:24 2018 +0100 ARM: mmp/mmp2: fix cpu_is_mmp2() on mmp2-dt commit 76f4e2c3b6a560cdd7a75b87df543e04d05a9e5f upstream. cpu_is_mmp2() was equivalent to cpu_is_pj4(), wouldn't be correct for multiplatform kernels. Fix it by also considering mmp_chip_id, as is done for cpu_is_pxa168() and cpu_is_pxa910() above. Moreover, it is only available with CONFIG_CPU_MMP2 and thus doesn't work on DT-based MMP2 machines. Enable it on CONFIG_MACH_MMP2_DT too. Note: CONFIG_CPU_MMP2 is only used for machines that use board files instead of DT. It should perhaps be renamed. I'm not doing it now, because I don't have a better idea. Signed-off-by: Lubomir Rintel Acked-by: Arnd Bergmann Cc: stable@vger.kernel.org Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit d9267e136044854e72c3196179cac63ba4fa4254 Author: Chad Austin Date: Mon Dec 10 10:54:52 2018 -0800 fuse: continue to send FUSE_RELEASEDIR when FUSE_OPEN returns ENOSYS commit 2e64ff154ce6ce9a8dc0f9556463916efa6ff460 upstream. When FUSE_OPEN returns ENOSYS, the no_open bit is set on the connection. Because the FUSE_RELEASE and FUSE_RELEASEDIR paths share code, this incorrectly caused the FUSE_RELEASEDIR request to be dropped and never sent to userspace. Pass an isdir bool to distinguish between FUSE_RELEASE and FUSE_RELEASEDIR inside of fuse_file_put. Fixes: 7678ac50615d ("fuse: support clients that don't implement 'open'") Cc: # v3.14 Signed-off-by: Chad Austin Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 113fe99d6376b123e553ff5135d136d3f728b723 Author: Alek Du Date: Thu Dec 6 17:24:59 2018 +0800 mmc: sdhci: fix the timeout check window for clock and reset commit b704441e38f645dcfba1348ca3cc1ba43d1a9f31 upstream. We observed some premature timeouts on a virtualization platform, the log is like this: case 1: [159525.255629] mmc1: Internal clock never stabilised. [159525.255818] mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== [159525.256049] mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00001002 ... [159525.257205] mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x0000fa03 From the clock control register dump, we are pretty sure the clock was stablized. case 2: [ 914.550127] mmc1: Reset 0x2 never completed. [ 914.550321] mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== [ 914.550608] mmc1: sdhci: Sys addr: 0x00000010 | Version: 0x00001002 After checking the sdhci code, we found the timeout check actually has a little window that the CPU can be scheduled out and when it comes back, the original time set or check is not valid. Fixes: 5a436cc0af62 ("mmc: sdhci: Optimize delay loops") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Alek Du Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 661feb2fc993e608a57c3502b46720de9efede39 Author: Faiz Abbas Date: Wed Nov 21 16:03:55 2018 +0530 mmc: sdhci-omap: Fix DCRC error handling during tuning commit db2039fcfd5754d15986340152e4503737f68f8d upstream. Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802") disabled DCRC interrupts during tuning. This write to the interrupt enable register gets overwritten in sdhci_prepare_data() and the interrupt is not in fact disabled. Fix this by disabling the interrupt in the host->ier variable. Fixes: 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802") Cc: Signed-off-by: Faiz Abbas Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 105819c8a545589849eecf5f2a04caf5045b08e0 Author: Wolfram Sang Date: Mon Nov 26 14:38:13 2018 +0100 mmc: core: use mrq->sbc when sending CMD23 for RPMB commit a44f7cb937321d4961bfc8f28912126b06e701c5 upstream. When sending out CMD23 in the blk preparation, the comment there rightfully says: * However, it is not sufficient to just send CMD23, * and avoid the final CMD12, as on an error condition * CMD12 (stop) needs to be sent anyway. This, coupled * with Auto-CMD23 enhancements provided by some * hosts, means that the complexity of dealing * with this is best left to the host. If CMD23 is * supported by card and host, we'll fill sbc in and let * the host deal with handling it correctly. Let's do this behaviour for RPMB as well, and not send CMD23 independently. Otherwise IP cores (like Renesas SDHI) may timeout because of automatic CMD23/CMD12 handling. Reported-by: Masaharu Hayakawa Signed-off-by: Wolfram Sang Tested-by: Clément Péron Reviewed-by: Avri Altman Reviewed-by: Niklas Söderlund Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e1e99fea907a42c1ad9c988458699b90ed567eb0 Author: Aaro Koskinen Date: Tue Nov 20 01:14:00 2018 +0200 MMC: OMAP: fix broken MMC on OMAP15XX/OMAP5910/OMAP310 commit e8cde625bfe8a714a856e1366bcbb259d7346095 upstream. Since v2.6.22 or so there has been reports [1] about OMAP MMC being broken on OMAP15XX based hardware (OMAP5910 and OMAP310). The breakage seems to have been caused by commit 46a6730e3ff9 ("mmc-omap: Fix omap to use MMC_POWER_ON") that changed clock enabling to be done on MMC_POWER_ON. This can happen multiple times in a row, and on 15XX the hardware doesn't seem to like it and the MMC just stops responding. Fix by memorizing the power mode and do the init only when necessary. Before the patch (on Palm TE): mmc0: new SD card at address b368 mmcblk0: mmc0:b368 SDC 977 MiB mmci-omap mmci-omap.0: command timeout (CMD18) mmci-omap mmci-omap.0: command timeout (CMD13) mmci-omap mmci-omap.0: command timeout (CMD13) mmci-omap mmci-omap.0: command timeout (CMD12) [x 6] mmci-omap mmci-omap.0: command timeout (CMD13) [x 6] mmcblk0: error -110 requesting status mmci-omap mmci-omap.0: command timeout (CMD8) mmci-omap mmci-omap.0: command timeout (CMD18) mmci-omap mmci-omap.0: command timeout (CMD13) mmci-omap mmci-omap.0: command timeout (CMD13) mmci-omap mmci-omap.0: command timeout (CMD12) [x 6] mmci-omap mmci-omap.0: command timeout (CMD13) [x 6] mmcblk0: error -110 requesting status mmcblk0: recovery failed! print_req_error: I/O error, dev mmcblk0, sector 0 Buffer I/O error on dev mmcblk0, logical block 0, async page read mmcblk0: unable to read partition table After the patch: mmc0: new SD card at address b368 mmcblk0: mmc0:b368 SDC 977 MiB mmcblk0: p1 The patch is based on a fix and analysis done by Ladislav Michl. Tested on OMAP15XX/OMAP310 (Palm TE), OMAP1710 (Nokia 770) and OMAP2420 (Nokia N810). [1] https://marc.info/?t=123175197000003&r=1&w=2 Fixes: 46a6730e3ff9 ("mmc-omap: Fix omap to use MMC_POWER_ON") Reported-by: Ladislav Michl Reported-by: Andrzej Zaborowski Tested-by: Ladislav Michl Acked-by: Tony Lindgren Signed-off-by: Aaro Koskinen Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2a335229946ec7e04fdd9477e63a08650a7a9999 Author: Amir Goldstein Date: Wed Nov 14 16:01:34 2018 +0200 ovl: fix missing override creds in link of a metacopy upper commit 91ff20f34e94424e586f57f4f593beae16504f86 upstream. Theodore Ts'o reported a v4.19 regression with docker-dropbox: https://marc.info/?l=linux-fsdevel&m=154070089431116&w=2 "I was rebuilding my dropbox Docker container, and it failed in 4.19 with the following error: ... dpkg: error: error creating new backup file \ '/var/lib/dpkg/status-old': Invalid cross-device link" The problem did not reproduce with metacopy feature disabled. The error was caused by insufficient credentials to set "trusted.overlay.redirect" xattr on link of a metacopy file. Reproducer: echo Y > /sys/module/overlay/parameters/redirect_dir echo Y > /sys/module/overlay/parameters/metacopy cd /tmp mkdir l u w m chmod 777 l u touch l/foo ln l/foo l/link chmod 666 l/foo mount -t overlay none -olowerdir=l,upperdir=u,workdir=w m su fsgqa ln m/foo m/bar [ 21.455823] overlayfs: failed to set redirect (-1) ln: failed to create hard link 'm/bar' => 'm/foo':\ Invalid cross-device link Reported-by: Theodore Y. Ts'o Reported-by: Maciej Zięba Fixes: 4120fe64dce4 ("ovl: Set redirect on upper inode when it is linked") Cc: # v4.19 Signed-off-by: Amir Goldstein Acked-by: Vivek Goyal Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 3faf68a42f97b5ca3aa78a0e93ec4d3ff9971ce7 Author: Amir Goldstein Date: Mon Nov 5 07:50:10 2018 +0200 ovl: fix decode of dir file handle with multi lower layers commit 155b8a0492a90a4c6e22f046a3568b92a6bc48da upstream. When decoding a lower file handle, we first call ovl_check_origin_fh() with connected=false to get any real lower dentry for overlay inode cache lookup. If the real dentry is a disconnected dir dentry, ovl_check_origin_fh() is called again with connected=true to get a connected real dentry and find the lower layer the real dentry belongs to. If the first call returned a connected real dentry, we use it to lookup an overlay connected dentry, but the first ovl_check_origin_fh() call with connected=false did not check that the found dentry is under the root of the layer (see ovl_acceptable()), it only checked that the found dentry super block matches the uuid of the lower file handle. In case there are multiple lower layers on the same fs and the found dentry is not from the top most lower layer, using the layer index returned from the first ovl_check_origin_fh() is wrong and we end up failing to decode the file handle. Fix this by always calling ovl_check_origin_fh() with connected=true if we got a directory dentry in the first call. Fixes: 8b58924ad55c ("ovl: lookup in inode cache first when decoding...") Cc: # v4.17 Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 7290c71ded83bad817ed7b4827afd725e81f20d0 Author: Keith Busch Date: Mon Dec 10 08:44:42 2018 -0700 block/bio: Do not zero user pages commit f55adad601c6a97c8c9628195453e0fb23b4a0ae upstream. We don't need to zero fill the bio if not using kernel allocated pages. Fixes: f3587d76da05 ("block: Clear kernel memory before copying to user") # v4.20-rc2 Reported-by: Todd Aiken Cc: Laurence Oberman Cc: stable@vger.kernel.org Cc: Bart Van Assche Tested-by: Laurence Oberman Signed-off-by: Keith Busch Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit beb98fda1853639bb7312da746d49a33a1325ddf Author: Robin Murphy Date: Mon Dec 10 19:33:31 2018 +0000 arm64: dma-mapping: Fix FORCE_CONTIGUOUS buffer clearing commit 3238c359acee4ab57f15abb5a82b8ab38a661ee7 upstream. We need to invalidate the caches *before* clearing the buffer via the non-cacheable alias, else in the worst case __dma_flush_area() may write back dirty lines over the top of our nice new zeros. Fixes: dd65a941f6ba ("arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag") Cc: # 4.18.x- Acked-by: Will Deacon Signed-off-by: Robin Murphy Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit d41c49daf25953490fe3a0832fa6bb0a6739ab0c Author: Andrea Arcangeli Date: Fri Dec 14 14:17:17 2018 -0800 userfaultfd: check VM_MAYWRITE was set after verifying the uffd is registered commit 01e881f5a1fca4677e82733061868c6d6ea05ca7 upstream. Calling UFFDIO_UNREGISTER on virtual ranges not yet registered in uffd could trigger an harmless false positive WARN_ON. Check the vma is already registered before checking VM_MAYWRITE to shut off the false positive warning. Link: http://lkml.kernel.org/r/20181206212028.18726-2-aarcange@redhat.com Cc: Fixes: 29ec90660d68 ("userfaultfd: shmem/hugetlbfs: only allow to register VM_MAYWRITE vmas") Signed-off-by: Andrea Arcangeli Reported-by: syzbot+06c7092e7d71218a2c16@syzkaller.appspotmail.com Acked-by: Mike Rapoport Acked-by: Hugh Dickins Acked-by: Peter Xu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 498a6e6be0de3cd8ccccce6628f0ea1dc4d8f159 Author: Piotr Jaroszynski Date: Fri Dec 14 14:17:14 2018 -0800 fs/iomap.c: get/put the page in iomap_page_create/release() commit 61c6de667263184125d5ca75e894fcad632b0dd3 upstream. migrate_page_move_mapping() expects pages with private data set to have a page_count elevated by 1. This is what used to happen for xfs through the buffer_heads code before the switch to iomap in commit 82cb14175e7d ("xfs: add support for sub-pagesize writeback without buffer_heads"). Not having the count elevated causes move_pages() to fail on memory mapped files coming from xfs. Make iomap compatible with the migrate_page_move_mapping() assumption by elevating the page count as part of iomap_page_create() and lowering it in iomap_page_release(). It causes the move_pages() syscall to misbehave on memory mapped files from xfs. It does not not move any pages, which I suppose is "just" a perf issue, but it also ends up returning a positive number which is out of spec for the syscall. Talking to Michal Hocko, it sounds like returning positive numbers might be a necessary update to move_pages() anyway though (https://lkml.kernel.org/r/20181116114955.GJ14706@dhcp22.suse.cz). I only hit this in tests that verify that move_pages() actually moved the pages. The test also got confused by the positive return from move_pages() (it got treated as a success as positive numbers were not expected and not handled) making it a bit harder to track down what's going on. Link: http://lkml.kernel.org/r/20181115184140.1388751-1-pjaroszynski@nvidia.com Fixes: 82cb14175e7d ("xfs: add support for sub-pagesize writeback without buffer_heads") Signed-off-by: Piotr Jaroszynski Reviewed-by: Christoph Hellwig Cc: William Kucharski Cc: Darrick J. Wong Cc: Brian Foster Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b11d5c025d8e483de0c00e7a99c0cef8608d1f73 Author: Thierry Reding Date: Fri Dec 14 14:17:24 2018 -0800 scripts/spdxcheck.py: always open files in binary mode commit 3a6ab5c7dc114057fd67750e308e1745dafc0e6a upstream. The spdxcheck script currently falls over when confronted with a binary file (such as Documentation/logo.gif). To avoid that, always open files in binary mode and decode line-by-line, ignoring encoding errors. One tricky case is when piping data into the script and reading it from standard input. By default, standard input will be opened in text mode, so we need to reopen it in binary mode. The breakage only happens with python3 and results in a UnicodeDecodeError (according to Uwe). Link: http://lkml.kernel.org/r/20181212131210.28024-1-thierry.reding@gmail.com Fixes: 6f4d29df66ac ("scripts/spdxcheck.py: make python3 compliant") Signed-off-by: Thierry Reding Reviewed-by: Jeremy Cline Cc: Thomas Gleixner Cc: Jonathan Corbet Cc: Joe Perches Cc: Uwe Kleine-König Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a6136922d905d103b4edb88c5f3dd3ccf3ce51fe Author: Jeff Moyer Date: Tue Dec 11 12:37:49 2018 -0500 aio: fix spectre gadget in lookup_ioctx commit a538e3ff9dabcdf6c3f477a373c629213d1c3066 upstream. Matthew pointed out that the ioctx_table is susceptible to spectre v1, because the index can be controlled by an attacker. The below patch should mitigate the attack for all of the aio system calls. Cc: stable@vger.kernel.org Reported-by: Matthew Wilcox Reported-by: Dan Carpenter Signed-off-by: Jeff Moyer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4c74d5f1836ebcbe78208ed0c295a62254fa419f Author: Chen-Yu Tsai Date: Tue Dec 4 17:04:57 2018 +0800 pinctrl: sunxi: a83t: Fix IRQ offset typo for PH11 commit 478b6767ad26ab86d9ecc341027dd09a87b1f997 upstream. Pin PH11 is used on various A83T board to detect a change in the OTG port's ID pin, as in when an OTG host cable is plugged in. The incorrect offset meant the gpiochip/irqchip was activating the wrong pin for interrupts. Fixes: 4730f33f0d82 ("pinctrl: sunxi: add allwinner A83T PIO controller support") Cc: Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 67e255bf2f349d04b2ccd591655a0d3a7a28edbf Author: Arnd Bergmann Date: Fri Dec 14 23:10:12 2018 +0100 drm/msm: fix address space warning In the linux-4.19 stable kernel, we get a warning about a type mismatch between phys_addr_t and dma_addr_t: drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c: In function '_dpu_dbg_dump_dpu_dbg_bus': drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c:2003:16: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] list_size, &phys, GFP_KERNEL); ^~~~~ In file included from include/linux/dma-buf.h:31, from drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c:20: include/linux/dma-mapping.h:561:15: note: expected 'dma_addr_t *' {aka 'long long unsigned int *'} but argument is of type 'phys_addr_t *' {aka 'unsigned int *'} dma_addr_t *dma_handle, gfp_t flag) ~~~~~~~~~~~~^~~~~~~~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c: In function '_dpu_dbg_dump_vbif_dbg_bus': drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c:2154:16: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] list_size, &phys, GFP_KERNEL); ^~~~~ In file included from include/linux/dma-buf.h:31, from drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c:20: include/linux/dma-mapping.h:561:15: note: expected 'dma_addr_t *' {aka 'long long unsigned int *'} but argument is of type 'phys_addr_t *' {aka 'unsigned int *'} This code was removed in linux-4.20 with upstream commit effec874792f ("drm/msm/dpu: Remove dpu_dbg"). Rather than backporting the large patch, this just fixes the warning by using the correct type. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 26527312c51953bd4a13aae1a8d4986f2a3d4bee Author: Arnd Bergmann Date: Fri Dec 14 23:10:11 2018 +0100 ARM: dts: qcom-apq8064-arrow-sd-600eval fix graph_endpoint warning Upstream commit 972910948fb6 ("ARM: dts: qcom: Remove Arrow SD600 eval board") removed this file because there are no known users, but in linux-4.19.y, we still get a compile-time warnign for it: arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dtb: Warning (graph_endpoint): /soc/mdp@5100000/ports/port@3/endpoint: graph connection to node '/soc/hdmi-tx@4a00000/ports/port@0/endpoint' is not bidirectional Address the warning by adding the remote endpoint that makes the link bidirectional. This is the same property that other boards use. Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit cd50eeeb664692519b896679b2d8c48ced80a372 Author: Arnd Bergmann Date: Fri Dec 14 23:10:10 2018 +0100 i2c: aspeed: fix build warning Upstream commit 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events properly") reworked the interrupt handling and fixed a warning in the process: drivers/i2c/busses/i2c-aspeed.c: In function 'aspeed_i2c_bus_irq': drivers/i2c/busses/i2c-aspeed.c:567:1: error: label 'out' defined but not used [-Werror=unused-label] The warning is still present in v4.19.8 and can be fixed either by applying that original patch, or by adding a simple #ifdef. Here, I choose the second simpler option as the original patch seems too invasive for a stable backport. Signed-off-by: Arnd Bergmann Reviewed-by: Brendan Higgins Signed-off-by: Sasha Levin commit 340a904a19441b6c97919f8dcb18ade57372d2bf Author: Arnd Bergmann Date: Fri Dec 14 23:10:09 2018 +0100 slimbus: ngd: mark PM functions as __maybe_unused Commit 2e6ae11dd0d1c37f44cec51a58fb2092e55ed0f5 upstream. qcom_slim_ngd_runtime_suspend is protected by an #ifdef, qcom_slim_ngd_runtime_idle is now, which causes a build time warning: drivers/slimbus/qcom-ngd-ctrl.c:1470:12: error: 'qcom_slim_ngd_runtime_idle' defined but not used [-Werror=unused-function] Marking both as __maybe_unused lets us get rid of the warning as well as the #ifdef. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 14e8b9ec43c9f2339c472ce22c974eab1f1191ba Author: Lubomir Rintel Date: Fri Dec 14 23:10:08 2018 +0100 staging: olpc_dcon: add a missing dependency Commit 33f49571d75024b1044cd02689ad2bdb4924cc80 upstream. WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n] Selected by [y]: - FB_OLPC_DCON [=y] && STAGING [=y] && X86 [=y] && OLPC [=y] && FB [=y] && I2C [=y] && (GPIO_CS5535 [=n] || GPIO_CS5535 [=n]=n) Signed-off-by: Lubomir Rintel Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cda8e63c89d7eca14910638f945f5469500f1f82 Author: Arnd Bergmann Date: Fri Dec 14 23:10:07 2018 +0100 scsi: raid_attrs: fix unused variable warning Commit 0eeec01488da9b1403c8c29e73eacac8af9e4bf2 upstream. I ran into a new warning on randconfig kernels: drivers/scsi/raid_class.c: In function 'raid_match': drivers/scsi/raid_class.c:64:24: error: unused variable 'i' [-Werror=unused-variable] This looks like a very old problem that for some reason was very hard to run into, but it is very easy to fix, by replacing the incorrect #ifdef with a simpler IS_ENABLED() check. Fixes: fac829fdcaf4 ("[SCSI] raid_attrs: fix dependency problems") Signed-off-by: Arnd Bergmann Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dc5350715915eb08f73fa616f948b583a088d27c Author: Vincent Guittot Date: Fri Dec 14 23:10:06 2018 +0100 sched/pelt: Fix warning and clean up IRQ PELT config Commit 11d4afd4ff667f9b6178ee8c142c36cb78bd84db upstream. Create a config for enabling irq load tracking in the scheduler. irq load tracking is useful only when irq or paravirtual time is accounted but it's only possible with SMP for now. Also use __maybe_unused to remove the compilation warning in update_rq_clock_task() that has been introduced by: 2e62c4743adc ("sched/fair: Remove #ifdefs from scale_rt_capacity()") Suggested-by: Ingo Molnar Reported-by: Dou Liyang Reported-by: Miguel Ojeda Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: bp@alien8.de Cc: dou_liyang@163.com Fixes: 2e62c4743adc ("sched/fair: Remove #ifdefs from scale_rt_capacity()") Link: http://lkml.kernel.org/r/1537867062-27285-1-git-send-email-vincent.guittot@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin