- 21 Dec, 2018 6 commits
-
-
Wolfram Sang authored
[ Upstream commit 0b57436f ] We should check the bus state before reinitializing the IP core. Otherwise, the internal bus busy state which also tracks multi-master activity is lost. Credits go to the Renesas BSP team for suggesting this change. Reported-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Fixes: ae481cc1 ("i2c: rcar: fix resume by always initializing registers before transfer") Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Vitaly Kuznetsov authored
[ Upstream commit 10f91c73 ] It makes little sense but still possible to put Hyper-V guests into suspend-to-idle state. To wake them up two wakeup sources were registered in the past: hyperv-keyboard and hid-hyperv. However, since commit eed4d47e ("ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle") pm_wakeup_event() from these devices is ignored. Switch to pm_wakeup_hard_event() API as these devices are actually the only possible way to wakeup Hyper-V guests. Fixes: eed4d47e (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
K. Y. Srinivasan <kys@microsoft.com> Acked-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit 05cc09de ] There is no unregister netlink notifier and family on error paths in init_mac80211_hwsim(). Also there is an error path where hwsim_class is not destroyed. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Fixes: 62759361 ("mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Michael J. Ruhl authored
commit 28a9a9e8 upstream Packet queue state is over used to determine SDMA descriptor availablitity and packet queue request state. cpu 0 ret = user_sdma_send_pkts(req, pcount); cpu 0 if (atomic_read(&pq->n_reqs)) cpu 1 IRQ user_sdma_txreq_cb calls pq_update() (state to _INACTIVE) cpu 0 xchg(&pq->state, SDMA_PKT_Q_ACTIVE); At this point pq->n_reqs == 0 and pq->state is incorrectly SDMA_PKT_Q_ACTIVE. The close path will hang waiting for the state to return to _INACTIVE. This can also change the state from _DEFERRED to _ACTIVE. However, this is a mostly benign race. Remove the racy code path. Use n_reqs to determine if a packet queue is active or not. Cc: <stable@vger.kernel.org> # 4.19.x Reviewed-by:
Mitko Haralanov <mitko.haralanov@intel.com> Reviewed-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Peter Zijlstra authored
commit 7aa54be2 upstream. On x86 we cannot do fetch_or() with a single instruction and thus end up using a cmpxchg loop, this reduces determinism. Replace the fetch_or() with a composite operation: tas-pending + load. Using two instructions of course opens a window we previously did not have. Consider the scenario: CPU0 CPU1 CPU2 1) lock trylock -> (0,0,1) 2) lock trylock /* fail */ 3) unlock -> (0,0,0) 4) lock trylock -> (0,0,1) 5) tas-pending -> (0,1,1) load-val <- (0,1,0) from 3 6) clear-pending-set-locked -> (0,0,1) FAIL: _2_ owners where 5) is our new composite operation. When we consider each part of the qspinlock state as a separate variable (as we can when _Q_PENDING_BITS == 8) then the above is entirely possible, because tas-pending will only RmW the pending byte, so the later load is able to observe prior tail and lock state (but not earlier than its own trylock, which operates on the whole word, due to coherence). To avoid this we need 2 things: - the load must come after the tas-pending (obviously, otherwise it can trivially observe prior state). - the tas-pending must be a full word RmW instruction, it cannot be an XCHGB for example, such that we cannot observe other state prior to setting pending. On x86 we can realize this by using "LOCK BTS m32, r32" for tas-pending followed by a regular load. Note that observing later state is not a problem: - if we fail to observe a later unlock, we'll simply spin-wait for that store to become visible. - if we observe a later xchg_tail(), there is no difference from that xchg_tail() having taken place before the tas-pending. Suggested-by:
Will Deacon <will.deacon@arm.com> Reported-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Ingo Molnar <mingo@kernel.org> [bigeasy: GEN_BINARY_RMWcc macro redo] Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Peter Zijlstra authored
commit 53bf57fa upstream. Flip the branch condition after atomic_fetch_or_acquire(_Q_PENDING_VAL) such that we loose the indent. This also result in a more natural code flow IMO. Signed-off-by:
-
- 19 Dec, 2018 34 commits
-
-
Greg Kroah-Hartman authored
-
Masahiro Yamada authored
commit 25896d07 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: 829fe4aa ("x86: Allow generating user-space headers without a compiler") Reported-by:
Meelis Roos <mroos@linux.ee> Tested-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Zhenzhong Duan <zhenzhong.duan@oracle.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com> Fixes: 4cd24de3 ("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/206Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Damien Le Moal authored
commit d57f9da8 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: 3b1a94c8 ("dm zoned: drive-managed zoned block device target") Cc: stable@vger.kernel.org Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Junwei Zhang authored
commit d55d8be0 upstream. Some new variants require different firmwares. Signed-off-by:
Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 153573d8 upstream. Some new variants require updated firmware. V2: add MODULE_FIRMWARE for new firmwares Reviewed-by: Huang Rui <ray.huang@amd.com> (v1) Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 2244b588 upstream. New vega ids. Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 756e16bf upstream. New vega10 ids. Reviewed-by:
-
Kenneth Feng authored
commit cf4197ed upstream. Instead of EVV cks-off voltages, avfs cks-off voltages can avoid the overshoot voltages when switching sclk. Signed-off-by:
Kenneth Feng <kenneth.feng@amd.com> Acked-by:
-
Chris Wilson authored
commit cf66b8a0 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: 987abd5c ("drm/i915/execlists: Force write serialisation into context image vs execution") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181206084431.9805-3-chris@chris-wilson.co.uk (cherry picked from commit 490b8c65) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Tina Zhang authored
commit a40fa231 upstream. Commit b244ffa1 ("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: b244ffa1("drm/i915/gvt: Fix drm_format_mod value for vGPU plane") Signed-off-by:
Tina Zhang <tina.zhang@intel.com> Cc: stable@vger.kernel.org # v4.19+ Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Brian Norris authored
commit 63238173 upstream. This reverts commit 7f3ef5de. 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: 7f3ef5de ("drm/rockchip: Allow driver to be shutdown on reboot/kexec") Cc: Jeffy Chen <jeffy.chen@rock-chips.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Vicente Bergas <vicencb@gmail.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: stable@vger.kernel.org Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20181205181657.177703-1-briannorris@chromium.orgSigned-off-by:
-
Ben Skeggs authored
commit 970a5ee4 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: d00ddd9d ("drm/nouveau/kms/nv50-: allocate push buffers in vidmem on pascal") Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Cc: <stable@vger.kernel.org> # 4.19+ Signed-off-by:
-
Lyude Paul authored
commit 24199c54 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: f479c0ba ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: <stable@vger.kernel.org> # v4.10+ Signed-off-by:
-
Benjamin Herrenschmidt authored
commit bf3d6afb upstream. Commit 78e5dfea ("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: 78e5dfea ("powerpc: dts: replace 'linux,stdout-path' with 'stdout-path'") Cc: stable@vger.kernel.org # v4.17+ Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Radu Rendec authored
commit 78e7b15e 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: 6b2fd7ef ("PCI/MSI/PPC: Remove arch_msi_check_device()") Cc: stable@vger.kernel.org # v3.18+ Signed-off-by:
Radu Rendec <radu.rendec@gmail.com> Signed-off-by:
-
Hans Verkuil authored
commit 04990215 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 b3379c62. Fixes: b3379c62 ('vb2: only call start_streaming if sufficient buffers are queued') Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v4.16 and up Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Steven Rostedt (VMware) authored
commit 2840f84f 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: 591dffda ("ftrace: Allow for function tracing instance to filter functions") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt (VMware) authored
commit 3cec638b 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: bac5fb97 ("tracing: Add and use generic set_trigger_filter() implementation") Reviewed-by:
Tom Zanussi <tom.zanussi@linux.intel.com> Signed-off-by:
-
Steven Rostedt (VMware) authored
commit b61c1920 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: 80765597 ("tracing: Rewrite filter logic to be simpler and faster") Reviewed-by:
-
Mike Snitzer authored
commit 89f5fa47 upstream. Otherwise the incoming bios, of various types, won't be shaped based on the DM device's advertised limits. Depends-on: af67c31f ("blk: remove bio_set arg from blk_queue_split()") Fixes: 744889b7 ("block: don't deal with discard limit in blkdev_issue_discard()") Cc: stable@vger.kernel.org Signed-off-by:
-
Mike Snitzer authored
commit 687cf441 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: 0d963b6e ("dm cache metadata: fix metadata2 format's blocks_are_clean_separate_dirty") Cc: stable@vger.kernel.org Reported-by:
David Teigland <teigland@redhat.com> Signed-off-by:
-
Mike Snitzer authored
commit f6c36758 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:
-
Stefan Wahren authored
commit e25b6783 upstream. The commit b1b8f45b ("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: b1b8f45b ("ARM: dts: bcm2837: Add missing GPIOs of Expander") Cc: stable@vger.kernel.org Reported-by:
Matthias Lueschner <lueschem@gmail.com> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911443Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Lubomir Rintel authored
commit 76f4e2c3 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 <lkundrak@v3.sk> Acked-by:
Arnd Bergmann <arnd@arndb.de> Cc: stable@vger.kernel.org Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Chad Austin authored
commit 2e64ff15 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: 7678ac50 ("fuse: support clients that don't implement 'open'") Cc: <stable@vger.kernel.org> # v3.14 Signed-off-by:
Chad Austin <chadaustin@fb.com> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Alek Du authored
commit b704441e 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: 5a436cc0 ("mmc: sdhci: Optimize delay loops") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by:
Alek Du <alek.du@intel.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Faiz Abbas authored
commit db2039fc upstream. Commit 7d33c358 ("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: 7d33c358 ("mmc: sdhci-omap: Workaround for Errata i802") Cc: <stable@vger.kernel.org> Signed-off-by:
Faiz Abbas <faiz_abbas@ti.com> Acked-by:
-
Wolfram Sang authored
commit a44f7cb9 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 <masaharu.hayakawa.ry@renesas.com> Signed-off-by:
Clément Péron <peron.clem@gmail.com> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Cc: stable@vger.kernel.org Signed-off-by:
-
Aaro Koskinen authored
commit e8cde625 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 46a6730e ("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: 46a6730e ("mmc-omap: Fix omap to use MMC_POWER_ON") Reported-by:
Ladislav Michl <ladis@linux-mips.org> Reported-by:
Andrzej Zaborowski <balrogg@gmail.com> Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Cc: stable@vger.kernel.org Signed-off-by:
-
Amir Goldstein authored
commit 91ff20f3 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 <tytso@mit.edu> Reported-by:
Maciej Zięba <maciekz82@gmail.com> Fixes: 4120fe64 ("ovl: Set redirect on upper inode when it is linked") Cc: <stable@vger.kernel.org> # v4.19 Signed-off-by:
Amir Goldstein <amir73il@gmail.com> Acked-by:
Vivek Goyal <vgoyal@redhat.com> Signed-off-by:
-
Amir Goldstein authored
commit 155b8a04 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: 8b58924a ("ovl: lookup in inode cache first when decoding...") Cc: <stable@vger.kernel.org> # v4.17 Signed-off-by:
-
Keith Busch authored
commit f55adad6 upstream. We don't need to zero fill the bio if not using kernel allocated pages. Fixes: f3587d76 ("block: Clear kernel memory before copying to user") # v4.20-rc2 Reported-by:
Todd Aiken <taiken@mvtech.ca> Cc: Laurence Oberman <loberman@redhat.com> Cc: stable@vger.kernel.org Cc: Bart Van Assche <bvanassche@acm.org> Tested-by:
Laurence Oberman <loberman@redhat.com> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Robin Murphy authored
commit 3238c359 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: dd65a941 ("arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag") Cc: <stable@vger.kernel.org> # 4.18.x- Acked-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Andrea Arcangeli authored
commit 01e881f5 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: <stable@vger.kernel.org> Fixes: 29ec9066 ("userfaultfd: shmem/hugetlbfs: only allow to register VM_MAYWRITE vmas") Signed-off-by:
Andrea Arcangeli <aarcange@redhat.com> Reported-by: syzbot+06c7092e7d71218a2c16@syzkaller.appspotmail.com Acked-by:
Mike Rapoport <rppt@linux.ibm.com> Acked-by:
Hugh Dickins <hughd@google.com> Acked-by:
Peter Xu <peterx@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
