Skip to main content

Browse the archive

https://github.com/torvalds/linux
05 April 2024, 19:05:47 UTC
sort by:
Revision Author Date Message Commit Date
e21a712 Linus Torvalds 05 August 2019, 01:40:12 UTC Linux 5.3-rc3 05 August 2019, 01:40:12 UTC
a6831a8 Linus Torvalds 04 August 2019, 23:39:07 UTC Merge tag 'tpmdd-next-20190805' of git://git.infradead.org/users/jjs/linux-tpmdd Pull tpm fixes from Jarkko Sakkinen: "Two bug fixes that did not make into my first pull request" * tag 'tpmdd-next-20190805' of git://git.infradead.org/users/jjs/linux-tpmdd: tpm: tpm_ibm_vtpm: Fix unallocated banks tpm: Fix null pointer dereference on chip register error path 04 August 2019, 23:39:07 UTC
62d1716 Linus Torvalds 04 August 2019, 23:37:08 UTC Merge tag 'mtd/fixes-for-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fixes from Miquel Raynal: "NAND: - Fix Micron driver as some chips enable internal ECC correction during their discovery while they advertize they do not have any. Hyperbus: - Restrict the build to only ARM64 SoCs (and compile testing) which is what should have been done since the beginning. - Fix Kconfig issue by selection something instead of implying it" * tag 'mtd/fixes-for-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: hyperbus: Add hardware dependency to AM654 driver mtd: hyperbus: Kconfig: Fix HBMC_AM654 dependencies mtd: rawnand: micron: handle on-die "ECC-off" devices correctly 04 August 2019, 23:37:08 UTC
fa4f99c Nayna Jain 11 July 2019, 16:13:35 UTC tpm: tpm_ibm_vtpm: Fix unallocated banks The nr_allocated_banks and allocated banks are initialized as part of tpm_chip_register. Currently, this is done as part of auto startup function. However, some drivers, like the ibm vtpm driver, do not run auto startup during initialization. This results in uninitialized memory issue and causes a kernel panic during boot. This patch moves the pcr allocation outside the auto startup function into tpm_chip_register. This ensures that allocated banks are initialized in any case. Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with PCR read") Reported-by: Michal Suchanek <msuchanek@suse.de> Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com> Tested-by: Michal Suchánek <msuchanek@suse.de> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> 04 August 2019, 21:55:00 UTC
1e5ac63 Milan Broz 04 July 2019, 07:26:15 UTC tpm: Fix null pointer dereference on chip register error path If clk_enable is not defined and chip initialization is canceled code hits null dereference. Easily reproducible with vTPM init fail: swtpm chardev --tpmstate dir=nonexistent_dir --tpm2 --vtpm-proxy BUG: kernel NULL pointer dereference, address: 00000000 ... Call Trace: tpm_chip_start+0x9d/0xa0 [tpm] tpm_chip_register+0x10/0x1a0 [tpm] vtpm_proxy_work+0x11/0x30 [tpm_vtpm_proxy] process_one_work+0x214/0x5a0 worker_thread+0x134/0x3e0 ? process_one_work+0x5a0/0x5a0 kthread+0xd4/0x100 ? process_one_work+0x5a0/0x5a0 ? kthread_park+0x90/0x90 ret_from_fork+0x19/0x24 Fixes: 719b7d81f204 ("tpm: introduce tpm_chip_start() and tpm_chip_stop()") Cc: stable@vger.kernel.org # v5.1+ Signed-off-by: Milan Broz <gmazyland@gmail.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> 04 August 2019, 21:55:00 UTC
4b6f231 Linus Torvalds 04 August 2019, 17:30:47 UTC Merge tag 'powerpc-5.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: "Some more powerpc fixes for 5.3: - Wire up the new clone3 syscall. - A fix for the PAPR SCM nvdimm driver, to fix a crash when firmware gives us a device that's attached to a non-online NUMA node. - A fix for a boot failure on 32-bit with KASAN enabled. - Three fixes for implicit fall through warnings, some of which are errors for us due to -Werror. Thanks to: Aneesh Kumar K.V, Christophe Leroy, Kees Cook, Santosh Sivaraj, Stephen Rothwell" * tag 'powerpc-5.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/kasan: fix early boot failure on PPC32 drivers/macintosh/smu.c: Mark expected switch fall-through powerpc/spe: Mark expected switch fall-throughs powerpc/nvdimm: Pick nearby online node if the device node is not online powerpc/kvm: Fall through switch case explicitly powerpc: Wire up clone3 syscall 04 August 2019, 17:30:47 UTC
4c0d228 Geert Uytterhoeven 29 July 2019, 17:56:58 UTC MAINTAINERS: Add Geert as Renesas SoC Co-Maintainer At the end of the v5.3 upstream kernel development cycle, Simon will be stepping down from his role as Renesas SoC maintainer. Starting with the v5.4 development cycle, Geert is taking over this role. Add Geert as a co-maintainer, and add his git repository and branch. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 04 August 2019, 17:23:23 UTC
05e4f88 Linus Torvalds 04 August 2019, 17:16:30 UTC Merge tag 'kbuild-fixes-v5.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - detect missing missing "WITH Linux-syscall-note" for uapi headers - fix needless rebuild when using Clang - fix false-positive cc-option in Kconfig when using Clang - avoid including corrupted .*.cmd files in the modpost stage - fix warning of 'make vmlinux' - fix {m,n,x,g}config to not generate the broken .config on the second save operation. - some trivial Makefile fixes * tag 'kbuild-fixes-v5.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kconfig: Clear "written" flag to avoid data loss kbuild: Check for unknown options with cc-option usage in Kconfig and clang lib/raid6: fix unnecessary rebuild of vpermxor*.c kbuild: modpost: do not parse unnecessary rules for vmlinux modpost kbuild: modpost: remove unnecessary dependency for __modpost kbuild: modpost: handle KBUILD_EXTRA_SYMBOLS only for external modules kbuild: modpost: include .*.cmd files only when targets exist kbuild: initialize CLANG_FLAGS correctly in the top Makefile kbuild: detect missing "WITH Linux-syscall-note" for uapi headers 04 August 2019, 17:16:30 UTC
8449c98 Linus Torvalds 04 August 2019, 17:02:13 UTC Merge tag 'safesetid-maintainers-correction-5.3-rc2' of git://github.com/micah-morton/linux Pull SafeSetID maintainer update from Micah Morton: "Add entry in MAINTAINERS file for SafeSetID LSM" * tag 'safesetid-maintainers-correction-5.3-rc2' of git://github.com/micah-morton/linux: Add entry in MAINTAINERS file for SafeSetID LSM 04 August 2019, 17:02:13 UTC
0c5b6c2 M. Vefa Bicakci 03 August 2019, 10:02:12 UTC kconfig: Clear "written" flag to avoid data loss Prior to this commit, starting nconfig, xconfig or gconfig, and saving the .config file more than once caused data loss, where a .config file that contained only comments would be written to disk starting from the second save operation. This bug manifests itself because the SYMBOL_WRITTEN flag is never cleared after the first call to conf_write, and subsequent calls to conf_write then skip all of the configuration symbols due to the SYMBOL_WRITTEN flag being set. This commit resolves this issue by clearing the SYMBOL_WRITTEN flag from all symbols before conf_write returns. Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf") Cc: linux-stable <stable@vger.kernel.org> # 4.19+ Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> 04 August 2019, 03:44:15 UTC
d8778f1 Linus Torvalds 04 August 2019, 01:50:52 UTC Merge tag 'xtensa-20190803' of git://github.com/jcmvbkbc/linux-xtensa Pull Xtensa fix from Max Filippov: "Fix build for xtensa cores with coprocessors that was broken by entry/return abstraction patch" * tag 'xtensa-20190803' of git://github.com/jcmvbkbc/linux-xtensa: xtensa: fix build for cores with coprocessors 04 August 2019, 01:50:52 UTC
cf6c8ae Linus Torvalds 03 August 2019, 19:56:34 UTC Merge branch 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "A set of driver fixes for the I2C subsystem" * 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: s3c2410: Mark expected switch fall-through i2c: at91: fix clk_offset for sama5d2 i2c: at91: disable TXRDY interrupt after sending data i2c: iproc: Fix i2c master read more than 63 bytes eeprom: at24: make spd world-readable again 03 August 2019, 19:56:34 UTC
8b7fd67 Linus Torvalds 03 August 2019, 17:58:46 UTC Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf tooling fixes from Thomas Gleixner: "A set of updates for perf tools and documentation: perf header: - Prevent a division by zero - Deal with an uninitialized warning proper libbpf: - Fix the missiong __WORDSIZE definition for musl & al UAPI headers: - Synchronize kernel headers Documentation: - Fix the memory units for perf.data size" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: libbpf: fix missing __WORDSIZE definition perf tools: Fix perf.data documentation units for memory size perf header: Fix use of unitialized value warning perf header: Fix divide by zero error if f_header.attr_size==0 tools headers UAPI: Sync if_link.h with the kernel tools headers UAPI: Sync sched.h with the kernel tools headers UAPI: Sync usbdevice_fs.h with the kernels to get new ioctl tools perf beauty: Fix usbdevfs_ioctl table generator to handle _IOC() tools headers UAPI: Update tools's copy of drm.h headers tools headers UAPI: Update tools's copy of mman.h headers tools headers UAPI: Update tools's copy of kvm.h headers tools include UAPI: Sync x86's syscalls_64.tbl and generic unistd.h to pick up clone3 and pidfd_open 03 August 2019, 17:58:46 UTC
0432a0a Linus Torvalds 03 August 2019, 17:51:29 UTC Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull vdso timer fixes from Thomas Gleixner: "A series of commits to deal with the regression caused by the generic VDSO implementation. The usage of clock_gettime64() for 32bit compat fallback syscalls caused seccomp filters to kill innocent processes because they only allow clock_gettime(). Handle the compat syscalls with clock_gettime() as before, which is not a functional problem for the VDSO as the legacy compat application interface is not y2038 safe anyway. It's just extra fallback code which needs to be implemented on every architecture. It's opt in for now so that it does not break the compile of already converted architectures in linux-next. Once these are fixed, the #ifdeffery goes away. So much for trying to be smart and reuse code..." * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: arm64: compat: vdso: Use legacy syscalls as fallback x86/vdso/32: Use 32bit syscall fallback lib/vdso/32: Provide legacy syscall fallbacks lib/vdso: Move fallback invocation to the callers lib/vdso/32: Remove inconsistent NULL pointer checks 03 August 2019, 17:51:29 UTC
af42e74 Linus Torvalds 03 August 2019, 17:49:45 UTC Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Thomas Gleixner: "A small bunch of fixes from the irqchip department: - Fix a couple of UAF on error paths (RZA1, GICv3 ITS) - Fix iMX GPCv2 trigger setting - Add missing of_node_put() on error path in MBIGEN - Add another bunch of /* fall-through */ to silence warnings" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/renesas-rza1: Fix an use-after-free in rza1_irqc_probe() irqchip/irq-imx-gpcv2: Forward irq type to parent irqchip/irq-mbigen: Add of_node_put() before return irqchip/gic-v3-its: Free unused vpt_page when alloc vpe table fail irqchip/gic-v3: Mark expected switch fall-through 03 August 2019, 17:49:45 UTC
e12b243 Linus Torvalds 03 August 2019, 17:43:44 UTC Merge tag 'xfs-5.3-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux Pull xfs fixes from Darrick Wong: - Avoid leaking kernel stack contents to userspace - Fix a potential null pointer dereference in the dabtree scrub code * tag 'xfs-5.3-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: Fix possible null-pointer dereferences in xchk_da_btree_block_check_sibling() xfs: fix stack contents leakage in the v1 inumber ioctls 03 August 2019, 17:43:44 UTC
b7aea68 Linus Torvalds 03 August 2019, 16:20:49 UTC Merge branch 'akpm' (patches from Andrew) Merge misc fixes from Andrew Morton: "17 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: drivers/acpi/scan.c: document why we don't need the device_hotplug_lock memremap: move from kernel/ to mm/ lib/test_meminit.c: use GFP_ATOMIC in RCU critical section asm-generic: fix -Wtype-limits compiler warnings cgroup: kselftest: relax fs_spec checks mm/memory_hotplug.c: remove unneeded return for void function mm/migrate.c: initialize pud_entry in migrate_vma() coredump: split pipe command whitespace before expanding template page flags: prioritize kasan bits over last-cpuid ubsan: build ubsan.c more conservatively kasan: remove clang version check for KASAN_STACK mm: compaction: avoid 100% CPU usage during compaction when a task is killed mm: migrate: fix reference check race between __find_get_block() and migration mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker ocfs2: remove set but not used variable 'last_hash' Revert "kmemleak: allow to coexist with fault injection" kernel/signal.c: fix a kernel-doc markup 03 August 2019, 16:20:49 UTC
6167254 Linus Torvalds 03 August 2019, 15:59:11 UTC Merge tag 'riscv/for-v5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: "Three minor RISC-V-related changes for v5.3-rc3: - Add build ID to VDSO builds to avoid a double-free in perf when libelf isn't used - Align the RV64 defconfig to the output of "make savedefconfig" so subsequent defconfig patches don't get out of hand - Drop a superfluous DT property from the FU540 SoC DT data (since it must be already set in board data that includes it)" * tag 'riscv/for-v5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: defconfig: align RV64 defconfig to the output of "make savedefconfig" riscv: dts: fu540-c000: drop "timebase-frequency" riscv: Fix perf record without libelf support 03 August 2019, 15:59:11 UTC
7291edc David Hildenbrand 03 August 2019, 04:49:29 UTC drivers/acpi/scan.c: document why we don't need the device_hotplug_lock Let's document why the lock is not needed in acpi_scan_init(), right now this is not really obvious. [akpm@linux-foundation.org: fix tpyo] Link: http://lkml.kernel.org/r/20190731135306.31524-1-david@redhat.com Signed-off-by: David Hildenbrand <david@redhat.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Oscar Salvador <osalvador@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:01 UTC
14c5ceb Christoph Hellwig 03 August 2019, 04:49:26 UTC memremap: move from kernel/ to mm/ memremap.c implements MM functionality for ZONE_DEVICE, so it really should be in the mm/ directory, not the kernel/ one. Link: http://lkml.kernel.org/r/20190722094143.18387-1-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:01 UTC
733d1d1 Alexander Potapenko 03 August 2019, 04:49:22 UTC lib/test_meminit.c: use GFP_ATOMIC in RCU critical section kmalloc() shouldn't sleep while in RCU critical section, therefore use GFP_ATOMIC instead of GFP_KERNEL. The bug was spotted by the 0day kernel testing robot. Link: http://lkml.kernel.org/r/20190725121703.210874-1-glider@google.com Fixes: 7e659650cbda ("lib: introduce test_meminit module") Signed-off-by: Alexander Potapenko <glider@google.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:01 UTC
cbedfe1 Qian Cai 03 August 2019, 04:49:19 UTC asm-generic: fix -Wtype-limits compiler warnings Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a compilation warning because "rx_frag_size" is an "ushort" while PAGE_SHIFT here is 16. The commit changed the get_order() to be a multi-line macro where compilers insist to check all statements in the macro even when __builtin_constant_p(rx_frag_size) will return false as "rx_frag_size" is a module parameter. In file included from ./arch/powerpc/include/asm/page_64.h:107, from ./arch/powerpc/include/asm/page.h:242, from ./arch/powerpc/include/asm/mmu.h:132, from ./arch/powerpc/include/asm/lppaca.h:47, from ./arch/powerpc/include/asm/paca.h:17, from ./arch/powerpc/include/asm/current.h:13, from ./include/linux/thread_info.h:21, from ./arch/powerpc/include/asm/processor.h:39, from ./include/linux/prefetch.h:15, from drivers/net/ethernet/emulex/benet/be_main.c:14: drivers/net/ethernet/emulex/benet/be_main.c: In function 'be_rx_cqs_create': ./include/asm-generic/getorder.h:54:9: warning: comparison is always true due to limited range of data type [-Wtype-limits] (((n) < (1UL << PAGE_SHIFT)) ? 0 : \ ^ drivers/net/ethernet/emulex/benet/be_main.c:3138:33: note: in expansion of macro 'get_order' adapter->big_page_size = (1 << get_order(rx_frag_size)) * PAGE_SIZE; ^~~~~~~~~ Fix it by moving all of this multi-line macro into a proper function, and killing __get_order() off. [akpm@linux-foundation.org: remove __get_order() altogether] [cai@lca.pw: v2] Link: http://lkml.kernel.org/r/1564000166-31428-1-git-send-email-cai@lca.pw Link: http://lkml.kernel.org/r/1563914986-26502-1-git-send-email-cai@lca.pw Fixes: d66acc39c7ce ("bitops: Optimise get_order()") Signed-off-by: Qian Cai <cai@lca.pw> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Cc: David S. Miller <davem@davemloft.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Howells <dhowells@redhat.com> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Bill Wendling <morbo@google.com> Cc: James Y Knight <jyknight@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:01 UTC
b59b1ba Chris Down 03 August 2019, 04:49:15 UTC cgroup: kselftest: relax fs_spec checks On my laptop most memcg kselftests were being skipped because it claimed cgroup v2 hierarchy wasn't mounted, but this isn't correct. Instead, it seems current systemd HEAD mounts it with the name "cgroup2" instead of "cgroup": % grep cgroup /proc/mounts cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0 I can't think of a reason to need to check fs_spec explicitly since it's arbitrary, so we can just rely on fs_vfstype. After these changes, `make TARGETS=cgroup kselftest` actually runs the cgroup v2 tests in more cases. Link: http://lkml.kernel.org/r/20190723210737.GA487@chrisdown.name Signed-off-by: Chris Down <chris@chrisdown.name> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Tejun Heo <tj@kernel.org> Cc: Roman Gushchin <guro@fb.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:01 UTC
aa4996b Weitao Hou 03 August 2019, 04:49:12 UTC mm/memory_hotplug.c: remove unneeded return for void function return is unneeded in void function Link: http://lkml.kernel.org/r/20190723130814.21826-1-houweitaoo@gmail.com Signed-off-by: Weitao Hou <houweitaoo@gmail.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Oscar Salvador <osalvador@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:01 UTC
7b358c6 Ralph Campbell 03 August 2019, 04:49:08 UTC mm/migrate.c: initialize pud_entry in migrate_vma() When CONFIG_MIGRATE_VMA_HELPER is enabled, migrate_vma() calls migrate_vma_collect() which initializes a struct mm_walk but didn't initialize mm_walk.pud_entry. (Found by code inspection) Use a C structure initialization to make sure it is set to NULL. Link: http://lkml.kernel.org/r/20190719233225.12243-1-rcampbell@nvidia.com Fixes: 8763cb45ab967 ("mm/migrate: new memory migration helper for use with device memory") Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: "Jérôme Glisse" <jglisse@redhat.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:01 UTC
315c692 Paul Wise 03 August 2019, 04:49:05 UTC coredump: split pipe command whitespace before expanding template Save the offsets of the start of each argument to avoid having to update pointers to each argument after every corename krealloc and to avoid having to duplicate the memory for the dump command. Executable names containing spaces were previously being expanded from %e or %E and then split in the middle of the filename. This is incorrect behaviour since an argument list can represent arguments with spaces. The splitting could lead to extra arguments being passed to the core dump handler that it might have interpreted as options or ignored completely. Core dump handlers that are not aware of this Linux kernel issue will be using %e or %E without considering that it may be split and so they will be vulnerable to processes with spaces in their names breaking their argument list. If their internals are otherwise well written, such as if they are written in shell but quote arguments, they will work better after this change than before. If they are not well written, then there is a slight chance of breakage depending on the details of the code but they will already be fairly broken by the split filenames. Core dump handlers that are aware of this Linux kernel issue will be placing %e or %E as the last item in their core_pattern and then aggregating all of the remaining arguments into one, separated by spaces. Alternatively they will be obtaining the filename via other methods. Both of these will be compatible with the new arrangement. A side effect from this change is that unknown template types (for example %z) result in an empty argument to the dump handler instead of the argument being dropped. This is a desired change as: It is easier for dump handlers to process empty arguments than dropped ones, especially if they are written in shell or don't pass each template item with a preceding command-line option in order to differentiate between individual template types. Most core_patterns in the wild do not use options so they can confuse different template types (especially numeric ones) if an earlier one gets dropped in old kernels. If the kernel introduces a new template type and a core_pattern uses it, the core dump handler might not expect that the argument can be dropped in old kernels. For example, this can result in security issues when %d is dropped in old kernels. This happened with the corekeeper package in Debian and resulted in the interface between corekeeper and Linux having to be rewritten to use command-line options to differentiate between template types. The core_pattern for most core dump handlers is written by the handler author who would generally not insert unknown template types so this change should be compatible with all the core dump handlers that exist. Link: http://lkml.kernel.org/r/20190528051142.24939-1-pabs3@bonedaddy.net Fixes: 74aadce98605 ("core_pattern: allow passing of arguments to user mode helper when core_pattern is a pipe") Signed-off-by: Paul Wise <pabs3@bonedaddy.net> Reported-by: Jakub Wilk <jwilk@jwilk.net> [https://bugs.debian.org/924398] Reported-by: Paul Wise <pabs3@bonedaddy.net> [https://lore.kernel.org/linux-fsdevel/c8b7ecb8508895bf4adb62a748e2ea2c71854597.camel@bonedaddy.net/] Suggested-by: Jakub Wilk <jwilk@jwilk.net> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:01 UTC
ee38d94 Arnd Bergmann 03 August 2019, 04:49:02 UTC page flags: prioritize kasan bits over last-cpuid ARM64 randdconfig builds regularly run into a build error, especially when NUMA_BALANCING and SPARSEMEM are enabled but not SPARSEMEM_VMEMMAP: #error "KASAN: not enough bits in page flags for tag" The last-cpuid bits are already contitional on the available space, so the result of the calculation is a bit random on whether they were already left out or not. Adding the kasan tag bits before last-cpuid makes it much more likely to end up with a successful build here, and should be reliable for randconfig at least, as long as that does not randomize NR_CPUS or NODES_SHIFT but uses the defaults. In order for the modified check to not trigger in the x86 vdso32 code where all constants are wrong (building with -m32), enclose all the definitions with an #ifdef. [arnd@arndb.de: build fix] Link: http://lkml.kernel.org/r/CAK8P3a3Mno1SWTcuAOT0Wa9VS15pdU6EfnkxLbDpyS55yO04+g@mail.gmail.com Link: http://lkml.kernel.org/r/20190722115520.3743282-1-arnd@arndb.de Link: https://lore.kernel.org/lkml/20190618095347.3850490-1-arnd@arndb.de/ Fixes: 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Andrey Konovalov <andreyknvl@google.com> Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Christoph Lameter <cl@linux.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:01 UTC
af700ea Arnd Bergmann 03 August 2019, 04:48:58 UTC ubsan: build ubsan.c more conservatively objtool points out several conditions that it does not like, depending on the combination with other configuration options and compiler variants: stack protector: lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0xbf: call to __stack_chk_fail() with UACCESS enabled lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0xbe: call to __stack_chk_fail() with UACCESS enabled stackleak plugin: lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x4a: call to stackleak_track_stack() with UACCESS enabled lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x4a: call to stackleak_track_stack() with UACCESS enabled kasan: lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x25: call to memcpy() with UACCESS enabled lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x25: call to memcpy() with UACCESS enabled The stackleak and kasan options just need to be disabled for this file as we do for other files already. For the stack protector, we already attempt to disable it, but this fails on clang because the check is mixed with the gcc specific -fno-conserve-stack option. According to Andrey Ryabinin, that option is not even needed, dropping it here fixes the stackprotector issue. Link: http://lkml.kernel.org/r/20190722125139.1335385-1-arnd@arndb.de Link: https://lore.kernel.org/lkml/20190617123109.667090-1-arnd@arndb.de/t/ Link: https://lore.kernel.org/lkml/20190722091050.2188664-1-arnd@arndb.de/t/ Fixes: d08965a27e84 ("x86/uaccess, ubsan: Fix UBSAN vs. SMAP") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:00 UTC
ebb6d35 Arnd Bergmann 03 August 2019, 04:48:54 UTC kasan: remove clang version check for KASAN_STACK asan-stack mode still uses dangerously large kernel stacks of tens of kilobytes in some drivers, and it does not seem that anyone is working on the clang bug. Turn it off for all clang versions to prevent users from accidentally enabling it once they update to clang-9, and to help automated build testing with clang-9. Link: https://bugs.llvm.org/show_bug.cgi?id=38809 Link: http://lkml.kernel.org/r/20190719200347.2596375-1-arnd@arndb.de Fixes: 6baec880d7a5 ("kasan: turn off asan-stack for clang-8 and earlier") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Qian Cai <cai@lca.pw> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:00 UTC
670105a Mel Gorman 03 August 2019, 04:48:51 UTC mm: compaction: avoid 100% CPU usage during compaction when a task is killed "howaboutsynergy" reported via kernel buzilla number 204165 that compact_zone_order was consuming 100% CPU during a stress test for prolonged periods of time. Specifically the following command, which should exit in 10 seconds, was taking an excessive time to finish while the CPU was pegged at 100%. stress -m 220 --vm-bytes 1000000000 --timeout 10 Tracing indicated a pattern as follows stress-3923 [007] 519.106208: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106212: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106216: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106219: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106223: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106227: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106231: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106235: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106238: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106242: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 Note that compaction is entered in rapid succession while scanning and isolating nothing. The problem is that when a task that is compacting receives a fatal signal, it retries indefinitely instead of exiting while making no progress as a fatal signal is pending. It's not easy to trigger this condition although enabling zswap helps on the basis that the timing is altered. A very small window has to be hit for the problem to occur (signal delivered while compacting and isolating a PFN for migration that is not aligned to SWAP_CLUSTER_MAX). This was reproduced locally -- 16G single socket system, 8G swap, 30% zswap configured, vm-bytes 22000000000 using Colin Kings stress-ng implementation from github running in a loop until the problem hits). Tracing recorded the problem occurring almost 200K times in a short window. With this patch, the problem hit 4 times but the task existed normally instead of consuming CPU. This problem has existed for some time but it was made worse by commit cf66f0700c8f ("mm, compaction: do not consider a need to reschedule as contention"). Before that commit, if the same condition was hit then locks would be quickly contended and compaction would exit that way. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204165 Link: http://lkml.kernel.org/r/20190718085708.GE24383@techsingularity.net Fixes: cf66f0700c8f ("mm, compaction: do not consider a need to reschedule as contention") Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> [5.1+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:00 UTC
ebdf4de Jan Kara 03 August 2019, 04:48:47 UTC mm: migrate: fix reference check race between __find_get_block() and migration buffer_migrate_page_norefs() can race with bh users in the following way: CPU1 CPU2 buffer_migrate_page_norefs() buffer_migrate_lock_buffers() checks bh refs spin_unlock(&mapping->private_lock) __find_get_block() spin_lock(&mapping->private_lock) grab bh ref spin_unlock(&mapping->private_lock) move page do bh work This can result in various issues like lost updates to buffers (i.e. metadata corruption) or use after free issues for the old page. This patch closes the race by holding mapping->private_lock while the mapping is being moved to a new page. Ordinarily, a reference can be taken outside of the private_lock using the per-cpu BH LRU but the references are checked and the LRU invalidated if necessary. The private_lock is held once the references are known so the buffer lookup slow path will spin on the private_lock. Between the page lock and private_lock, it should be impossible for other references to be acquired and updates to happen during the migration. A user had reported data corruption issues on a distribution kernel with a similar page migration implementation as mainline. The data corruption could not be reproduced with this patch applied. A small number of migration-intensive tests were run and no performance problems were noted. [mgorman@techsingularity.net: Changelog, removed tracing] Link: http://lkml.kernel.org/r/20190718090238.GF24383@techsingularity.net Fixes: 89cb0888ca14 "mm: migrate: provide buffer_migrate_page_norefs()" Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Cc: <stable@vger.kernel.org> [5.0+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:00 UTC
fa1e512 Yang Shi 03 August 2019, 04:48:44 UTC mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker Shakeel Butt reported premature oom on kernel with "cgroup_disable=memory" since mem_cgroup_is_root() returns false even though memcg is actually NULL. The drop_caches is also broken. It is because commit aeed1d325d42 ("mm/vmscan.c: generalize shrink_slab() calls in shrink_node()") removed the !memcg check before !mem_cgroup_is_root(). And, surprisingly root memcg is allocated even though memory cgroup is disabled by kernel boot parameter. Add mem_cgroup_disabled() check to make reclaimer work as expected. Link: http://lkml.kernel.org/r/1563385526-20805-1-git-send-email-yang.shi@linux.alibaba.com Fixes: aeed1d325d42 ("mm/vmscan.c: generalize shrink_slab() calls in shrink_node()") Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com> Reported-by: Shakeel Butt <shakeelb@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Jan Hadrava <had@kam.mff.cuni.cz> Cc: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Roman Gushchin <guro@fb.com> Cc: Hugh Dickins <hughd@google.com> Cc: Qian Cai <cai@lca.pw> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: <stable@vger.kernel.org> [4.19+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:00 UTC
7bc36e3 YueHaibing 03 August 2019, 04:48:40 UTC ocfs2: remove set but not used variable 'last_hash' Fixes gcc '-Wunused-but-set-variable' warning: fs/ocfs2/xattr.c: In function ocfs2_xattr_bucket_find: fs/ocfs2/xattr.c:3828:6: warning: variable last_hash set but not used [-Wunused-but-set-variable] It's never used and can be removed. Link: http://lkml.kernel.org/r/20190716132110.34836-1-yuehaibing@huawei.com Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:00 UTC
df9576d Yang Shi 03 August 2019, 04:48:37 UTC Revert "kmemleak: allow to coexist with fault injection" When running ltp's oom test with kmemleak enabled, the below warning was triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is passed in: WARNING: CPU: 105 PID: 2138 at mm/page_alloc.c:4608 __alloc_pages_nodemask+0x1c31/0x1d50 Modules linked in: loop dax_pmem dax_pmem_core ip_tables x_tables xfs virtio_net net_failover virtio_blk failover ata_generic virtio_pci virtio_ring virtio libata CPU: 105 PID: 2138 Comm: oom01 Not tainted 5.2.0-next-20190710+ #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:__alloc_pages_nodemask+0x1c31/0x1d50 ... kmemleak_alloc+0x4e/0xb0 kmem_cache_alloc+0x2a7/0x3e0 mempool_alloc_slab+0x2d/0x40 mempool_alloc+0x118/0x2b0 bio_alloc_bioset+0x19d/0x350 get_swap_bio+0x80/0x230 __swap_writepage+0x5ff/0xb20 The mempool_alloc_slab() clears __GFP_DIRECT_RECLAIM, however kmemleak has __GFP_NOFAIL set all the time due to d9570ee3bd1d4f2 ("kmemleak: allow to coexist with fault injection"). But, it doesn't make any sense to have __GFP_NOFAIL and ~__GFP_DIRECT_RECLAIM specified at the same time. According to the discussion on the mailing list, the commit should be reverted for short term solution. Catalin Marinas would follow up with a better solution for longer term. The failure rate of kmemleak metadata allocation may increase in some circumstances, but this should be expected side effect. Link: http://lkml.kernel.org/r/1563299431-111710-1-git-send-email-yang.shi@linux.alibaba.com Fixes: d9570ee3bd1d4f2 ("kmemleak: allow to coexist with fault injection") Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com> Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: David Rientjes <rientjes@google.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Qian Cai <cai@lca.pw> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:00 UTC
68d8681 Mauro Carvalho Chehab 03 August 2019, 04:48:33 UTC kernel/signal.c: fix a kernel-doc markup The kernel-doc parser doesn't handle expressions with %foo*. Instead, when an asterisk should be part of a constant, it uses an alternative notation: `foo*`. Link: http://lkml.kernel.org/r/7f18c2e0b5e39e6b7eb55ddeb043b8b260b49f2d.1563361575.git.mchehab+samsung@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Cc: Deepa Dinamani <deepa.kernel@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 03 August 2019, 14:02:00 UTC
0e31225 Linus Torvalds 03 August 2019, 01:53:51 UTC Merge tag 'drm-fixes-2019-08-02-1' of git://anongit.freedesktop.org/drm/drm Pull more drm fixes from Daniel Vetter: "Dave sends his pull, everyone realizes they've been asleep at the wheel and hits send on their own pulls :-/ Normally I'd just ignore these all because w/e for me and Dave. But this time around the latecomers also included drm-intel-fixes, which failed to send out a -fixes pull thus far for this release (screwed up vacation coverage, despite that 2/3 maintainers were around ... they all look appropriately guilty), and that really is overdue to get landed. And since I had to do a pull request anyway I pulled the other two late ones too. intel fixes (didn't have any ever since the main merge window pull): - gvt fixes (2 cc: stable) - fix gpu reset vs mm-shrinker vs wakeup fun (needed a few patches) - two gem locking fixes (one cc: stable) - pile of misc fixes all over with minor impact, 6 cc: stable, others from this window exynos: - misc minor fixes misc: - some build/Kconfig fixes - regression fix for vm scalability perf test which seems to mostly exercise dmesg/console logging ... - the vgem cache flush fix for arm64 broke the world on x86, so that's reverted again * tag 'drm-fixes-2019-08-02-1' of git://anongit.freedesktop.org/drm/drm: (42 commits) Revert "drm/vgem: fix cache synchronization on arm/arm64" drm/exynos: fix missing decrement of retry counter drm/exynos: add CONFIG_MMU dependency drm/exynos: remove redundant assignment to pointer 'node' drm/exynos: using dev_get_drvdata directly drm/bochs: Use shadow buffer for bochs framebuffer console drm/fb-helper: Instanciate shadow FB if configured in device's mode_config drm/fb-helper: Map DRM client buffer only when required drm/client: Support unmapping of DRM client buffers drm/i915: Only recover active engines drm/i915: Add a wakeref getter for iff the wakeref is already active drm/i915: Lift intel_engines_resume() to callers drm/vgem: fix cache synchronization on arm/arm64 drm/i810: Use CONFIG_PREEMPTION drm/bridge: tc358764: Fix build error drm/bridge: lvds-encoder: Fix build error while CONFIG_DRM_KMS_HELPER=m drm/i915/gvt: Adding ppgtt to GVT GEM context after shadow pdps settled. drm/i915/gvt: grab runtime pm first for forcewake use drm/i915/gvt: fix incorrect cache entry for guest page mapping drm/i915/gvt: Checking workload's gma earlier ... 03 August 2019, 01:53:51 UTC
4f1a6ef Linus Torvalds 03 August 2019, 01:40:49 UTC Merge tag 'selinux-pr-20190801' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux Pull selinux fix from Paul Moore: "One more small fix for a potential memory leak in an error path" * tag 'selinux-pr-20190801' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: selinux: fix memory leak in policydb_init() 03 August 2019, 01:40:49 UTC
2b372a9 Jean Delvare 31 July 2019, 08:07:06 UTC mtd: hyperbus: Add hardware dependency to AM654 driver The hbmc-am654 driver is for the TI AM654, which is an ARM64 SoC, so don't propose this driver on other architectures unless build-testing. Fixes: b07079f1642c ("mtd: hyperbus: Add driver for TI's HyperBus memory controller") Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> 03 August 2019, 00:11:52 UTC
2d75989 Vignesh Raghavendra 19 July 2019, 08:29:12 UTC mtd: hyperbus: Kconfig: Fix HBMC_AM654 dependencies On x86_64, when CONFIG_OF is not disabled: WARNING: unmet direct dependencies detected for MUX_MMIO Depends on [n]: MULTIPLEXER [=y] && (OF [=n] || COMPILE_TEST [=n]) Selected by [y]: - HBMC_AM654 [=y] && MTD [=y] && MTD_HYPERBUS [=y] due to config HBMC_AM654 tristate "HyperBus controller driver for AM65x SoC" select MULTIPLEXER select MUX_MMIO Fix this by making HBMC_AM654 imply MUX_MMIO instead of select so that dependencies are taken care of. MUX_MMIO is optional for functioning of driver. Fixes: b07079f1642c ("mtd: hyperbus: Add driver for TI's HyperBus memory controller") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> 03 August 2019, 00:11:41 UTC
8493b2a Marco Felsch 30 July 2019, 13:44:07 UTC mtd: rawnand: micron: handle on-die "ECC-off" devices correctly Some devices are not supposed to support on-die ECC but experience shows that internal ECC machinery can actually be enabled through the "SET FEATURE (EFh)" command, even if a read of the "READ ID Parameter Tables" returns that it is not. Currently, the driver checks the "READ ID Parameter" field directly after having enabled the feature. If the check fails it returns immediately but leaves the ECC on. When using buggy chips like MT29F2G08ABAGA and MT29F2G08ABBGA, all future read/program cycles will go through the on-die ECC, confusing the host controller which is supposed to be the one handling correction. To address this in a common way we need to turn off the on-die ECC directly after reading the "READ ID Parameter" and before checking the "ECC status". Cc: stable@vger.kernel.org Fixes: dbc44edbf833 ("mtd: rawnand: micron: Fix on-die ECC detection logic") Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> 03 August 2019, 00:00:01 UTC
dcb8cfb Linus Torvalds 02 August 2019, 22:26:48 UTC Merge tag 'for-linus-5.3a-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: - a small cleanup - a fix for a build error on ARM with some configs - a fix of a patch for the Xen gntdev driver - three patches for fixing a potential problem in the swiotlb-xen driver which Konrad was fine with me carrying them through the Xen tree * tag 'for-linus-5.3a-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/swiotlb: remember having called xen_create_contiguous_region() xen/swiotlb: simplify range_straddles_page_boundary() xen/swiotlb: fix condition for calling xen_destroy_contiguous_region() xen: avoid link error on ARM xen/gntdev.c: Replace vm_map_pages() with vm_map_pages_zero() xen/pciback: remove set but not used variable 'old_state' 02 August 2019, 22:26:48 UTC
a507f25 Linus Torvalds 02 August 2019, 22:23:27 UTC Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Update the compat layer to allow single-byte watchpoints on all addresses (similar to the native support) - arm_pmu: fix the restoration of the counters on the CPU_PM_ENTER_FAILED path - Fix build regression with vDSO and Makefile not stripping CROSS_COMPILE_COMPAT - Fix the CTR_EL0 (cache type register) sanitisation on heterogeneous machines (e.g. big.LITTLE) - Fix the interrupt controller priority mask value when pseudo-NMIs are enabled - arm64 kprobes fixes: recovering of the PSTATE.D flag in the single-step exception handler, NOKPROBE annotations for unwind_frame() and walk_stackframe(), remove unneeded rcu_read_lock/unlock from debug handlers - Several gcc fall-through warnings - Unused variable warnings * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Make debug exception handlers visible from RCU arm64: kprobes: Recover pstate.D in single-step exception handler arm64/mm: fix variable 'tag' set but not used arm64/mm: fix variable 'pud' set but not used arm64: Remove unneeded rcu_read_lock from debug handlers arm64: unwind: Prohibit probing on return_address() arm64: Lower priority mask for GIC_PRIO_IRQON arm64/efi: fix variable 'si' set but not used arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG} arm64: vdso: Fix Makefile regression arm64: module: Mark expected switch fall-through arm64: smp: Mark expected switch fall-through arm64: hw_breakpoint: Fix warnings about implicit fallthrough drivers/perf: arm_pmu: Fix failure path in PM notifier arm64: compat: Allow single-byte watchpoints on all addresses 02 August 2019, 22:23:27 UTC
9100fc5 Linus Torvalds 02 August 2019, 22:18:51 UTC Merge branch 'parisc-5.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: "A few small fixes for the parisc architecture: - Fix fall-through warnings in parisc math emu code - Fix vmlinuz linking failure with debug-enabled kernels - Fix a race condition in kernel live-patching code - Add missing archclean Makefile target & defconfig adjustments" * 'parisc-5.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Add archclean Makefile target parisc: Strip debug info from kernel before creating compressed vmlinuz parisc: Fix build of compressed kernel even with debug enabled parisc: fix race condition in patching code parisc: rename default_defconfig to defconfig parisc: Fix fall-through warnings in fpudispatch.c parisc: Mark expected switch fall-throughs in fault.c 02 August 2019, 22:18:51 UTC
4dd6819 Linus Torvalds 02 August 2019, 22:13:27 UTC Merge tag 's390-5.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 updates from Vasily Gorbik: - Default configs updates - Minor qdio cleanup - Sparse warnings fixes - Implicit-fallthrough warnings fixes * tag 's390-5.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/zcrypt: adjust switch fall through comments for -Wimplicit-fallthrough vfio-ccw: make vfio_ccw_async_region_ops static s390/3215: add switch fall through comment for -Wimplicit-fallthrough s390/tape: add fallthrough annotations s390/mm: add fallthrough annotations s390/mm: make gmap_test_and_clear_dirty_pmd static s390/kexec: add missing include to machine_kexec_reloc.c s390/perf: make cf_diag_csd static s390/lib: add missing include s390/boot: add missing declarations and includes s390: update configs s390: clean up qdio.h 02 August 2019, 22:13:27 UTC
6e6d053 Linus Torvalds 02 August 2019, 21:46:33 UTC Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Seven fixes to four drivers with no core changes. The mpt3sas one is theoretical until we get a CPU that goes up to 64 bits physical, the qla2xxx one fixes an oops in a driver initialization error leg and the others are mostly cosmetic" [ The fcoe patches may be worth highlighting - they may be "just" cleanups, but they simplify and fix the odd fc_rport_priv structure handling rules so that the new gcc-9 warnings about memset crossing structure boundaries are gone. The old code was hard for humans to understand too, and really confused the compiler sanity checks - Linus ] * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: qla2xxx: Fix possible fcport null-pointer dereferences scsi: mpt3sas: Use 63-bit DMA addressing on SAS35 HBA scsi: hpsa: remove printing internal cdb on tag collision scsi: hpsa: correct scsi command status issue after reset scsi: fcoe: pass in fcoe_rport structure instead of fc_rport_priv scsi: fcoe: Embed fc_rport_priv in fcoe_rport structure scsi: libfc: Whitespace cleanup in libfc.h 02 August 2019, 21:46:33 UTC
10e5ddd Linus Torvalds 02 August 2019, 21:31:26 UTC Merge tag 'for-linus-20190802' of git://git.kernel.dk/linux-block Pull block fixes from Jens Axboe: "Here's a small collection of fixes that should go into this series. This contains: - io_uring potential use-after-free fix (Jackie) - loop regression fix (Jan) - O_DIRECT fragmented bio regression fix (Damien) - Mark Denis as the new floppy maintainer (Denis) - ataflop switch fall-through annotation (Gustavo) - libata zpodd overflow fix (Kees) - libata ahci deferred probe fix (Miquel) - nbd invalidation BUG_ON() fix (Munehisa) - dasd endless loop fix (Stefan)" * tag 'for-linus-20190802' of git://git.kernel.dk/linux-block: s390/dasd: fix endless loop after read unit address configuration block: Fix __blkdev_direct_IO() for bio fragments MAINTAINERS: floppy: take over maintainership nbd: replace kill_bdev() with __invalidate_device() again ata: libahci: do not complain in case of deferred probe io_uring: fix KASAN use after free in io_sq_wq_submit_work loop: Fix mount(2) failure due to race with LOOP_SET_FD libata: zpodd: Fix small read overflow in zpodd_get_mech_type() ataflop: Mark expected switch fall-through 02 August 2019, 21:31:26 UTC
b2c7423 Linus Torvalds 02 August 2019, 21:28:40 UTC Merge tag 'for-5.3/dm-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mike Snitzer: "Fix NULL pointer and various whitespace issues with DM's recent DAX code changes from commit in 5.3 merge" * tag 'for-5.3/dm-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm table: fix various whitespace issues with recent DAX code dm table: fix dax_dev NULL dereference in device_synchronous() 02 August 2019, 21:28:40 UTC
b07042c Linus Torvalds 02 August 2019, 21:23:24 UTC Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma Pull rdma fixes from Doug Ledford: "Here's our second -rc pull request. Nothing particularly special in this one. The client removal deadlock fix is kindy tricky, but we had multiple eyes on it and no one could find a fault in it. A couple Spectre V1 fixes too. Otherwise, all just normal -rc fodder: - A couple Spectre V1 fixes (umad, hfi1) - Fix a tricky deadlock in the rdma core code with refcounting instead of locks (client removal patches) - Build errors (hns) - Fix a scheduling while atomic issue (mlx5) - Use after free fix (mad) - Fix error path return code (hns) - Null deref fix (siw_crypto_hash) - A few other misc. minor fixes" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: RDMA/hns: Fix error return code in hns_roce_v1_rsv_lp_qp() RDMA/mlx5: Release locks during notifier unregister IB/hfi1: Fix Spectre v1 vulnerability IB/mad: Fix use-after-free in ib mad completion handling RDMA/restrack: Track driver QP types in resource tracker IB/mlx5: Fix MR registration flow to use UMR properly RDMA/devices: Remove the lock around remove_client_context RDMA/devices: Do not deadlock during client removal IB/core: Add mitigation for Spectre V1 Do not dereference 'siw_crypto_shash' before checking RDMA/qedr: Fix the hca_type and hca_rev returned in device attributes RDMA/hns: Fix build error 02 August 2019, 21:23:24 UTC
d38c3fa Linus Torvalds 02 August 2019, 21:19:41 UTC Merge tag 'for-5.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - tiny race window during 2 transactions aborting at the same time can accidentally lead to a commit - regression fix, possible deadlock during fiemap - fix for an old bug when incremental send can fail on a file that has been deduplicated in a special way * tag 'for-5.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: Btrfs: fix deadlock between fiemap and transaction commits Btrfs: fix race leading to fs corruption after transaction abort Btrfs: fix incremental send failure after deduplication 02 August 2019, 21:19:41 UTC
97b00af Linus Torvalds 02 August 2019, 16:02:58 UTC Merge tag 'gfs2-v5.3-rc2.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2 Pull gfs2 fix from Andreas Gruenbacher: "Fix gfs2 cluster coherency bug" * tag 'gfs2-v5.3-rc2.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2: gfs2: Inode dirtying fix 02 August 2019, 16:02:58 UTC
755f1fe Linus Torvalds 02 August 2019, 15:55:28 UTC Merge tag 'pm-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Fix recent regression affecting ACPI device power management" * tag 'pm-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: PM: Fix regression in acpi_device_set_power() 02 August 2019, 15:55:28 UTC
75cdf41 Linus Torvalds 02 August 2019, 15:53:34 UTC Merge tag 'sound-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: - A further fix for syzcaller issues with USB-audio, addressing NULL dereference that was introduced by the recent fix - Avoid a long delay at boot with HD-audio when i915 module was built but not installed, found on some Debian systems - A fix of small race window at PCM draining * tag 'sound-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: usb-audio: Fix gpf in snd_usb_pipe_sanity_check ALSA: pcm: fix lost wakeup event scenarios in snd_pcm_drain ALSA: hda: Fix 1-minute detection delay when i915 module is not available 02 August 2019, 15:53:34 UTC
f26dbb2 Linus Torvalds 02 August 2019, 15:50:37 UTC Merge tag 'drm-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm Pull drm fixes from Dave Airlie: "Thanks to Daniel for handling the email the last couple of weeks, flus and break-ins combined to derail me. Surprised nothing materialised today to take me out again. Just more amdgpu navi fixes, msm fixes and a single nouveau regression fix: amdgpu: - navi10 temperature and pstate fixes - vcn dynamic power management fix - CS ioctl error handling fix - debugfs info leak fix - amdkfd VegaM fix msm: - dma sync call fix - mdp5 dsi command mode fix - fall-through fixes - disabled GPU fix nouveau: - regression fix for displayport MST support" * tag 'drm-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm: drm/nouveau: Only release VCPI slots on mode changes drm: msm: Fix add_gpu_components drm/msm: Annotate intentional switch statement fall throughs drm/msm: add support for per-CRTC max_vblank_count on mdp5 drm/msm: Use the correct dma_sync calls in msm_gem drm/amd/powerplay: correct UVD/VCE/VCN power status retrieval drm/amd/powerplay: correct Navi10 VCN powergate control (v2) drm/amd/powerplay: support VCN powergate status retrieval for SW SMU drm/amd/powerplay: support VCN powergate status retrieval on Raven drm/amd/powerplay: add new sensor type for VCN powergate status drm/amdgpu: fix a potential information leaking bug drm/amdgpu: fix error handling in amdgpu_cs_process_fence_dep drm/amd/powerplay: enable SW SMU reset functionality drm/amd/powerplay: fix null pointer dereference around dpm state relates drm/amdgpu/powerplay: use proper revision id for navi drm/amd/powerplay: fix temperature granularity error in smu11 drm/amd/powerplay: add callback function of get_thermal_temperature_range drm/amdkfd: Fix byte align on VegaM 02 August 2019, 15:50:37 UTC
42d2190 Linus Torvalds 02 August 2019, 15:47:28 UTC Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "A few fixes for code that came in during the merge window or that started getting exercised differently this time around: - Select regmap MMIO kconfig in spreadtrum driver to avoid compile errors - Complete kerneldoc on devm_clk_bulk_get_optional() - Register an essential clk earlier on mediatek mt8183 SoCs so the clocksource driver can use it - Fix divisor math in the at91 driver - Plug a race in Renesas reset control logic" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: renesas: cpg-mssr: Fix reset control race condition clk: sprd: Select REGMAP_MMIO to avoid compile errors clk: mediatek: mt8183: Register 13MHz clock earlier for clocksource clk: Add missing documentation of devm_clk_bulk_get_optional() argument clk: at91: generated: Truncate divisor to GENERATED_MAX_DIV + 1 02 August 2019, 15:47:28 UTC
234172f Linus Torvalds 02 August 2019, 15:44:33 UTC Merge tag 'arm-swiotlb-5.3' of git://git.infradead.org/users/hch/dma-mapping Pull arm swiotlb support from Christoph Hellwig: "This fixes a cascade of regressions that originally started with the addition of the ia64 port, but only got fatal once we removed most uses of block layer bounce buffering in Linux 4.18. The reason is that while the original i386/PAE code that was the first architecture that supported > 4GB of memory without an iommu decided to leave bounce buffering to the subsystems, which in those days just mean block and networking as no one else consumed arbitrary userspace memory. Later with ia64, x86_64 and other ports we assumed that either an iommu or something that fakes it up ("software IOTLB" in beautiful Intel speak) is present and that subsystems can rely on that for dealing with addressing limitations in devices. Except that the ARM LPAE scheme that added larger physical address to 32-bit ARM did not follow that scheme and thus only worked by chance and only for block and networking I/O directly to highmem. Long story, short fix - add swiotlb support to arm when build for LPAE platforms, which actuallys turns out to be pretty trivial with the modern dma-direct / swiotlb code to fix the Linux 4.18-ish regression" * tag 'arm-swiotlb-5.3' of git://git.infradead.org/users/hch/dma-mapping: arm: use swiotlb for bounce buffering on LPAE configs dma-mapping: check pfn validity in dma_common_{mmap,get_sgtable} 02 August 2019, 15:44:33 UTC
35fca9f Linus Torvalds 02 August 2019, 15:41:11 UTC Merge tag 'dma-mapping-5.3-3' of git://git.infradead.org/users/hch/dma-mapping Pull dma-mapping regression fixes from Christoph Hellwig: "Two related regression fixes for changes from this merge window to fix alignment issues introduced in the CMA allocation rework (Nicolin Chen)" * tag 'dma-mapping-5.3-3' of git://git.infradead.org/users/hch/dma-mapping: dma-contiguous: page-align the size in dma_free_contiguous() dma-contiguous: do not overwrite align in dma_alloc_contiguous() 02 August 2019, 15:41:11 UTC
9c8c9c7 Daniel Vetter 02 August 2019, 15:10:16 UTC Merge tag 'exynos-drm-fixes-for-v5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes - Two cleanup patches . use dev_get_drvdata for readability instead of platform_get_drvdata . remove redundant assignment to node. - Two fixup patches . fix undefined reference to 'vmf_insert_mixed' with NOMMU configuration. . fix potential infinite spin issue by decrementing 'retry' variable in scaler_reset function of exynos_drm_scaler.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Inki Dae <inki.dae@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1564734791-745-1-git-send-email-inki.dae@samsung.com 02 August 2019, 15:10:17 UTC
63dc6e6 Chris Wilson 01 August 2019, 12:44:58 UTC Revert "drm/vgem: fix cache synchronization on arm/arm64" commit 7e9e5ead55be ("drm/vgem: fix cache synchronization on arm/arm64") broke all of the !llc i915-vgem coherency tests in CI, and left the HW very, very unhappy (which is even more scary). Fixes: 7e9e5ead55be ("drm/vgem: fix cache synchronization on arm/arm64") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rob Clark <robdclark@chromium.org> Cc: Sean Paul <seanpaul@chromium.org> Acked-by: Sean Paul <sean@poorly.run> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190801124458.24949-1-chris@chris-wilson.co.uk 02 August 2019, 15:05:55 UTC
5fd5d2b Daniel Vetter 02 August 2019, 15:03:04 UTC Merge tag 'drm-misc-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes drm-misc-fixes for v5.3-rc3: - Fix some build errors in drm/bridge. - Do not build i810 on CONFIG_PREEMPTION. - Fix cache sync on arm in vgem. - Allow mapping fb in drm_client only when required, and use it to fix bochs fbdev. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/af0dc371-16e0-cee8-0d71-4824d44aa973@linux.intel.com 02 August 2019, 15:03:04 UTC
3cdd986 Vasily Gorbik 28 July 2019, 23:23:46 UTC s390/zcrypt: adjust switch fall through comments for -Wimplicit-fallthrough Silence the following warnings when built with -Wimplicit-fallthrough=3 enabled by default since 5.3-rc2: In file included from ./include/linux/preempt.h:11, from ./include/linux/spinlock.h:51, from ./include/linux/mmzone.h:8, from ./include/linux/gfp.h:6, from ./include/linux/slab.h:15, from drivers/s390/crypto/ap_queue.c:13: drivers/s390/crypto/ap_queue.c: In function 'ap_sm_recv': ./include/linux/list.h:577:2: warning: this statement may fall through [-Wimplicit-fallthrough=] 577 | for (pos = list_first_entry(head, typeof(*pos), member); \ | ^~~ drivers/s390/crypto/ap_queue.c:147:3: note: in expansion of macro 'list_for_each_entry' 147 | list_for_each_entry(ap_msg, &aq->pendingq, list) { | ^~~~~~~~~~~~~~~~~~~ drivers/s390/crypto/ap_queue.c:155:2: note: here 155 | case AP_RESPONSE_NO_PENDING_REPLY: | ^~~~ drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_ep11_xcrb': drivers/s390/crypto/zcrypt_msgtype6.c:871:6: warning: this statement may fall through [-Wimplicit-fallthrough=] 871 | if (msg->cprbx.cprb_ver_id == 0x04) | ^ drivers/s390/crypto/zcrypt_msgtype6.c:874:2: note: here 874 | default: /* Unknown response type, this should NEVER EVER happen */ | ^~~~~~~ drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_rng': drivers/s390/crypto/zcrypt_msgtype6.c:901:6: warning: this statement may fall through [-Wimplicit-fallthrough=] 901 | if (msg->cprbx.cprb_ver_id == 0x02) | ^ drivers/s390/crypto/zcrypt_msgtype6.c:907:2: note: here 907 | default: /* Unknown response type, this should NEVER EVER happen */ | ^~~~~~~ drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_xcrb': drivers/s390/crypto/zcrypt_msgtype6.c:838:6: warning: this statement may fall through [-Wimplicit-fallthrough=] 838 | if (msg->cprbx.cprb_ver_id == 0x02) | ^ drivers/s390/crypto/zcrypt_msgtype6.c:844:2: note: here 844 | default: /* Unknown response type, this should NEVER EVER happen */ | ^~~~~~~ drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_ica': drivers/s390/crypto/zcrypt_msgtype6.c:801:6: warning: this statement may fall through [-Wimplicit-fallthrough=] 801 | if (msg->cprbx.cprb_ver_id == 0x02) | ^ drivers/s390/crypto/zcrypt_msgtype6.c:808:2: note: here 808 | default: /* Unknown response type, this should NEVER EVER happen */ | ^~~~~~~ Acked-by: Patrick Steuer <patrick.steuer@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> 02 August 2019, 11:58:23 UTC
d8bb671 Masami Hiramatsu 01 August 2019, 14:36:14 UTC arm64: Make debug exception handlers visible from RCU Make debug exceptions visible from RCU so that synchronize_rcu() correctly track the debug exception handler. This also introduces sanity checks for user-mode exceptions as same as x86's ist_enter()/ist_exit(). The debug exception can interrupt in idle task. For example, it warns if we put a kprobe on a function called from idle task as below. The warning message showed that the rcu_read_lock() caused this problem. But actually, this means the RCU is lost the context which is already in NMI/IRQ. /sys/kernel/debug/tracing # echo p default_idle_call >> kprobe_events /sys/kernel/debug/tracing # echo 1 > events/kprobes/enable /sys/kernel/debug/tracing # [ 135.122237] [ 135.125035] ============================= [ 135.125310] WARNING: suspicious RCU usage [ 135.125581] 5.2.0-08445-g9187c508bdc7 #20 Not tainted [ 135.125904] ----------------------------- [ 135.126205] include/linux/rcupdate.h:594 rcu_read_lock() used illegally while idle! [ 135.126839] [ 135.126839] other info that might help us debug this: [ 135.126839] [ 135.127410] [ 135.127410] RCU used illegally from idle CPU! [ 135.127410] rcu_scheduler_active = 2, debug_locks = 1 [ 135.128114] RCU used illegally from extended quiescent state! [ 135.128555] 1 lock held by swapper/0/0: [ 135.128944] #0: (____ptrval____) (rcu_read_lock){....}, at: call_break_hook+0x0/0x178 [ 135.130499] [ 135.130499] stack backtrace: [ 135.131192] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0-08445-g9187c508bdc7 #20 [ 135.131841] Hardware name: linux,dummy-virt (DT) [ 135.132224] Call trace: [ 135.132491] dump_backtrace+0x0/0x140 [ 135.132806] show_stack+0x24/0x30 [ 135.133133] dump_stack+0xc4/0x10c [ 135.133726] lockdep_rcu_suspicious+0xf8/0x108 [ 135.134171] call_break_hook+0x170/0x178 [ 135.134486] brk_handler+0x28/0x68 [ 135.134792] do_debug_exception+0x90/0x150 [ 135.135051] el1_dbg+0x18/0x8c [ 135.135260] default_idle_call+0x0/0x44 [ 135.135516] cpu_startup_entry+0x2c/0x30 [ 135.135815] rest_init+0x1b0/0x280 [ 135.136044] arch_call_rest_init+0x14/0x1c [ 135.136305] start_kernel+0x4d4/0x500 [ 135.136597] So make debug exception visible to RCU can fix this warning. Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Acked-by: Paul E. McKenney <paulmck@linux.ibm.com> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> 02 August 2019, 10:56:01 UTC
b3980e4 Masami Hiramatsu 01 August 2019, 14:25:49 UTC arm64: kprobes: Recover pstate.D in single-step exception handler kprobes manipulates the interrupted PSTATE for single step, and doesn't restore it. Thus, if we put a kprobe where the pstate.D (debug) masked, the mask will be cleared after the kprobe hits. Moreover, in the most complicated case, this can lead a kernel crash with below message when a nested kprobe hits. [ 152.118921] Unexpected kernel single-step exception at EL1 When the 1st kprobe hits, do_debug_exception() will be called. At this point, debug exception (= pstate.D) must be masked (=1). But if another kprobes hits before single-step of the first kprobe (e.g. inside user pre_handler), it unmask the debug exception (pstate.D = 0) and return. Then, when the 1st kprobe setting up single-step, it saves current DAIF, mask DAIF, enable single-step, and restore DAIF. However, since "D" flag in DAIF is cleared by the 2nd kprobe, the single-step exception happens soon after restoring DAIF. This has been introduced by commit 7419333fa15e ("arm64: kprobe: Always clear pstate.D in breakpoint exception handler") To solve this issue, this stores all DAIF bits and restore it after single stepping. Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Fixes: 7419333fa15e ("arm64: kprobe: Always clear pstate.D in breakpoint exception handler") Reviewed-by: James Morse <james.morse@arm.com> Tested-by: James Morse <james.morse@arm.com> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> 02 August 2019, 10:55:50 UTC
ab35c8a Daniel Vetter 02 August 2019, 09:31:20 UTC Merge tag 'drm-intel-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v5.3-rc3: - GVT fixes - Fix TBT aux powerwell - Fix PSR2 training pattern duration - Fix memory leak in runtime wakeref tracking - Fix ICL memory bandwidth issue preventing planes from being enabled - Fix OA mux configuration delays for accurate performance data - Fix VLV/CHV DP audio cdclk frequency requirements - Fix register whitelisting to fix a number of GL & Vulkan CTS tests - Fix ICL perf register offsets - Fix Gen11 Sampler Prefetch workaround, impacting dEQP tests - Fix various gen2 tracepoints - A number of GEM locking fixes addressing lockdep issues - Fix idle engine reset, recover only active engines - Fix incorrect MCR programming Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87d0hnncgo.fsf@intel.com 02 August 2019, 09:31:21 UTC
1bbbab0 Colin Ian King 22 July 2019, 22:25:35 UTC drm/exynos: fix missing decrement of retry counter Currently the retry counter is not being decremented, leading to a potential infinite spin if the scalar_reads don't change state. Addresses-Coverity: ("Infinite loop") Fixes: 280e54c9f614 ("drm/exynos: scaler: Reset hardware before starting the operation") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> 02 August 2019, 07:50:18 UTC
d6f25bd Arnd Bergmann 09 July 2019, 12:08:48 UTC drm/exynos: add CONFIG_MMU dependency Compile-testing this driver on a NOMMU configuration shows a link failure: drivers/gpu/drm/exynos/exynos_drm_gem.o: In function `exynos_drm_gem_fault': exynos_drm_gem.c:(.text+0x484): undefined reference to `vmf_insert_mixed' Add a CONFIG_MMU dependency to ensure we only enable this in configurations that build correctly. Many other drm drivers have the same dependency. It would be nice to make this work in MMU-less configurations, but evidently nobody has ever needed this so far. Fixes: 156bdac99061 ("drm/exynos: trigger build of all modules") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Inki Dae <daeinki@gmail.com> 02 August 2019, 06:28:47 UTC
59d4317 Colin Ian King 09 July 2019, 12:01:14 UTC drm/exynos: remove redundant assignment to pointer 'node' The pointer 'node' is being assigned with a value that is never read and is re-assigned later. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Inki Dae <daeinki@gmail.com> 02 August 2019, 06:28:47 UTC
9eae7c3 Fuqian Huang 04 July 2019, 02:34:36 UTC drm/exynos: using dev_get_drvdata directly Several drivers cast a struct device pointer to a struct platform_device pointer only to then call platform_get_drvdata(). To improve readability, these constructs can be simplified by using dev_get_drvdata() directly. Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> 02 August 2019, 06:28:47 UTC
4199534 Stefan Haberland 01 August 2019, 11:06:30 UTC s390/dasd: fix endless loop after read unit address configuration After getting a storage server event that causes the DASD device driver to update its unit address configuration during a device shutdown there is the possibility of an endless loop in the device driver. In the system log there will be ongoing DASD error messages with RC: -19. The reason is that the loop starting the ruac request only terminates when the retry counter is decreased to 0. But in the sleep_on function there are early exit paths that do not decrease the retry counter. Prevent an endless loop by handling those cases separately. Remove the unnecessary do..while loop since the sleep_on function takes care of retries by itself. Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1") Cc: stable@vger.kernel.org # 2.6.25+ Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> 02 August 2019, 02:46:14 UTC
f8981e0 Dave Airlie 02 August 2019, 00:17:25 UTC Merge tag 'msm-fixes-2019_08_01' of https://gitlab.freedesktop.org/drm/msm into drm-fixes - Fix the dma_sync calls applied last week (Rob) - Fix mdp5 dsi command mode (Brian) - Squash fall through warnings (Jordan) - Don't add disabled gpu nodes to the of device list (Jeffrey) Cc: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Rob Clark <robdclark@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com> # gpg: Signature made Fri 02 Aug 2019 05:54:27 AM AEST # gpg: using RSA key 96F70DFDA84A070A # gpg: Can't check signature: public key not found From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190801200439.GV104440@art_vandelay 02 August 2019, 00:17:25 UTC
412e85b Lyude Paul 01 August 2019, 22:02:15 UTC drm/nouveau: Only release VCPI slots on mode changes Looks like a regression got introduced into nv50_mstc_atomic_check() that somehow didn't get found until now. If userspace changes crtc_state->active to false but leaves the CRTC enabled, we end up calling drm_dp_atomic_find_vcpi_slots() using the PBN calculated in asyh->dp.pbn. However, if the display is inactive we end up calculating a PBN of 0, which inadvertently causes us to have an allocation of 0. >From there, if userspace then disables the CRTC afterwards we end up accidentally attempting to free the VCPI twice: WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336 drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] RIP: 0010:drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] Call Trace: drm_atomic_helper_check_modeset+0x3f3/0xa60 [drm_kms_helper] ? drm_atomic_check_only+0x43/0x780 [drm] drm_atomic_helper_check+0x15/0x90 [drm_kms_helper] nv50_disp_atomic_check+0x83/0x1d0 [nouveau] drm_atomic_check_only+0x54d/0x780 [drm] ? drm_atomic_set_crtc_for_connector+0xec/0x100 [drm] drm_atomic_commit+0x13/0x50 [drm] drm_atomic_helper_set_config+0x81/0x90 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? vprintk_emit+0x16a/0x230 ? drm_ioctl+0x163/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] nouveau_drm_ioctl+0x63/0xb0 [nouveau] do_vfs_ioctl+0x405/0x660 ? recalc_sigpending+0x17/0x50 ? _copy_from_user+0x37/0x60 ksys_ioctl+0x5e/0x90 ? exit_to_usermode_loop+0x92/0xe0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x59/0x190 entry_SYSCALL_64_after_hwframe+0x44/0xa9 WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336 drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] ---[ end trace 4c395c0c51b1f88d ]--- [drm:drm_dp_atomic_release_vcpi_slots [drm_kms_helper]] *ERROR* no VCPI for [MST PORT:00000000e288eb7d] found in mst state 000000008e642070 So, fix this by doing what we probably should have done from the start: only call drm_dp_atomic_find_vcpi_slots() when crtc_state->mode_changed is set, so that VCPI allocations remain for as long as the CRTC is enabled. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") Cc: Lyude Paul <lyude@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Juston Li <juston.li@intel.com> Cc: Karol Herbst <karolherbst@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: <stable@vger.kernel.org> # v5.1+ Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190801220216.15323-1-lyude@redhat.com 01 August 2019, 23:49:37 UTC
4b381ee Dave Airlie 01 August 2019, 23:35:39 UTC Merge tag 'drm-fixes-5.3-2019-07-31' of git://people.freedesktop.org/~agd5f/linux into drm-fixes drm-fixes-5.3-2019-07-31: amdgpu: - Fix temperature granularity for navi - Fix stable pstate setting for navi - Fix VCN DPM enablement on navi - Fix error handling on CS ioctl when processing dependencies - Fix possible information leak in debugfs amdkfd: - fix memory alignment for VegaM Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190731191648.25729-1-alexander.deucher@amd.com 01 August 2019, 23:35:40 UTC
42787ed Rafael J. Wysocki 31 July 2019, 23:31:08 UTC ACPI: PM: Fix regression in acpi_device_set_power() Commit f850a48a0799 ("ACPI: PM: Allow transitions to D0 to occur in special cases") overlooked the fact that acpi_power_transition() may change the power.state value for the target device and if that happens, it may confuse acpi_device_set_power() and cause it to omit the _PS0 evaluation which on some systems is necessary to change power states of devices from low-power to D0. Fix that by saving the current value of power.state for the target device before passing it to acpi_power_transition() and using the saved value in a subsequent check. Fixes: f850a48a0799 ("ACPI: PM: Allow transitions to D0 to occur in special cases") Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reported-by: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com> 01 August 2019, 21:39:17 UTC
8eb9a2d Gustavo A. R. Silva 28 July 2019, 23:51:38 UTC i2c: s3c2410: Mark expected switch fall-through Mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/i2c/busses/i2c-s3c2410.c: In function 'i2c_s3c_irq_nextbyte': drivers/i2c/busses/i2c-s3c2410.c:431:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (i2c->state == STATE_READ) ^ drivers/i2c/busses/i2c-s3c2410.c:439:2: note: here case STATE_WRITE: ^~~~ Notice that, in this particular case, the code comment is modified in accordance with what GCC is expecting to find. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 01 August 2019, 20:24:16 UTC
b1ac670 Michał Mirosław 22 July 2019, 19:05:56 UTC i2c: at91: fix clk_offset for sama5d2 In SAMA5D2 datasheet, TWIHS_CWGR register rescription mentions clock offset of 3 cycles (compared to 4 in eg. SAMA5D3). Cc: stable@vger.kernel.org # 5.2.x [needs applying to i2c-at91.c instead for earlier kernels] Fixes: 0ef6f3213dac ("i2c: at91: add support for new alternative command mode") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 01 August 2019, 20:24:16 UTC
d12e3aa Michał Mirosław 22 July 2019, 18:55:27 UTC i2c: at91: disable TXRDY interrupt after sending data Driver was not disabling TXRDY interrupt after last TX byte. This caused interrupt storm until transfer timeouts for slow or broken device on the bus. The patch fixes the interrupt storm on my SAMA5D2-based board. Cc: stable@vger.kernel.org # 5.2.x [v5.2 introduced file split; the patch should apply to i2c-at91.c before the split] Fixes: fac368a04048 ("i2c: at91: add new driver") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Tested-by: Raag Jadav <raagjadav@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 01 August 2019, 20:24:16 UTC
0eb6ddf Damien Le Moal 01 August 2019, 10:21:51 UTC block: Fix __blkdev_direct_IO() for bio fragments The recent fix to properly handle IOCB_NOWAIT for async O_DIRECT IO (patch 6a43074e2f46) introduced two problems with BIO fragment handling for direct IOs: 1) The dio size processed is calculated by incrementing the ret variable by the size of the bio fragment issued for the dio. However, this size is obtained directly from bio->bi_iter.bi_size AFTER the bio submission which may result in referencing the bi_size value after the bio completed, resulting in an incorrect value use. 2) The ret variable is not incremented by the size of the last bio fragment issued for the bio, leading to an invalid IO size being returned to the user. Fix both problem by using dio->size (which is incremented before the bio submission) to update the value of ret after bio submissions, including for the last bio fragment issued. Fixes: 6a43074e2f46 ("block: properly handle IOCB_NOWAIT for async O_DIRECT IO") Reported-by: Masato Suzuki <masato.suzuki@wdc.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> 01 August 2019, 19:51:18 UTC
a5dbba8 Thomas Gleixner 01 August 2019, 18:21:00 UTC Merge tag 'irqchip-fixes-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes from Marc Zyngier: A small bunch of fixes from the irqchip department: - Fix a couple of UAF on error paths (RZA1, GICv3 ITS) - Fix iMX GPCv2 trigger setting - Add missing of_node_put on error path in MBIGEN - Add another bunch of /* fall-through */ to silence warnings 01 August 2019, 18:21:00 UTC
fc5b34a Micah Morton 01 August 2019, 17:28:27 UTC Add entry in MAINTAINERS file for SafeSetID LSM This LSM was added in v5.1 and needs an entry in the MAINTAINERS file. Signed-off-by: Micah Morton <mortonm@chromium.org> Acked-by: James Morris <jamorris@linux.microsoft.com> 01 August 2019, 17:30:57 UTC
020fb3b Wei Yongjun 01 August 2019, 01:27:25 UTC RDMA/hns: Fix error return code in hns_roce_v1_rsv_lp_qp() Fix to return error code -ENOMEM from the rdma_zalloc_drv_obj() error handling case instead of 0, as done elsewhere in this function. Fixes: e8ac9389f0d7 ("RDMA: Fix allocation failure on pointer pd") Fixes: 21a428a019c9 ("RDMA: Handle PD allocations by IB/core") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Leon Romanovsky <leonro@mellanox.com> Link: https://lore.kernel.org/r/20190801012725.150493-1-weiyongjun1@huawei.com Signed-off-by: Doug Ledford <dledford@redhat.com> 01 August 2019, 16:53:53 UTC
9ca7ad6 Jeffrey Hugo 26 June 2019, 18:00:15 UTC drm: msm: Fix add_gpu_components add_gpu_components() adds found GPU nodes from the DT to the match list, regardless of the status of the nodes. This is a problem, because if the nodes are disabled, they should not be on the match list because they will not be matched. This prevents display from initing if a GPU node is defined, but it's status is disabled. Fix this by checking the node's status before adding it to the match list. Fixes: dc3ea265b856 (drm/msm: Drop the gpu binding) Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190626180015.45242-1-jeffrey.l.hugo@gmail.com 01 August 2019, 16:52:21 UTC
23eaf3b Leon Romanovsky 31 July 2019, 08:38:52 UTC RDMA/mlx5: Release locks during notifier unregister The below kernel panic was observed when created bond mode LACP with GRE tunnel on top. The reason to it was not released spinlock during mlx5 notify unregsiter sequence. [ 234.562007] BUG: scheduling while atomic: sh/10900/0x00000002 [ 234.563005] Preemption disabled at: [ 234.566864] ------------[ cut here ]------------ [ 234.567120] DEBUG_LOCKS_WARN_ON(val > preempt_count()) [ 234.567139] WARNING: CPU: 16 PID: 10900 at kernel/sched/core.c:3203 preempt_count_sub+0xca/0x170 [ 234.569550] CPU: 16 PID: 10900 Comm: sh Tainted: G W 5.2.0-rc1-for-linust-dbg-2019-05-25_04-57-33-60 #1 [ 234.569886] Hardware name: Dell Inc. PowerEdge R720/0X3D66, BIOS 2.6.1 02/12/2018 [ 234.570183] RIP: 0010:preempt_count_sub+0xca/0x170 [ 234.570404] Code: 03 38 d0 7c 08 84 d2 0f 85 b0 00 00 00 8b 15 dd 02 03 04 85 d2 75 ba 48 c7 c6 00 e1 88 83 48 c7 c7 40 e1 88 83 e8 76 11 f7 ff <0f> 0b 5b c3 65 8b 05 d3 1f d8 7e 84 c0 75 82 e8 62 c3 c3 00 85 c0 [ 234.570911] RSP: 0018:ffff888b94477b08 EFLAGS: 00010286 [ 234.571133] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 [ 234.571391] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000246 [ 234.571648] RBP: ffff888ba5560000 R08: fffffbfff08962d5 R09: fffffbfff08962d5 [ 234.571902] R10: 0000000000000001 R11: fffffbfff08962d4 R12: ffff888bac6e9548 [ 234.572157] R13: ffff888babfaf728 R14: ffff888bac6e9568 R15: ffff888babfaf750 [ 234.572412] FS: 00007fcafa59b740(0000) GS:ffff888bed200000(0000) knlGS:0000000000000000 [ 234.572686] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 234.572914] CR2: 00007f984f16b140 CR3: 0000000b2bf0a001 CR4: 00000000001606e0 [ 234.573172] Call Trace: [ 234.573336] _raw_spin_unlock+0x2e/0x50 [ 234.573542] mlx5_ib_unbind_slave_port+0x1bc/0x690 [mlx5_ib] [ 234.573793] mlx5_ib_cleanup_multiport_master+0x1d3/0x660 [mlx5_ib] [ 234.574039] mlx5_ib_stage_init_cleanup+0x4c/0x360 [mlx5_ib] [ 234.574271] ? kfree+0xf5/0x2f0 [ 234.574465] __mlx5_ib_remove+0x61/0xd0 [mlx5_ib] [ 234.574688] ? __mlx5_ib_remove+0xd0/0xd0 [mlx5_ib] [ 234.574951] mlx5_remove_device+0x234/0x300 [mlx5_core] [ 234.575224] mlx5_unregister_device+0x4d/0x1e0 [mlx5_core] [ 234.575493] remove_one+0x4f/0x160 [mlx5_core] [ 234.575704] pci_device_remove+0xef/0x2a0 [ 234.581407] ? pcibios_free_irq+0x10/0x10 [ 234.587143] ? up_read+0xc1/0x260 [ 234.592785] device_release_driver_internal+0x1ab/0x430 [ 234.598442] unbind_store+0x152/0x200 [ 234.604064] ? sysfs_kf_write+0x3b/0x180 [ 234.609441] ? sysfs_file_ops+0x160/0x160 [ 234.615021] kernfs_fop_write+0x277/0x440 [ 234.620288] ? __sb_start_write+0x1ef/0x2c0 [ 234.625512] vfs_write+0x15e/0x460 [ 234.630786] ksys_write+0x156/0x1e0 [ 234.635988] ? __ia32_sys_read+0xb0/0xb0 [ 234.641120] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 234.646163] do_syscall_64+0x95/0x470 [ 234.651106] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 234.656004] RIP: 0033:0x7fcaf9c9cfd0 [ 234.660686] Code: 73 01 c3 48 8b 0d c0 6e 2d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d cd cf 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee cb 01 00 48 89 04 24 [ 234.670128] RSP: 002b:00007ffd3b01ddd8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 234.674811] RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fcaf9c9cfd0 [ 234.679387] RDX: 000000000000000d RSI: 00007fcafa5c1000 RDI: 0000000000000001 [ 234.683848] RBP: 00007fcafa5c1000 R08: 000000000000000a R09: 00007fcafa59b740 [ 234.688167] R10: 00007ffd3b01d8e0 R11: 0000000000000246 R12: 00007fcaf9f75400 [ 234.692386] R13: 000000000000000d R14: 0000000000000001 R15: 0000000000000000 [ 234.696495] irq event stamp: 153067 [ 234.700525] hardirqs last enabled at (153067): [<ffffffff83258c39>] _raw_spin_unlock_irqrestore+0x59/0x70 [ 234.704665] hardirqs last disabled at (153066): [<ffffffff83259382>] _raw_spin_lock_irqsave+0x22/0x90 [ 234.708722] softirqs last enabled at (153058): [<ffffffff836006c5>] __do_softirq+0x6c5/0xb4e [ 234.712673] softirqs last disabled at (153051): [<ffffffff81227c1d>] irq_exit+0x17d/0x1d0 [ 234.716601] ---[ end trace 5dbf096843ee9ce6 ]--- Fixes: df097a278c75 ("IB/mlx5: Use the new mlx5 core notifier API") Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Link: https://lore.kernel.org/r/20190731083852.584-1-leon@kernel.org Signed-off-by: Doug Ledford <dledford@redhat.com> 01 August 2019, 16:41:41 UTC
6497d0a Gustavo A. R. Silva 31 July 2019, 17:54:28 UTC IB/hfi1: Fix Spectre v1 vulnerability sl is controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. Fix this by sanitizing sl before using it to index ibp->sl_to_sc. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20190731175428.GA16736@embeddedor Signed-off-by: Doug Ledford <dledford@redhat.com> 01 August 2019, 16:14:15 UTC
770b7d9 Jack Morgenstein 01 August 2019, 12:14:49 UTC IB/mad: Fix use-after-free in ib mad completion handling We encountered a use-after-free bug when unloading the driver: [ 3562.116059] BUG: KASAN: use-after-free in ib_mad_post_receive_mads+0xddc/0xed0 [ib_core] [ 3562.117233] Read of size 4 at addr ffff8882ca5aa868 by task kworker/u13:2/23862 [ 3562.118385] [ 3562.119519] CPU: 2 PID: 23862 Comm: kworker/u13:2 Tainted: G OE 5.1.0-for-upstream-dbg-2019-05-19_16-44-30-13 #1 [ 3562.121806] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014 [ 3562.123075] Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] [ 3562.124383] Call Trace: [ 3562.125640] dump_stack+0x9a/0xeb [ 3562.126911] print_address_description+0xe3/0x2e0 [ 3562.128223] ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core] [ 3562.129545] __kasan_report+0x15c/0x1df [ 3562.130866] ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core] [ 3562.132174] kasan_report+0xe/0x20 [ 3562.133514] ib_mad_post_receive_mads+0xddc/0xed0 [ib_core] [ 3562.134835] ? find_mad_agent+0xa00/0xa00 [ib_core] [ 3562.136158] ? qlist_free_all+0x51/0xb0 [ 3562.137498] ? mlx4_ib_sqp_comp_worker+0x1970/0x1970 [mlx4_ib] [ 3562.138833] ? quarantine_reduce+0x1fa/0x270 [ 3562.140171] ? kasan_unpoison_shadow+0x30/0x40 [ 3562.141522] ib_mad_recv_done+0xdf6/0x3000 [ib_core] [ 3562.142880] ? _raw_spin_unlock_irqrestore+0x46/0x70 [ 3562.144277] ? ib_mad_send_done+0x1810/0x1810 [ib_core] [ 3562.145649] ? mlx4_ib_destroy_cq+0x2a0/0x2a0 [mlx4_ib] [ 3562.147008] ? _raw_spin_unlock_irqrestore+0x46/0x70 [ 3562.148380] ? debug_object_deactivate+0x2b9/0x4a0 [ 3562.149814] __ib_process_cq+0xe2/0x1d0 [ib_core] [ 3562.151195] ib_cq_poll_work+0x45/0xf0 [ib_core] [ 3562.152577] process_one_work+0x90c/0x1860 [ 3562.153959] ? pwq_dec_nr_in_flight+0x320/0x320 [ 3562.155320] worker_thread+0x87/0xbb0 [ 3562.156687] ? __kthread_parkme+0xb6/0x180 [ 3562.158058] ? process_one_work+0x1860/0x1860 [ 3562.159429] kthread+0x320/0x3e0 [ 3562.161391] ? kthread_park+0x120/0x120 [ 3562.162744] ret_from_fork+0x24/0x30 ... [ 3562.187615] Freed by task 31682: [ 3562.188602] save_stack+0x19/0x80 [ 3562.189586] __kasan_slab_free+0x11d/0x160 [ 3562.190571] kfree+0xf5/0x2f0 [ 3562.191552] ib_mad_port_close+0x200/0x380 [ib_core] [ 3562.192538] ib_mad_remove_device+0xf0/0x230 [ib_core] [ 3562.193538] remove_client_context+0xa6/0xe0 [ib_core] [ 3562.194514] disable_device+0x14e/0x260 [ib_core] [ 3562.195488] __ib_unregister_device+0x79/0x150 [ib_core] [ 3562.196462] ib_unregister_device+0x21/0x30 [ib_core] [ 3562.197439] mlx4_ib_remove+0x162/0x690 [mlx4_ib] [ 3562.198408] mlx4_remove_device+0x204/0x2c0 [mlx4_core] [ 3562.199381] mlx4_unregister_interface+0x49/0x1d0 [mlx4_core] [ 3562.200356] mlx4_ib_cleanup+0xc/0x1d [mlx4_ib] [ 3562.201329] __x64_sys_delete_module+0x2d2/0x400 [ 3562.202288] do_syscall_64+0x95/0x470 [ 3562.203277] entry_SYSCALL_64_after_hwframe+0x49/0xbe The problem was that the MAD PD was deallocated before the MAD CQ. There was completion work pending for the CQ when the PD got deallocated. When the mad completion handling reached procedure ib_mad_post_receive_mads(), we got a use-after-free bug in the following line of code in that procedure: sg_list.lkey = qp_info->port_priv->pd->local_dma_lkey; (the pd pointer in the above line is no longer valid, because the pd has been deallocated). We fix this by allocating the PD before the CQ in procedure ib_mad_port_open(), and deallocating the PD after freeing the CQ in procedure ib_mad_port_close(). Since the CQ completion work queue is flushed during ib_free_cq(), no completions will be pending for that CQ when the PD is later deallocated. Note that freeing the CQ before deallocating the PD is the practice in the ULPs. Fixes: 4be90bc60df4 ("IB/mad: Remove ib_get_dma_mr calls") Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Link: https://lore.kernel.org/r/20190801121449.24973-1-leon@kernel.org Signed-off-by: Doug Ledford <dledford@redhat.com> 01 August 2019, 15:58:54 UTC
52e0a11 Gal Pressman 01 August 2019, 10:43:54 UTC RDMA/restrack: Track driver QP types in resource tracker The check for QP type different than XRC has excluded driver QP types from the resource tracker. As a result, "rdma resource show" user command would not show opened driver QPs which does not reflect the real state of the system. Check QP type explicitly instead of assuming enum values/ordering. Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation") Signed-off-by: Gal Pressman <galpress@amazon.com> Reviewed-by: Leon Romanovsky <leonro@mellanox.com> Link: https://lore.kernel.org/r/20190801104354.11417-1-galpress@amazon.com Signed-off-by: Doug Ledford <dledford@redhat.com> 01 August 2019, 15:54:13 UTC
e5366d3 Guy Levi 31 July 2019, 08:19:29 UTC IB/mlx5: Fix MR registration flow to use UMR properly Driver shouldn't allow to use UMR to register a MR when umr_modify_atomic_disabled is set. Otherwise it will always end up with a failure in the post send flow which sets the UMR WQE to modify atomic access right. Fixes: c8d75a980fab ("IB/mlx5: Respect new UMR capabilities") Signed-off-by: Guy Levi <guyle@mellanox.com> Reviewed-by: Moni Shoua <monis@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Link: https://lore.kernel.org/r/20190731081929.32559-1-leon@kernel.org Signed-off-by: Doug Ledford <dledford@redhat.com> 01 August 2019, 15:49:51 UTC
9cd5881 Jason Gunthorpe 31 July 2019, 08:18:41 UTC RDMA/devices: Remove the lock around remove_client_context Due to the complexity of client->remove() callbacks it is desirable to not hold any locks while calling them. Remove the last one by tracking only the highest client ID and running backwards from there over the xarray. Since the only purpose of that lock was to protect the linked list, we can drop the lock. Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Link: https://lore.kernel.org/r/20190731081841.32345-3-leon@kernel.org Signed-off-by: Doug Ledford <dledford@redhat.com> 01 August 2019, 15:44:48 UTC
621e55f Jason Gunthorpe 31 July 2019, 08:18:40 UTC RDMA/devices: Do not deadlock during client removal lockdep reports: WARNING: possible circular locking dependency detected modprobe/302 is trying to acquire lock: 0000000007c8919c ((wq_completion)ib_cm){+.+.}, at: flush_workqueue+0xdf/0x990 but task is already holding lock: 000000002d3d2ca9 (&device->client_data_rwsem){++++}, at: remove_client_context+0x79/0xd0 [ib_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&device->client_data_rwsem){++++}: down_read+0x3f/0x160 ib_get_net_dev_by_params+0xd5/0x200 [ib_core] cma_ib_req_handler+0x5f6/0x2090 [rdma_cm] cm_process_work+0x29/0x110 [ib_cm] cm_req_handler+0x10f5/0x1c00 [ib_cm] cm_work_handler+0x54c/0x311d [ib_cm] process_one_work+0x4aa/0xa30 worker_thread+0x62/0x5b0 kthread+0x1ca/0x1f0 ret_from_fork+0x24/0x30 -> #1 ((work_completion)(&(&work->work)->work)){+.+.}: process_one_work+0x45f/0xa30 worker_thread+0x62/0x5b0 kthread+0x1ca/0x1f0 ret_from_fork+0x24/0x30 -> #0 ((wq_completion)ib_cm){+.+.}: lock_acquire+0xc8/0x1d0 flush_workqueue+0x102/0x990 cm_remove_one+0x30e/0x3c0 [ib_cm] remove_client_context+0x94/0xd0 [ib_core] disable_device+0x10a/0x1f0 [ib_core] __ib_unregister_device+0x5a/0xe0 [ib_core] ib_unregister_device+0x21/0x30 [ib_core] mlx5_ib_stage_ib_reg_cleanup+0x9/0x10 [mlx5_ib] __mlx5_ib_remove+0x3d/0x70 [mlx5_ib] mlx5_ib_remove+0x12e/0x140 [mlx5_ib] mlx5_remove_device+0x144/0x150 [mlx5_core] mlx5_unregister_interface+0x3f/0xf0 [mlx5_core] mlx5_ib_cleanup+0x10/0x3a [mlx5_ib] __x64_sys_delete_module+0x227/0x350 do_syscall_64+0xc3/0x6a4 entry_SYSCALL_64_after_hwframe+0x49/0xbe Which is due to the read side of the client_data_rwsem being obtained recursively through a work queue flush during cm client removal. The lock is being held across the remove in remove_client_context() so that the function is a fence, once it returns the client is removed. This is required so that the two callers do not proceed with destruction until the client completes removal. Instead of using client_data_rwsem use the existing device unregistration refcount and add a similar client unregistration (client->uses) refcount. This will fence the two unregistration paths without holding any locks. Cc: <stable@vger.kernel.org> Fixes: 921eab1143aa ("RDMA/devices: Re-organize device.c locking") Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Link: https://lore.kernel.org/r/20190731081841.32345-2-leon@kernel.org Signed-off-by: Doug Ledford <dledford@redhat.com> 01 August 2019, 15:44:47 UTC
61f2598 Luck, Tony 31 July 2019, 04:39:57 UTC IB/core: Add mitigation for Spectre V1 Some processors may mispredict an array bounds check and speculatively access memory that they should not. With a user supplied array index we like to play things safe by masking the value with the array size before it is used as an index. Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20190731043957.GA1600@agluck-desk2.amr.corp.intel.com Signed-off-by: Doug Ledford <dledford@redhat.com> 01 August 2019, 15:34:11 UTC
7732d20 Qian Cai 01 August 2019, 14:47:05 UTC arm64/mm: fix variable 'tag' set but not used When CONFIG_KASAN_SW_TAGS=n, set_tag() is compiled away. GCC throws a warning, mm/kasan/common.c: In function '__kasan_kmalloc': mm/kasan/common.c:464:5: warning: variable 'tag' set but not used [-Wunused-but-set-variable] u8 tag = 0xff; ^~~ Fix it by making __tag_set() a static inline function the same as arch_kasan_set_tag() in mm/kasan/kasan.h for consistency because there is a macro in arch/arm64/include/asm/kasan.h, #define arch_kasan_set_tag(addr, tag) __tag_set(addr, tag) However, when CONFIG_DEBUG_VIRTUAL=n and CONFIG_SPARSEMEM_VMEMMAP=y, page_to_virt() will call __tag_set() with incorrect type of a parameter, so fix that as well. Also, still let page_to_virt() return "void *" instead of "const void *", so will not need to add a similar cast in lowmem_page_address(). Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: Will Deacon <will@kernel.org> 01 August 2019, 14:53:10 UTC
c14b5dc Jordan Crouse 25 July 2019, 16:53:08 UTC drm/msm: Annotate intentional switch statement fall throughs Explicitly mark intentional fall throughs in switch statements to keep -Wimplicit-fallthrough from complaining. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1564073588-27386-1-git-send-email-jcrouse@codeaurora.org 01 August 2019, 14:22:32 UTC
2bab52a Brian Masney 31 May 2019, 09:46:15 UTC drm/msm: add support for per-CRTC max_vblank_count on mdp5 The mdp5 drm/kms driver currently does not work on command-mode DSI panels due to 'vblank wait timed out' errors. This causes a latency of seconds, or tens of seconds in some cases, before content is shown on the panel. This hardware does not have the something that we can use as a frame counter available when running in command mode, so we need to fall back to using timestamps by setting the max_vblank_count to zero. This can be done on a per-CRTC basis, so the convert mdp5 to use drm_crtc_set_max_vblank_count(). This change was tested on a LG Nexus 5 (hammerhead) phone. Suggested-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Reviewed-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190531094619.31704-3-masneyb@onstation.org 01 August 2019, 14:21:23 UTC
7d4e2dc Qian Cai 31 July 2019, 20:05:45 UTC arm64/mm: fix variable 'pud' set but not used GCC throws a warning, arch/arm64/mm/mmu.c: In function 'pud_free_pmd_page': arch/arm64/mm/mmu.c:1033:8: warning: variable 'pud' set but not used [-Wunused-but-set-variable] pud_t pud; ^~~ because pud_table() is a macro and compiled away. Fix it by making it a static inline function and for pud_sect() as well. Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: Will Deacon <will@kernel.org> 01 August 2019, 14:00:27 UTC
760d8ed Masami Hiramatsu 25 July 2019, 08:16:25 UTC arm64: Remove unneeded rcu_read_lock from debug handlers Remove rcu_read_lock()/rcu_read_unlock() from debug exception handlers since we are sure those are not preemptible and interrupts are off. Acked-by: Paul E. McKenney <paulmck@linux.ibm.com> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> 01 August 2019, 14:00:27 UTC
ee07b93 Masami Hiramatsu 25 July 2019, 08:16:05 UTC arm64: unwind: Prohibit probing on return_address() Prohibit probing on return_address() and subroutines which is called from return_address(), since the it is invoked from trace_hardirqs_off() which is also kprobe blacklisted. Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> 01 August 2019, 14:00:26 UTC
677379b Julien Thierry 29 July 2019, 14:57:46 UTC arm64: Lower priority mask for GIC_PRIO_IRQON On a system with two security states, if SCR_EL3.FIQ is cleared, non-secure IRQ priorities get shifted to fit the secure view but priority masks aren't. On such system, it turns out that GIC_PRIO_IRQON masks the priority of normal interrupts, which obviously ends up in a hang. Increase GIC_PRIO_IRQON value (i.e. lower priority) to make sure interrupts are not blocked by it. Cc: Oleg Nesterov <oleg@redhat.com> Fixes: bd82d4bd21880b7c ("arm64: Fix incorrect irqflag restore for priority masking") Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Julien Thierry <julien.thierry.kdev@gmail.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> [will: fixed Fixes: tag] Signed-off-by: Will Deacon <will@kernel.org> 01 August 2019, 13:59:48 UTC
1e78030 Linus Torvalds 01 August 2019, 13:37:42 UTC Merge tag 'mmc-v5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: - sdhci-sprd: Add a missing pm_runtime_put_noidle() to fix deferred probe - dw_mmc: Fix occasional hang after tuning on eMMC - meson-mx-sdio: Fix misuse of GENMASK macro - mmc_spi: Fix CRC problems for writes by using BDI_CAP_STABLE_WRITES * tag 'mmc-v5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: mmc_spi: Enable stable writes mmc: meson-mx-sdio: Fix misuse of GENMASK macro mmc: dw_mmc: Fix occasional hang after tuning on eMMC mmc: host: sdhci-sprd: Fix the missing pm_runtime_put_noidle() 01 August 2019, 13:37:42 UTC
28f5ab1 Linus Torvalds 01 August 2019, 13:26:30 UTC Merge tag 'gpio-v5.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Three GPIO fixes, all touching the core, so quite important: - Fix the request of active low GPIO line events. - Don't issue WARN() stuff on NULL descriptors if the GPIOLIB is disabled. - Preserve the descriptor flags when setting the initial direction on lines" * tag 'gpio-v5.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpiolib: Preserve desc->flags when setting state gpio: don't WARN() on NULL descs if gpiolib is disabled gpiolib: fix incorrect IRQ requesting of an active-low lineevent 01 August 2019, 13:26:30 UTC
5854059 Thomas Zimmermann 03 July 2019, 07:58:34 UTC drm/bochs: Use shadow buffer for bochs framebuffer console The bochs driver (and virtual hardware) requires buffer objects to reside in video ram to display them to the screen. So it can not display the framebuffer console because the respective buffer object is permanently pinned in system memory. Using a shadow buffer for the console solves this problem. The console emulation will pin the buffer object only during updates from the shadow buffer. Otherwise, the bochs driver can freely relocated the buffer between system memory and video ram. v2: * select shadow FB via struct drm_mode_config.prefer_shadow_fbdev Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/315833/ Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 01 August 2019, 13:01:42 UTC
01b947a Thomas Zimmermann 05 July 2019, 07:31:00 UTC drm/fb-helper: Instanciate shadow FB if configured in device's mode_config Generic framebuffer emulation uses a shadow buffer for framebuffers with dirty() function. If drivers want to use the shadow FB without such a function, they can now set prefer_shadow or prefer_shadow_fbdev in their mode_config structures. The former flag is exported to userspace, the latter flag is fbdev-only. v3: * only schedule dirty worker if fbdev uses shadow fb * test shadow fb settings with boolean operators * use bool for struct drm_mode_config.prefer_shadow_fbdev * fix documentation comments Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/315834/ Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 01 August 2019, 13:01:35 UTC
87e281f Thomas Zimmermann 03 July 2019, 07:58:24 UTC drm/fb-helper: Map DRM client buffer only when required This patch changes DRM clients to not map the buffer by default. The buffer, like any buffer object, should be mapped and unmapped when needed. An unmapped buffer object can be evicted to system memory and does not consume video ram until displayed. This allows to use generic fbdev emulation with drivers for low-memory devices, such as ast and mgag200. This change affects the generic framebuffer console. HW-based consoles map their console buffer once and keep it mapped. Userspace can mmap this buffer into its address space. The shadow-buffered framebuffer console only needs the buffer object to be mapped during updates. While not being updated from the shadow buffer, the buffer object can remain unmapped. Userspace will always mmap the shadow buffer. v2: * change DRM client to not map buffer by default * manually map client buffer for fbdev with HW framebuffer Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/315830/ Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 01 August 2019, 13:01:29 UTC
back to top