- 19 Dec, 2018 37 commits
-
-
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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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 <snitzer@redhat.com> 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:
Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-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:
Will Deacon <will.deacon@arm.com> Signed-off-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:
-
Piotr Jaroszynski authored
commit 61c6de66 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 82cb1417 ("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: 82cb1417 ("xfs: add support for sub-pagesize writeback without buffer_heads") Signed-off-by:
Piotr Jaroszynski <pjaroszynski@nvidia.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Cc: William Kucharski <william.kucharski@oracle.com> Cc: Darrick J. Wong <darrick.wong@oracle.com> Cc: Brian Foster <bfoster@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Thierry Reding authored
commit 3a6ab5c7 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: 6f4d29df ("scripts/spdxcheck.py: make python3 compliant") Signed-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
Jeremy Cline <jcline@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Joe Perches <joe@perches.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jeff Moyer authored
commit a538e3ff 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 <willy@infradead.org> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
-
Chen-Yu Tsai authored
commit 478b6767 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: 4730f33f ("pinctrl: sunxi: add allwinner A83T PIO controller support") Cc: <stable@vger.kernel.org> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
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: 25fdd593 ("drm/msm: Add SDM845 DPU support") Signed-off-by:Sasha Levin <sashal@kernel.org>
-
Arnd Bergmann authored
Upstream commit 97291094 ("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 authored
Upstream commit 3e9efc32 ("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:
Brendan Higgins <brendanhiggins@google.com> Signed-off-by:
-
Arnd Bergmann authored
Commit 2e6ae11d 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: 917809e2 ("slimbus: ngd: Add qcom SLIMBus NGD driver") Signed-off-by:
-
Lubomir Rintel authored
Commit 33f49571 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:
-
Arnd Bergmann authored
Commit 0eeec014 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: fac829fd ("[SCSI] raid_attrs: fix dependency problems") Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Vincent Guittot authored
Commit 11d4afd4 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: 2e62c474 ("sched/fair: Remove #ifdefs from scale_rt_capacity()") Suggested-by:
Ingo Molnar <mingo@redhat.com> Reported-by:
Dou Liyang <douly.fnst@cn.fujitsu.com> Reported-by:
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Signed-off-by:
Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bp@alien8.de Cc: dou_liyang@163.com Fixes: 2e62c474 ("sched/fair: Remove #ifdefs from scale_rt_capacity()") Link: http://lkml.kernel.org/r/1537867062-27285-1-git-send-email-vincent.guittot@linaro.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
- 17 Dec, 2018 3 commits
-
-
Greg Kroah-Hartman authored
-
Eric Dumazet authored
commit f9bfe4e6 upstream. tcp_tso_should_defer() can return true in three different cases : 1) We are cwnd-limited 2) We are rwnd-limited 3) We are application limited. Neal pointed out that my recent fix went too far, since it assumed that if we were not in 1) case, we must be rwnd-limited Fix this by properly populating the is_cwnd_limited and is_rwnd_limited booleans. After this change, we can finally move the silly check for FIN flag only for the application-limited case. The same move for EOR bit will be handled in net-next, since commit 1c09f7d0 ("tcp: do not try to defer skbs with eor mark (MSG_EOR)") is scheduled for linux-4.21 Tested by running 200 concurrent netperf -t TCP_RR -- -r 60000,100 and checking none of them was rwnd_limited in the chrono_stat output from "ss -ti" command. Fixes: 41727549 ("tcp: Do not underestimate rwnd_limited") Signed-off-by:
Eric Dumazet <edumazet@google.com> Suggested-by:
Neal Cardwell <ncardwell@google.com> Reviewed-by:
Soheil Hassas Yeganeh <soheil@google.com> Reviewed-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Edward Cree authored
commit afd59424 upstream. When patching in a new sequence for the first insn of a subprog, the start of that subprog does not change (it's the first insn of the sequence), so adjust_subprog_starts should check start <= off (rather than < off). Also added a test to test_verifier.c (it's essentially the syz reproducer). Fixes: cc8b0b92 ("bpf: introduce function calls (function boundaries)") Reported-by: syzbot+4fc427c7af994b0948be@syzkaller.appspotmail.com Signed-off-by:
Edward Cree <ecree@solarflare.com> Acked-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
