aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-03-03dm bio record: save/restore bi_end_io and bi_integrityMike Snitzer1-0/+15
Also, save/restore __bi_remaining in case the bio was used in a BIO_CHAIN (e.g. due to blk_queue_split). Suggested-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2020-03-03btrfs: fix RAID direct I/O reads with alternate csumsOmar Sandoval1-1/+3
btrfs_lookup_and_bind_dio_csum() does pointer arithmetic which assumes 32-bit checksums. If using a larger checksum, this leads to spurious failures when a direct I/O read crosses a stripe. This is easy to reproduce: # mkfs.btrfs -f --checksum blake2 -d raid0 /dev/vdc /dev/vdd ... # mount /dev/vdc /mnt # cd /mnt # dd if=/dev/urandom of=foo bs=1M count=1 status=none # dd if=foo of=/dev/null bs=1M iflag=direct status=none dd: error reading 'foo': Input/output error # dmesg | tail -1 [ 135.821568] BTRFS warning (device vdc): csum failed root 5 ino 257 off 421888 ... Fix it by using the actual checksum size. Fixes: 1e25a2e3ca0d ("btrfs: don't assume ordered sums to be 4 bytes") CC: [email protected] # 5.4+ Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Omar Sandoval <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-03-03ASoC: SOF: Fix snd_sof_ipc_stream_posn()Dan Carpenter1-1/+1
We're passing "&posn" instead of "posn" so it ends up corrupting memory instead of doing something useful. Fixes: 53e0c72d98ba ("ASoC: SOF: Add support for IPC IO between DSP and Host") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-03-03ASoC: rt1015: modify pre-divider for sysclkJack Yu1-1/+1
Modify pre-divider for system clock. Signed-off-by: Jack Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-03-03interconnect: Handle memory allocation errorsGeorgi Djakov1-0/+9
When we allocate memory, kasprintf() can fail and we must check its return value. Fixes: 05309830e1f8 ("interconnect: Add a name to struct icc_path") Signed-off-by: Georgi Djakov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-03altera-stapl: altera_get_note: prevent write beyond end of 'key'Daniel Axtens1-6/+6
altera_get_note is called from altera_init, where key is kzalloc(33). When the allocation functions are annotated to allow the compiler to see the sizes of objects, and with FORTIFY_SOURCE, we see: In file included from drivers/misc/altera-stapl/altera.c:14:0: In function ‘strlcpy’, inlined from ‘altera_init’ at drivers/misc/altera-stapl/altera.c:2189:5: include/linux/string.h:378:4: error: call to ‘__write_overflow’ declared with attribute error: detected write beyond size of object passed as 1st parameter __write_overflow(); ^~~~~~~~~~~~~~~~~~ That refers to this code in altera_get_note: if (key != NULL) strlcpy(key, &p[note_strings + get_unaligned_be32( &p[note_table + (8 * i)])], length); The error triggers because the length of 'key' is 33, but the copy uses length supplied as the 'length' parameter, which is always 256. Split the size parameter into key_len and val_len, and use the appropriate length depending on what is being copied. Detected by compiler error, only compile-tested. Cc: "Igor M. Liplianin" <[email protected]> Signed-off-by: Daniel Axtens <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/202002251042.D898E67AC@keescook Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-03binder: prevent UAF for binderfs devicesChristian Brauner2-1/+17
On binder_release(), binder_defer_work(proc, BINDER_DEFERRED_RELEASE) is called which punts the actual cleanup operation to a workqueue. At some point, binder_deferred_func() will be called which will end up calling binder_deferred_release() which will retrieve and cleanup the binder_context attach to this struct binder_proc. If we trace back where this binder_context is attached to binder_proc we see that it is set in binder_open() and is taken from the struct binder_device it is associated with. This obviously assumes that the struct binder_device that context is attached to is _never_ freed. While that might be true for devtmpfs binder devices it is most certainly wrong for binderfs binder devices. So, assume binder_open() is called on a binderfs binder devices. We now stash away the struct binder_context associated with that struct binder_devices: proc->context = &binder_dev->context; /* binderfs stashes devices in i_private */ if (is_binderfs_device(nodp)) { binder_dev = nodp->i_private; info = nodp->i_sb->s_fs_info; binder_binderfs_dir_entry_proc = info->proc_log_dir; } else { . . . proc->context = &binder_dev->context; Now let's assume that the binderfs instance for that binder devices is shutdown via umount() and/or the mount namespace associated with it goes away. As long as there is still an fd open for that binderfs binder device things are fine. But let's assume we now close the last fd for that binderfs binder device. Now binder_release() is called and punts to the workqueue. Assume that the workqueue has quite a bit of stuff to do and doesn't get to cleaning up the struct binder_proc and the associated struct binder_context with it for that binderfs binder device right away. In the meantime, the VFS is killing the super block and is ultimately calling sb->evict_inode() which means it will call binderfs_evict_inode() which does: static void binderfs_evict_inode(struct inode *inode) { struct binder_device *device = inode->i_private; struct binderfs_info *info = BINDERFS_I(inode); clear_inode(inode); if (!S_ISCHR(inode->i_mode) || !device) return; mutex_lock(&binderfs_minors_mutex); --info->device_count; ida_free(&binderfs_minors, device->miscdev.minor); mutex_unlock(&binderfs_minors_mutex); kfree(device->context.name); kfree(device); } thereby freeing the struct binder_device including struct binder_context. Now the workqueue finally has time to get around to cleaning up struct binder_proc and is now trying to access the associate struct binder_context. Since it's already freed it will OOPs. Fix this by holding an additional reference to the inode that is only released once the workqueue is done cleaning up struct binder_proc. This is an easy alternative to introducing separate refcounting on struct binder_device which we can always do later if it becomes necessary. This is an alternative fix to 51d8a7eca677 ("binder: prevent UAF read in print_binder_transaction_log_entry()"). Fixes: 3ad20fe393b3 ("binder: implement binderfs") Fixes: 03e2e07e3814 ("binder: Make transaction_log available in binderfs") Related : 51d8a7eca677 ("binder: prevent UAF read in print_binder_transaction_log_entry()") Cc: [email protected] Signed-off-by: Christian Brauner <[email protected]> Acked-by: Todd Kjos <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-02Revert "bcache: ignore pending signals when creating gc and allocator thread"Jens Axboe2-29/+2
This reverts commit 0b96da639a4874311e9b5156405f69ef9fc3bef8. We can't just go flushing random signals, under the assumption that the OOM killer will just do something else. It's not safe from the OOM perspective, and it could also cause other signals to get randomly lost. Signed-off-by: Jens Axboe <[email protected]>
2020-03-02dt-bindings: arm: fsl: fix APF6Dev compatibleSébastien Szymanski1-1/+1
APF6 Dev compatible is armadeus,imx6dl-apf6dev and not armadeus,imx6dl-apf6dldev. Fixes: 3d735471d066 ("dt-bindings: arm: Document Armadeus SoM and Dev boards devicetree binding") Signed-off-by: Sébastien Szymanski <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-03-02io-wq: remove io_wq_flush and IO_WQ_WORK_INTERNALPavel Begunkov2-39/+1
io_wq_flush() is buggy, during cancelation of a flush, the associated work may be passed to the caller's (i.e. io_uring) @match callback. That callback is expecting it to be embedded in struct io_kiocb. Cancelation of internal work probably doesn't make a lot of sense to begin with. As the flush helper is no longer used, just delete it and the associated work flag. Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-03-02Merge tag 'arm-soc/for-5.6/defconfig-fixes' of ↵Olof Johansson1-0/+1
https://github.com/Broadcom/stblinux into arm/fixes This pull request contains Broadcom ARM-based SoCs defconfig file(s) fixes for v5.6, please pull the following: - Stefan restores CONFIG_DEBUG_FS from the bcm2835_defconfig which was accidentally removed * tag 'arm-soc/for-5.6/defconfig-fixes' of https://github.com/Broadcom/stblinux: ARM: bcm2835_defconfig: Explicitly restore CONFIG_DEBUG_FS Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Olof Johansson <[email protected]>
2020-03-02Merge tag 'amlogic-fixes' of ↵Olof Johansson3-2/+2
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/fixes Amlogic fixes for v5.6-rc * tag 'amlogic-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic: arm64: dts: meson: fix gxm-khadas-vim2 wifi arm64: dts: meson-sm1-sei610: add missing interrupt-names ARM: meson: Drop unneeded select of COMMON_CLK Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Olof Johansson <[email protected]>
2020-03-02ARM: bcm2835_defconfig: Explicitly restore CONFIG_DEBUG_FSStefan Wahren1-0/+1
The commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency") accidentally dropped the DEBUG FS support in bcm2835_defconfig. So restore the config as before the commit. Reported-by: Marek Szyprowski <[email protected]> Fixes: 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency") Signed-off-by: Stefan Wahren <[email protected]> Signed-off-by: Florian Fainelli <[email protected]>
2020-03-02selftest/lkdtm: Use local .gitignoreChristophe Leroy2-4/+2
Commit 68ca0fd272da ("selftest/lkdtm: Don't pollute 'git status'") introduced patterns for git to ignore files generated in tools/testing/selftests/lkdtm/ Use local .gitignore file instead of using the root one. Fixes: 68ca0fd272da ("selftest/lkdtm: Don't pollute 'git status'") Signed-off-by: Christophe Leroy <[email protected]> Acked-by: Kees Cook <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2020-03-02IB/hfi1, qib: Ensure RCU is locked when accessing listDennis Dalessandro2-1/+5
The packet handling function, specifically the iteration of the qp list for mad packet processing misses locking RCU before running through the list. Not only is this incorrect, but the list_for_each_entry_rcu() call can not be called with a conditional check for lock dependency. Remedy this by invoking the rcu lock and unlock around the critical section. This brings MAD packet processing in line with what is done for non-MAD packets. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Mike Marciniszyn <[email protected]> Signed-off-by: Dennis Dalessandro <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-03-02spi: bcm63xx-hsspi: Really keep pll clk enabledChristophe JAILLET1-1/+0
The purpose of commit 0fd85869c2a9 ("spi/bcm63xx-hsspi: keep pll clk enabled") was to keep the pll clk enabled through the lifetime of the device. In order to do that, some 'clk_prepare_enable()'/'clk_disable_unprepare()' calls have been added in the error handling path of the probe function, in the remove function and in the suspend and resume functions. However, a 'clk_disable_unprepare()' call has been unfortunately left in the probe function. So the commit seems to be more or less a no-op. Axe it now, so that the pll clk is left enabled through the lifetime of the device, as described in the commit. Fixes: 0fd85869c2a9 ("spi/bcm63xx-hsspi: keep pll clk enabled") Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Jonas Gorski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-03-02io-wq: fix IO_WQ_WORK_NO_CANCEL cancellationPavel Begunkov1-6/+14
To cancel a work, io-wq sets IO_WQ_WORK_CANCEL and executes the callback. However, IO_WQ_WORK_NO_CANCEL works will just execute and may return next work, which will be ignored and lost. Cancel the whole link. Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-03-02block: Remove used kblockd_schedule_work_on()Daniel Wagner2-7/+0
Commit ee63cfa7fc19 ("block: add kblockd_schedule_work_on()") introduced the helper in 2016. Remove it because since then no caller was added. Cc: Jens Axboe <[email protected]> Signed-off-by: Daniel Wagner <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-03-02ASoC: rt1015: add operation callback function for rt1015_dai[]Jack Yu1-0/+1
Add operation callback function for rt1015_dai[]. Signed-off-by: Jack Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-03-02Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds8-9/+52
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "Misc fixes: a pkeys fix for a bug that triggers with weird BIOS settings, and two Xen PV fixes: a paravirt interface fix, and pagetable dumping fix" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mm: Fix dump_pagetables with Xen PV x86/ioperm: Add new paravirt function update_io_bitmap() x86/pkeys: Manually set X86_FEATURE_OSPKE to preserve existing changes
2020-03-02Merge branch 'sched-urgent-for-linus' of ↵Linus Torvalds1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fix from Ingo Molnar: "Fix a scheduler statistics bug" * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Fix statistics for find_idlest_group()
2020-03-02Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds25-214/+251
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "No kernel side changes, all tooling fixes plus two tooling cleanups that were committed late in the merge window alongside the perf annotate fixes, delayed by Arnaldo's European trip" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits) perf annotate: Fix segfault with source toggle perf annotate: Align struct annotate_args perf annotate: Simplify disasm_line allocation and freeing code perf annotate: Remove privsize from symbol__annotate() args perf probe: Check return value of strlist__add() for -ENOMEM perf config: Document missing config options perf annotate: Fix perf config option description perf annotate: Prefer cmdline option over default config perf annotate: Make perf config effective perf config: Introduce perf_config_u8() perf annotate: Fix --show-nr-samples for tui/stdio2 perf annotate: Fix --show-total-period for tui/stdio2 perf annotate/tui: Re-render title bar after switching back from script browser tools headers UAPI: Update tools's copy of kvm.h headers tools arch x86: Sync the msr-index.h copy with the kernel sources perf arch powerpc: Sync powerpc syscall.tbl with the kernel sources perf auxtrace: Add auxtrace_record__read_finish() perf arm-spe: Fix endless record after being terminated perf cs-etm: Fix endless record after being terminated perf intel-bts: Fix endless record after being terminated ...
2020-03-02Merge branch 'efi-urgent-for-linus' of ↵Linus Torvalds2-101/+54
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fixes from Ingo Molnar: "Three fixes to EFI mixed boot mode, mostly related to x86-64 vmap stacks activated years ago, bug-fixed recently for EFI, which had knock-on effects of various 1:1 mapping assumptions in mixed mode. There's also a READ_ONCE() fix for reading an mmap-ed EFI firmware data field only once, out of caution" * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: READ_ONCE rng seed size before munmap efi/x86: Handle by-ref arguments covering multiple pages in mixed mode efi/x86: Remove support for EFI time and counter services in mixed mode efi/x86: Align GUIDs to their size in the mixed mode runtime wrapper
2020-03-02arm64: context: Fix ASID limit in boot messagesJean-Philippe Brucker1-5/+15
Since commit f88f42f853a8 ("arm64: context: Free up kernel ASIDs if KPTI is not in use"), the NUM_USER_ASIDS macro doesn't correspond to the effective number of ASIDs when KPTI is enabled. Get an accurate number of available ASIDs in an arch_initcall, once we've discovered all CPUs' capabilities and know if we still need to halve the ASID space for KPTI. Fixes: f88f42f853a8 ("arm64: context: Free up kernel ASIDs if KPTI is not in use") Reviewed-by: Vladimir Murzin <[email protected]> Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-03-02drivers/perf: arm_pmu_acpi: Fix incorrect checking of gicc pointerluanshi1-5/+2
Fix bogus NULL checks on the return value of acpi_cpu_get_madt_gicc() by checking for a 0 'gicc->performance_interrupt' value instead. Signed-off-by: Liguang Zhang <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-03-02drivers/perf: fsl_imx8_ddr: Correct the CLEAR bit definitionJoakim Zhang1-4/+6
When disabling a counter from ddr_perf_event_stop(), the counter value is reset to 0 at the same time. Preserve the counter value by performing a read-modify-write of the PMU register and clearing only the enable bit. Signed-off-by: Joakim Zhang <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-03-02drm/i915/selftests: Fix return in assert_mmap_offset()Dan Carpenter1-1/+1
The assert_mmap_offset() returns type bool so if we return an error pointer that is "return true;" or success. If we have an error, then we should return false. Fixes: 3d81d589d6e3 ("drm/i915: Test exhaustion of the mmap space") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit efbf928824820f2738f41271934f6ec2c6ebd587) Signed-off-by: Jani Nikula <[email protected]>
2020-03-02drm/i915: Protect i915_request_await_start from early waitsChris Wilson1-13/+28
We need to be extremely careful inside i915_request_await_start() as it needs to walk the list of requests in the foreign timeline with very little protection. As we hold our own timeline mutex, we can not nest inside the signaler's timeline mutex, so all that remains is our RCU protection. However, to be safe we need to tell the compiler that we may be traversing the list only under RCU protection, and furthermore we need to start declaring requests as elements of the timeline from their construction. Fixes: 9ddc8ec027a3 ("drm/i915: Eliminate the trylock for awaiting an earlier request") Fixes: 6a79d848403d ("drm/i915: Lock signaler timeline while navigating") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit d22d2d073ef859b346bc32cb25299262e3973769) Signed-off-by: Jani Nikula <[email protected]>
2020-03-02drm/i915/tgl: Add Wa_1608008084Lucas De Marchi1-12/+7
Wa_1608008084 is an additional WA that applies to writes on FF_MODE2 register. We can't read it back either from CPU or GPU. Since the other bits should be 0, recommendation to handle Wa_1604555607 is to actually just write the timer value. Do a write only and don't try to read it, neither before or after the WA is applied. Fixes: ff690b2111ba ("drm/i915/tgl: Implement Wa_1604555607") Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit e94bda14325ccf1a519ffb516738d1201457f97f) Signed-off-by: Jani Nikula <[email protected]>
2020-03-02drm/i915/tgl: Add Wa_22010178259:tglMatt Roper2-0/+14
We need to explicitly set the TLB Request Timer initial value in the BW_BUDDY registers to 0x8 rather than relying on the hardware default. v2: Apply missing REG_FIELD_PREP to ensure 0x8 is placed in the correct bits during the rmw. (Jose) Bspec: 52890 Bspec: 50044 Fixes: 3fa01d642fa7 ("drm/i915/tgl: Program BW_BUDDY registers during display init") Cc: Stanislav Lisovskiy <[email protected]> Cc: José Roberto de Souza <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]> (cherry picked from commit 87e04f75928bb5d357ef7df4eedc1a7e2761a833) Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-02drm/i915: Program MBUS with rmw during initializationMatt Roper1-5/+11
It wasn't terribly clear from the bspec's wording, but after discussion with the hardware folks, it turns out that we need to preserve the pre-existing contents of the MBUS ABOX control register when initializing a few specific bits. Bspec: 49213 Bspec: 50096 Fixes: 4cb4585e5a7f ("drm/i915/icl: initialize MBus during display init") Cc: Stanislav Lisovskiy <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matt Atwood <[email protected]> (cherry picked from commit 837b63e6087838d0f1e612d448405419199d8033) Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-02drm/i915/psr: Force PSR probe only after full initializationJosé Roberto de Souza4-5/+26
Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase once to enable PSR") was forcing the state compute too earlier causing errors because not everything was initialized, so here moving to the end of i915_driver_modeset_probe() when the display is all initialized. Also fixing the place where it disarm the force probe as during the atomic check phase errors could happen like the ones due locking and it would cause PSR to never be enabled if that happens. Leaving the disarm to the atomic commit phase, intel_psr_enable() or intel_psr_update() will be called even if the current state do not allow PSR to be enabled. v2: Check if intel_dp is null in intel_psr_force_mode_changed_set() v3: Check intel_dp before get dev_priv v4: - renamed intel_psr_force_mode_changed_set() to intel_psr_set_force_mode_changed() - removed the set parameter from intel_psr_set_force_mode_changed() - not calling intel_psr_set_force_mode_changed() from intel_psr_enable/update(), directly setting it after the same checks that intel_psr_set_force_mode_changed() does - moved intel_psr_set_force_mode_changed() arm call to i915_driver_modeset_probe() as it is a better for a PSR call, all the functions calls happening between the old and the new function call will cause issue [backported to v5.6-rc3] Fixes: 60c6a14b489b ("drm/i915/display: Force the state compute phase once to enable PSR") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151 Tested-by: Ross Zwisler <[email protected]> Reported-by: Ross Zwisler <[email protected]> Cc: Gwan-gyeong Mun <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Anshuman Gupta <[email protected]> Reviewed-by: Gwan-gyeong Mun <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit df1a5bfc16f3275a74f77d73375e69bc62c45c4b) Signed-off-by: Jani Nikula <[email protected]>
2020-03-02drm/i915/gem: Break up long lists of object reclaimChris Wilson1-0/+1
Call cond_resched() between each freed object in case we have a really, really long list, and we don't want to block normal processes. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit deeee411a97559096523f97655ff16da34cf0573) Signed-off-by: Jani Nikula <[email protected]>
2020-03-02drm/shmem: drop pgprot_decrypted()Gerd Hoffmann1-1/+0
Was added by commit 95cf9264d5f3 ("x86, drm, fbdev: Do not specify encrypted memory for video mappings"), then it was kept through various changes. While vram actually needs decrypted mappings this is not correct for shmem gem objects which live in main memory not io memory, so remove the call. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-02drm/exynos: hdmi: don't leak enable HDMI_EN regulator if probe failsMarek Szyprowski1-10/+12
Move enabling and disabling HDMI_EN optional regulator to probe() function to keep track on the regulator status. This fixes following warning if probe() fails (for example when I2C DDC adapter cannot be yet gathered due to the missing driver). This fixes following warning observed on Arndale5250 board with multi_v7_defconfig: [drm] Failed to get ddc i2c adapter by node ------------[ cut here ]------------ WARNING: CPU: 0 PID: 214 at drivers/regulator/core.c:2051 _regulator_put+0x16c/0x184 Modules linked in: ... CPU: 0 PID: 214 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200219-00040-g38af1dfafdbb #7570 Hardware name: Samsung Exynos (Flattened Device Tree) [<c0312258>] (unwind_backtrace) from [<c030cc10>] (show_stack+0x10/0x14) [<c030cc10>] (show_stack) from [<c0f0d3a0>] (dump_stack+0xcc/0xe0) [<c0f0d3a0>] (dump_stack) from [<c0346a58>] (__warn+0xe0/0xf8) [<c0346a58>] (__warn) from [<c0346b20>] (warn_slowpath_fmt+0xb0/0xb8) [<c0346b20>] (warn_slowpath_fmt) from [<c0893f58>] (_regulator_put+0x16c/0x184) [<c0893f58>] (_regulator_put) from [<c0893f8c>] (regulator_put+0x1c/0x2c) [<c0893f8c>] (regulator_put) from [<c09b2664>] (release_nodes+0x17c/0x200) [<c09b2664>] (release_nodes) from [<c09aebe8>] (really_probe+0x10c/0x350) [<c09aebe8>] (really_probe) from [<c09aefa8>] (driver_probe_device+0x60/0x1a0) [<c09aefa8>] (driver_probe_device) from [<c09af288>] (device_driver_attach+0x58/0x60) [<c09af288>] (device_driver_attach) from [<c09af310>] (__driver_attach+0x80/0xbc) [<c09af310>] (__driver_attach) from [<c09ace34>] (bus_for_each_dev+0x68/0xb4) [<c09ace34>] (bus_for_each_dev) from [<c09ae00c>] (bus_add_driver+0x130/0x1e8) [<c09ae00c>] (bus_add_driver) from [<c09afd98>] (driver_register+0x78/0x110) [<c09afd98>] (driver_register) from [<bf139558>] (exynos_drm_init+0xe8/0x11c [exynosdrm]) [<bf139558>] (exynos_drm_init [exynosdrm]) from [<c0302fa8>] (do_one_initcall+0x50/0x220) [<c0302fa8>] (do_one_initcall) from [<c03dc02c>] (do_init_module+0x60/0x210) [<c03dc02c>] (do_init_module) from [<c03daf44>] (load_module+0x1c0c/0x2310) [<c03daf44>] (load_module) from [<c03db85c>] (sys_finit_module+0xac/0xbc) [<c03db85c>] (sys_finit_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54) Exception stack(0xecca3fa8 to 0xecca3ff0) ... ---[ end trace 276c91214635905c ]--- Signed-off-by: Marek Szyprowski <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2020-03-02drm/exynos: dsi: fix workaround for the legacy clock nameMarek Szyprowski1-3/+4
Writing to the built-in strings arrays doesn't work if driver is loaded as kernel module. This is also considered as a bad pattern. Fix this by adding a call to clk_get() with legacy clock name. This fixes following kernel oops if driver is loaded as module: Unable to handle kernel paging request at virtual address bf047978 pgd = (ptrval) [bf047978] *pgd=59344811, *pte=5903c6df, *ppte=5903c65f Internal error: Oops: 80f [#1] SMP ARM Modules linked in: mc exynosdrm(+) analogix_dp rtc_s3c exynos_ppmu i2c_gpio CPU: 1 PID: 212 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200219 #326 videodev: Linux video capture interface: v2.00 Hardware name: Samsung Exynos (Flattened Device Tree) PC is at exynos_dsi_probe+0x1f0/0x384 [exynosdrm] LR is at exynos_dsi_probe+0x1dc/0x384 [exynosdrm] ... Process systemd-udevd (pid: 212, stack limit = 0x(ptrval)) ... [<bf03cf14>] (exynos_dsi_probe [exynosdrm]) from [<c09b1ca0>] (platform_drv_probe+0x6c/0xa4) [<c09b1ca0>] (platform_drv_probe) from [<c09afcb8>] (really_probe+0x210/0x350) [<c09afcb8>] (really_probe) from [<c09aff74>] (driver_probe_device+0x60/0x1a0) [<c09aff74>] (driver_probe_device) from [<c09b0254>] (device_driver_attach+0x58/0x60) [<c09b0254>] (device_driver_attach) from [<c09b02dc>] (__driver_attach+0x80/0xbc) [<c09b02dc>] (__driver_attach) from [<c09ade00>] (bus_for_each_dev+0x68/0xb4) [<c09ade00>] (bus_for_each_dev) from [<c09aefd8>] (bus_add_driver+0x130/0x1e8) [<c09aefd8>] (bus_add_driver) from [<c09b0d64>] (driver_register+0x78/0x110) [<c09b0d64>] (driver_register) from [<bf038558>] (exynos_drm_init+0xe8/0x11c [exynosdrm]) [<bf038558>] (exynos_drm_init [exynosdrm]) from [<c0302fa8>] (do_one_initcall+0x50/0x220) [<c0302fa8>] (do_one_initcall) from [<c03dd02c>] (do_init_module+0x60/0x210) [<c03dd02c>] (do_init_module) from [<c03dbf44>] (load_module+0x1c0c/0x2310) [<c03dbf44>] (load_module) from [<c03dc85c>] (sys_finit_module+0xac/0xbc) [<c03dc85c>] (sys_finit_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54) Exception stack(0xd979bfa8 to 0xd979bff0) ... ---[ end trace db16efe05faab470 ]--- Signed-off-by: Marek Szyprowski <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2020-03-02drm/exynos: dsi: propagate error value and silence meaningless warningMarek Szyprowski1-2/+3
Properly propagate error value from devm_regulator_bulk_get() and don't confuse user with meaningless warning about failure in getting regulators in case of deferred probe. Signed-off-by: Marek Szyprowski <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2020-03-01Linux 5.6-rc4Linus Torvalds1-1/+1
2020-03-01Merge tag 'ext4_for_linus_stable' of ↵Linus Torvalds2-7/+7
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull ext4 fixes from Ted Ts'o: "Two more bug fixes (including a regression) for 5.6" * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: potential crash on allocation error in ext4_alloc_flex_bg_array() jbd2: fix data races at struct journal_head
2020-03-01Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds22-107/+171
Pull KVM fixes from Paolo Bonzini: "More bugfixes, including a few remaining "make W=1" issues such as too large frame sizes on some configurations. On the ARM side, the compiler was messing up shadow stacks between EL1 and EL2 code, which is easily fixed with __always_inline" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: VMX: check descriptor table exits on instruction emulation kvm: x86: Limit the number of "kvm: disabled by bios" messages KVM: x86: avoid useless copy of cpufreq policy KVM: allow disabling -Werror KVM: x86: allow compiling as non-module with W=1 KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis KVM: Introduce pv check helpers KVM: let declaration of kvm_get_running_vcpus match implementation KVM: SVM: allocate AVIC data structures based on kvm_amd module parameter arm64: Ask the compiler to __always_inline functions used by KVM at HYP KVM: arm64: Define our own swab32() to avoid a uapi static inline KVM: arm64: Ask the compiler to __always_inline functions used at HYP kvm: arm/arm64: Fold VHE entry/exit work into kvm_vcpu_run_vhe() KVM: arm/arm64: Fix up includes for trace.h
2020-03-01KVM: VMX: check descriptor table exits on instruction emulationOliver Upton1-0/+15
KVM emulates UMIP on hardware that doesn't support it by setting the 'descriptor table exiting' VM-execution control and performing instruction emulation. When running nested, this emulation is broken as KVM refuses to emulate L2 instructions by default. Correct this regression by allowing the emulation of descriptor table instructions if L1 hasn't requested 'descriptor table exiting'. Fixes: 07721feee46b ("KVM: nVMX: Don't emulate instructions in guest mode") Reported-by: Jan Kiszka <[email protected]> Cc: [email protected] Cc: Paolo Bonzini <[email protected]> Cc: Jim Mattson <[email protected]> Signed-off-by: Oliver Upton <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-01arm64: dts: meson: fix gxm-khadas-vim2 wifiChristian Hewitt1-1/+1
before [6.418252] brcmfmac: F1 signature read @0x18000000=0x17224356 [6.435663] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2 [6.551259] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed [6.551275] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x00184000 [6.551352] brcmfmac: brcmf_sdio_download_firmware: dongle image file download failed after [6.657165] brcmfmac: F1 signature read @0x18000000=0x17224356 [6.660807] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2 [6.918643] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2 [6.918734] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [6.922724] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4356/2 wl0: Jun 16 2015 14:25:06 version 7.35.184.r1 (TOB) (r559293) FWID 01-b22ae69c Fixes: adc52bf7ef16 ("arm64: dts: meson: fix mmc v2 chips max frequencies") Suggested-by: Art Nikpal <[email protected]> Signed-off-by: Christian Hewitt <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-02-29Merge branch 'i2c/for-current-fixed' of ↵Linus Torvalds3-56/+34
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "I2C has three driver bugfixes for you. We agreed on the Mac regression to go in via I2C" * 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: macintosh: therm_windtunnel: fix regression when instantiating devices i2c: altera: Fix potential integer overflow i2c: jz4780: silence log flood on txabrt
2020-02-29ext4: potential crash on allocation error in ext4_alloc_flex_bg_array()Dan Carpenter1-3/+3
If sbi->s_flex_groups_allocated is zero and the first allocation fails then this code will crash. The problem is that "i--" will set "i" to -1 but when we compare "i >= sbi->s_flex_groups_allocated" then the -1 is type promoted to unsigned and becomes UINT_MAX. Since UINT_MAX is more than zero, the condition is true so we call kvfree(new_groups[-1]). The loop will carry on freeing invalid memory until it crashes. Fixes: 7c990728b99e ("ext4: fix potential race between s_flex_groups online resizing and access") Reviewed-by: Suraj Jitindar Singh <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2020-02-29macintosh: therm_windtunnel: fix regression when instantiating devicesWolfram Sang1-21/+31
Removing attach_adapter from this driver caused a regression for at least some machines. Those machines had the sensors described in their DT, too, so they didn't need manual creation of the sensor devices. The old code worked, though, because manual creation came first. Creation of DT devices then failed later and caused error logs, but the sensors worked nonetheless because of the manually created devices. When removing attach_adaper, manual creation now comes later and loses the race. The sensor devices were already registered via DT, yet with another binding, so the driver could not be bound to it. This fix refactors the code to remove the race and only manually creates devices if there are no DT nodes present. Also, the DT binding is updated to match both, the DT and manually created devices. Because we don't know which device creation will be used at runtime, the code to start the kthread is moved to do_probe() which will be called by both methods. Fixes: 3e7bed52719d ("macintosh: therm_windtunnel: drop using attach_adapter") Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723 Reported-by: Erhard Furtner <[email protected]> Tested-by: Erhard Furtner <[email protected]> Acked-by: Michael Ellerman <[email protected]> (powerpc) Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected] # v4.19+
2020-02-29Merge tag 'arm-soc/for-5.6/devicetree-fixes' of ↵Olof Johansson3-0/+7
https://github.com/Broadcom/stblinux into arm/fixes This pull request contains Broadcom ARM-based SoCs Device Tree fixes for 5.6, please pull the following: - Stefan adds missing Device Tree properties for the Raspberry Pi 3B and 4 LEDs to have proper default configuration - Nicolas adds an alias for the PCIe root complex node that is looked up by the Raspberry Pi firmware for patching in specific properties * tag 'arm-soc/for-5.6/devicetree-fixes' of https://github.com/Broadcom/stblinux: ARM: dts: bcm2711: Add pcie0 alias ARM: dts: bcm283x: Add missing properties to the PWR LED Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Olof Johansson <[email protected]>
2020-02-29Merge tag 'omap-for-v5.6/fixes-rc3-signed' of ↵Olof Johansson9-19/+20
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes Few fixes for omaps for v5.6-rc cycle This series of changes contains few code fixes for issues recently discovered: - A build fix for ARMv6 only configs when CONFIG_HAVE_ARM_SMCCC is not set - A fix for ti-sysc quirk handling for 1-wire hdq reset And a handful of dts fixes that I had queued up and should have already sent earlier instead of waiting for the code fixes to get sorted out: - Fix naming of vsys_3v3 regulator for dra7-evm - Fix incorrect OPP node names for am437x-idk-evm - Fix IPU1 mux clock parent source for dra7 - Add missing PWM property for dra7 timers 13 to 16 - Add missing dma-ranges for dra7 PCIe nodes - Fix mmc3 max-frequency for dra76x * tag 'omap-for-v5.6/fixes-rc3-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2+: Fix compile if CONFIG_HAVE_ARM_SMCCC is not set arm: dts: dra76x: Fix mmc3 max-frequency ARM: dts: dra7: Add "dma-ranges" property to PCIe RC DT nodes bus: ti-sysc: Fix 1-wire reset quirk ARM: dts: dra7-l4: mark timer13-16 as pwm capable ARM: dts: dra7xx-clocks: Fixup IPU1 mux clock parent source ARM: dts: am437x-idk-evm: Fix incorrect OPP node names ARM: dts: dra7-evm: Rename evm_3v3 regulator to vsys_3v3 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Olof Johansson <[email protected]>
2020-02-29jbd2: fix data races at struct journal_headQian Cai1-4/+4
journal_head::b_transaction and journal_head::b_next_transaction could be accessed concurrently as noticed by KCSAN, LTP: starting fsync04 /dev/zero: Can't open blockdev EXT4-fs (loop0): mounting ext3 file system using the ext4 subsystem EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null) ================================================================== BUG: KCSAN: data-race in __jbd2_journal_refile_buffer [jbd2] / jbd2_write_access_granted [jbd2] write to 0xffff99f9b1bd0e30 of 8 bytes by task 25721 on cpu 70: __jbd2_journal_refile_buffer+0xdd/0x210 [jbd2] __jbd2_journal_refile_buffer at fs/jbd2/transaction.c:2569 jbd2_journal_commit_transaction+0x2d15/0x3f20 [jbd2] (inlined by) jbd2_journal_commit_transaction at fs/jbd2/commit.c:1034 kjournald2+0x13b/0x450 [jbd2] kthread+0x1cd/0x1f0 ret_from_fork+0x27/0x50 read to 0xffff99f9b1bd0e30 of 8 bytes by task 25724 on cpu 68: jbd2_write_access_granted+0x1b2/0x250 [jbd2] jbd2_write_access_granted at fs/jbd2/transaction.c:1155 jbd2_journal_get_write_access+0x2c/0x60 [jbd2] __ext4_journal_get_write_access+0x50/0x90 [ext4] ext4_mb_mark_diskspace_used+0x158/0x620 [ext4] ext4_mb_new_blocks+0x54f/0xca0 [ext4] ext4_ind_map_blocks+0xc79/0x1b40 [ext4] ext4_map_blocks+0x3b4/0x950 [ext4] _ext4_get_block+0xfc/0x270 [ext4] ext4_get_block+0x3b/0x50 [ext4] __block_write_begin_int+0x22e/0xae0 __block_write_begin+0x39/0x50 ext4_write_begin+0x388/0xb50 [ext4] generic_perform_write+0x15d/0x290 ext4_buffered_write_iter+0x11f/0x210 [ext4] ext4_file_write_iter+0xce/0x9e0 [ext4] new_sync_write+0x29c/0x3b0 __vfs_write+0x92/0xa0 vfs_write+0x103/0x260 ksys_write+0x9d/0x130 __x64_sys_write+0x4c/0x60 do_syscall_64+0x91/0xb05 entry_SYSCALL_64_after_hwframe+0x49/0xbe 5 locks held by fsync04/25724: #0: ffff99f9911093f8 (sb_writers#13){.+.+}, at: vfs_write+0x21c/0x260 #1: ffff99f9db4c0348 (&sb->s_type->i_mutex_key#15){+.+.}, at: ext4_buffered_write_iter+0x65/0x210 [ext4] #2: ffff99f5e7dfcf58 (jbd2_handle){++++}, at: start_this_handle+0x1c1/0x9d0 [jbd2] #3: ffff99f9db4c0168 (&ei->i_data_sem){++++}, at: ext4_map_blocks+0x176/0x950 [ext4] #4: ffffffff99086b40 (rcu_read_lock){....}, at: jbd2_write_access_granted+0x4e/0x250 [jbd2] irq event stamp: 1407125 hardirqs last enabled at (1407125): [<ffffffff980da9b7>] __find_get_block+0x107/0x790 hardirqs last disabled at (1407124): [<ffffffff980da8f9>] __find_get_block+0x49/0x790 softirqs last enabled at (1405528): [<ffffffff98a0034c>] __do_softirq+0x34c/0x57c softirqs last disabled at (1405521): [<ffffffff97cc67a2>] irq_exit+0xa2/0xc0 Reported by Kernel Concurrency Sanitizer on: CPU: 68 PID: 25724 Comm: fsync04 Tainted: G L 5.6.0-rc2-next-20200221+ #7 Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019 The plain reads are outside of jh->b_state_lock critical section which result in data races. Fix them by adding pairs of READ|WRITE_ONCE(). Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Qian Cai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2020-02-29arm64: dts: meson-sm1-sei610: add missing interrupt-namesGuillaume La Roque1-0/+1
add missing "host-wakeup interrupt names Fixes: 30388cc07572 ("arm64: dts: meson-sm1-sei610: add gpio bluetooth interrupt") Signed-off-by: Guillaume La Roque <[email protected]> Acked-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kevin Hilman <[email protected]>
2020-02-29ARM: meson: Drop unneeded select of COMMON_CLKGeert Uytterhoeven1-1/+0
Support for Amlogic Meson SoCs depends on ARCH_MULTI_V7, and thus on ARCH_MULTIPLATFORM. As the latter selects COMMON_CLK, there is no need for ARCH_MESON to select COMMON_CLK. Signed-off-by: Geert Uytterhoeven <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: [email protected] Acked-by: Martin Blumenstingl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kevin Hilman <[email protected]>