commit e23f129cafe7dc2c8bb0f30af505b796d9d9ae64 Author: Greg Kroah-Hartman Date: Sat Apr 10 13:39:01 2021 +0200 Linux 5.11.13 Tested-by: Guenter Roeck Tested-by: Shuah Khan Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210409095305.397149021@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit d0dfb9d3f250ddc9804448de02ceb02d4d34d3f7 Author: Masahiro Yamada Date: Fri Mar 12 21:07:08 2021 -0800 init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM commit ea29b20a828511de3348334e529a3d046a180416 upstream. I read the commit log of the following two: - bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on !UML") - 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390") Both are talking about HAS_IOMEM dependency missing in many drivers. So, 'depends on HAS_IOMEM' seems the direct, sensible solution to me. This does not change the behavior of UML. UML still cannot enable COMPILE_TEST because it does not provide HAS_IOMEM. The current dependency for S390 is too strong. Under the condition of CONFIG_PCI=y, S390 provides HAS_IOMEM, hence can enable COMPILE_TEST. I also removed the meaningless 'default n'. Link: https://lkml.kernel.org/r/20210224140809.1067582-1-masahiroy@kernel.org Signed-off-by: Masahiro Yamada Cc: Heiko Carstens Cc: Guenter Roeck Cc: Arnd Bergmann Cc: Kees Cook Cc: Daniel Borkmann Cc: Johannes Weiner Cc: KP Singh Cc: Nathan Chancellor Cc: Nick Terrell Cc: Quentin Perret Cc: Valentin Schneider Cc: "Enrico Weigelt, metux IT consult" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 7f6b5b8e03099559a3c05ce3715c147a1df90bbb Author: Piotr Krysiuk Date: Tue Apr 6 21:59:39 2021 +0100 bpf, x86: Validate computation of branch displacements for x86-32 commit 26f55a59dc65ff77cd1c4b37991e26497fc68049 upstream. The branch displacement logic in the BPF JIT compilers for x86 assumes that, for any generated branch instruction, the distance cannot increase between optimization passes. But this assumption can be violated due to how the distances are computed. Specifically, whenever a backward branch is processed in do_jit(), the distance is computed by subtracting the positions in the machine code from different optimization passes. This is because part of addrs[] is already updated for the current optimization pass, before the branch instruction is visited. And so the optimizer can expand blocks of machine code in some cases. This can confuse the optimizer logic, where it assumes that a fixed point has been reached for all machine code blocks once the total program size stops changing. And then the JIT compiler can output abnormal machine code containing incorrect branch displacements. To mitigate this issue, we assert that a fixed point is reached while populating the output image. This rejects any problematic programs. The issue affects both x86-32 and x86-64. We mitigate separately to ease backporting. Signed-off-by: Piotr Krysiuk Reviewed-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman commit b85b10dc8af463b59a732f299ade2612a8b950c9 Author: Piotr Krysiuk Date: Mon Apr 5 22:52:15 2021 +0100 bpf, x86: Validate computation of branch displacements for x86-64 commit e4d4d456436bfb2fe412ee2cd489f7658449b098 upstream. The branch displacement logic in the BPF JIT compilers for x86 assumes that, for any generated branch instruction, the distance cannot increase between optimization passes. But this assumption can be violated due to how the distances are computed. Specifically, whenever a backward branch is processed in do_jit(), the distance is computed by subtracting the positions in the machine code from different optimization passes. This is because part of addrs[] is already updated for the current optimization pass, before the branch instruction is visited. And so the optimizer can expand blocks of machine code in some cases. This can confuse the optimizer logic, where it assumes that a fixed point has been reached for all machine code blocks once the total program size stops changing. And then the JIT compiler can output abnormal machine code containing incorrect branch displacements. To mitigate this issue, we assert that a fixed point is reached while populating the output image. This rejects any problematic programs. The issue affects both x86-32 and x86-64. We mitigate separately to ease backporting. Signed-off-by: Piotr Krysiuk Reviewed-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman commit f4fa197e6b1d11ad732714ef6e8a4b7d2b0fd75e Author: Stanislav Fomichev Date: Thu Feb 11 17:00:53 2021 -0800 tools/resolve_btfids: Add /libbpf to .gitignore [ Upstream commit 90a82b1fa40d0cee33d1c9306dc54412442d1e57 ] This is what I see after compiling the kernel: # bpf-next...bpf-next/master ?? tools/bpf/resolve_btfids/libbpf/ Fixes: fc6b48f692f8 ("tools/resolve_btfids: Build libbpf and libsubcmd in separate directories") Signed-off-by: Stanislav Fomichev Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210212010053.668700-1-sdf@google.com Signed-off-by: Sasha Levin commit 13ddfcbdd64b4254de802aa910b95d87a755292f Author: Jiri Olsa Date: Thu Feb 11 13:40:04 2021 +0100 kbuild: Do not clean resolve_btfids if the output does not exist [ Upstream commit 0e1aa629f1ce9e8cb89e0cefb9e3bfb3dfa94821 ] Nathan reported issue with cleaning empty build directory: $ make -s O=build distclean ../../scripts/Makefile.include:4: *** \ O=/ho...build/tools/bpf/resolve_btfids does not exist. Stop. The problem that tools scripts require existing output directory, otherwise it fails. Adding check around the resolve_btfids clean target to ensure the output directory is in place. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Tested-by: Nathan Chancellor Link: https://lore.kernel.org/bpf/20210211124004.1144344-1-jolsa@kernel.org Signed-off-by: Sasha Levin commit a9b54a282bcdefc6b69cc35efd66a62f5abf0525 Author: Jiri Olsa Date: Fri Feb 5 13:40:20 2021 +0100 kbuild: Add resolve_btfids clean to root clean target [ Upstream commit 50d3a3f81689586697a38cd60070181ebe626ad9 ] The resolve_btfids tool is used during the kernel build, so we should clean it on kernel's make clean. Invoking the the resolve_btfids clean as part of root 'make clean'. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20210205124020.683286-5-jolsa@kernel.org Signed-off-by: Sasha Levin commit bd6391b8732c6be070d64be7496e3abbc49952a7 Author: Jiri Olsa Date: Fri Feb 5 13:40:19 2021 +0100 tools/resolve_btfids: Set srctree variable unconditionally [ Upstream commit 7962cb9b640af98ccb577f46c8b894319e6c5c20 ] We want this clean to be called from tree's root Makefile, which defines same srctree variable and that will screw the make setup. We actually do not use srctree being passed from outside, so we can solve this by setting current srctree value directly. Also changing the way how srctree is initialized as suggested by Andrri. Also root Makefile does not define the implicit RM variable, so adding RM initialization. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210205124020.683286-4-jolsa@kernel.org Signed-off-by: Sasha Levin commit d1db79f5a4cfbf0fdaf182554d44dab112b0f612 Author: Jiri Olsa Date: Fri Feb 5 13:40:18 2021 +0100 tools/resolve_btfids: Check objects before removing [ Upstream commit f23130979c2f15ea29a431cd9e1ea7916337bbd4 ] We want this clean to be called from tree's root clean and that one is silent if there's nothing to clean. Adding check for all object to clean and display CLEAN messages only if there are objects to remove. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210205124020.683286-3-jolsa@kernel.org Signed-off-by: Sasha Levin commit 5c14a915e0464eb25a34256cbf8760ac15d8488d Author: Jiri Olsa Date: Fri Feb 5 13:40:17 2021 +0100 tools/resolve_btfids: Build libbpf and libsubcmd in separate directories [ Upstream commit fc6b48f692f89cc48bfb7fd1aa65454dfe9b2d77 ] Setting up separate build directories for libbpf and libpsubcmd, so it's separated from other objects and we don't get them mixed in the future. It also simplifies cleaning, which is now simple rm -rf. Also there's no need for FEATURE-DUMP.libbpf and bpf_helper_defs.h files in .gitignore anymore. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Acked-by: Song Liu Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210205124020.683286-2-jolsa@kernel.org Signed-off-by: Sasha Levin commit 079287a8e677f828469918217c40be5c9b87f790 Author: David S. Miller Date: Wed Mar 24 16:42:54 2021 -0700 math: Export mul_u64_u64_div_u64 [ Upstream commit bf45947864764548697e7515fe693e10f173f312 ] Fixes: f51d7bf1dbe5 ("ptp_qoriq: fix overflow in ptp_qoriq_adjfine() u64 calcalation") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1cabe1b0bd5fb6493777a724732d0f01225491be Author: Pavel Begunkov Date: Thu Mar 25 18:32:42 2021 +0000 io_uring: fix timeout cancel return code [ Upstream commit 1ee4160c73b2102a52bc97a4128a89c34821414f ] When we cancel a timeout we should emit a sensible return code, like -ECANCELED but not 0, otherwise it may trick users. Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/7b0ad1065e3bd1994722702bd0ba9e7bc9b0683b.1616696997.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit fabd7beaa06cf8b009b46dd6345255b103c0026c Author: Vincent Whitchurch Date: Fri Mar 19 14:57:11 2021 +0100 cifs: Silently ignore unknown oplock break handle [ Upstream commit 219481a8f90ec3a5eed9638fb35609e4b1aeece7 ] Make SMB2 not print out an error when an oplock break is received for an unknown handle, similar to SMB1. The debug message which is printed for these unknown handles may also be misleading, so fix that too. The SMB2 lease break path is not affected by this patch. Without this, a program which writes to a file from one thread, and opens, reads, and writes the same file from another thread triggers the below errors several times a minute when run against a Samba server configured with "smb2 leases = no". CIFS: VFS: \\192.168.0.1 No task to wake, unknown frame received! NumMids 2 00000000: 424d53fe 00000040 00000000 00000012 .SMB@........... 00000010: 00000001 00000000 ffffffff ffffffff ................ 00000020: 00000000 00000000 00000000 00000000 ................ 00000030: 00000000 00000000 00000000 00000000 ................ Signed-off-by: Vincent Whitchurch Reviewed-by: Tom Talpey Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit a6c4223bbd4b367c6039f1818972940e07e3f2c1 Author: Ronnie Sahlberg Date: Thu Mar 25 16:26:35 2021 +1000 cifs: revalidate mapping when we open files for SMB1 POSIX [ Upstream commit cee8f4f6fcabfdf229542926128e9874d19016d5 ] RHBZ: 1933527 Under SMB1 + POSIX, if an inode is reused on a server after we have read and cached a part of a file, when we then open the new file with the re-cycled inode there is a chance that we may serve the old data out of cache to the application. This only happens for SMB1 (deprecated) and when posix are used. The simplest solution to avoid this race is to force a revalidate on smb1-posix open. Signed-off-by: Ronnie Sahlberg Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 28d95f1bf41459b8e969cc789bd027c809c47ed1 Author: Sergei Trofimovich Date: Wed Mar 24 21:37:41 2021 -0700 ia64: fix format strings for err_inject [ Upstream commit 95d44a470a6814207d52dd6312203b0f4ef12710 ] Fix warning with %lx / u64 mismatch: arch/ia64/kernel/err_inject.c: In function 'show_resources': arch/ia64/kernel/err_inject.c:62:22: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'u64' {aka 'long long unsigned int'} 62 | return sprintf(buf, "%lx", name[cpu]); \ | ^~~~~~~ Link: https://lkml.kernel.org/r/20210313104312.1548232-1-slyfox@gentoo.org Signed-off-by: Sergei Trofimovich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7dd54a85ecf5bc037d494beb6fdf7ffcd4b3f050 Author: Sergei Trofimovich Date: Wed Mar 24 21:37:38 2021 -0700 ia64: mca: allocate early mca with GFP_ATOMIC [ Upstream commit f2a419cf495f95cac49ea289318b833477e1a0e2 ] The sleep warning happens at early boot right at secondary CPU activation bootup: smp: Bringing up secondary CPUs ... BUG: sleeping function called from invalid context at mm/page_alloc.c:4942 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.12.0-rc2-00007-g79e228d0b611-dirty #99 .. Call Trace: show_stack+0x90/0xc0 dump_stack+0x150/0x1c0 ___might_sleep+0x1c0/0x2a0 __might_sleep+0xa0/0x160 __alloc_pages_nodemask+0x1a0/0x600 alloc_page_interleave+0x30/0x1c0 alloc_pages_current+0x2c0/0x340 __get_free_pages+0x30/0xa0 ia64_mca_cpu_init+0x2d0/0x3a0 cpu_init+0x8b0/0x1440 start_secondary+0x60/0x700 start_ap+0x750/0x780 Fixed BSP b0 value from CPU 1 As I understand interrupts are not enabled yet and system has a lot of memory. There is little chance to sleep and switch to GFP_ATOMIC should be a no-op. Link: https://lkml.kernel.org/r/20210315085045.204414-1-slyfox@gentoo.org Signed-off-by: Sergei Trofimovich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a18e5bc5641ededba2a85fc8cc75dd1355795ac5 Author: Rong Chen Date: Wed Mar 24 21:37:26 2021 -0700 selftests/vm: fix out-of-tree build [ Upstream commit 19ec368cbc7ee1915e78c120b7a49c7f14734192 ] When building out-of-tree, attempting to make target from $(OUTPUT) directory: make[1]: *** No rule to make target '$(OUTPUT)/protection_keys.c', needed by '$(OUTPUT)/protection_keys_32'. Link: https://lkml.kernel.org/r/20210315094700.522753-1-rong.a.chen@intel.com Signed-off-by: Rong Chen Reported-by: kernel test robot Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 45d73636ca28c03274cb6008b881a9de5d0859af Author: Rich Wiley Date: Tue Mar 23 17:28:09 2021 -0700 arm64: kernel: disable CNP on Carmel [ Upstream commit 20109a859a9b514eb10c22b8a14b5704ffe93897 ] On NVIDIA Carmel cores, CNP behaves differently than it does on standard ARM cores. On Carmel, if two cores have CNP enabled and share an L2 TLB entry created by core0 for a specific ASID, a non-shareable TLBI from core1 may still see the shared entry. On standard ARM cores, that TLBI will invalidate the shared entry as well. This causes issues with patchsets that attempt to do local TLBIs based on cpumasks instead of broadcast TLBIs. Avoid these issues by disabling CNP support for NVIDIA Carmel cores. Signed-off-by: Rich Wiley Link: https://lore.kernel.org/r/20210324002809.30271-1-rwiley@nvidia.com [will: Fix pre-existing whitespace issue] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit dc992077faea40161c24f25f613f9fb6fda6828c Author: Martin Wilck Date: Tue Mar 23 22:24:31 2021 +0100 scsi: target: pscsi: Clean up after failure in pscsi_map_sg() [ Upstream commit 36fa766faa0c822c860e636fe82b1affcd022974 ] If pscsi_map_sg() fails, make sure to drop references to already allocated bios. Link: https://lore.kernel.org/r/20210323212431.15306-2-mwilck@suse.com Reviewed-by: Christoph Hellwig Reviewed-by: Lee Duncan Signed-off-by: Martin Wilck Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bd7ab3de86d8f07de76a8112f4fafcbc725d2f68 Author: Yangbo Lu Date: Tue Mar 23 16:02:29 2021 +0800 ptp_qoriq: fix overflow in ptp_qoriq_adjfine() u64 calcalation [ Upstream commit f51d7bf1dbe5522c51c93fe8faa5f4abbdf339cd ] Current calculation for diff of TMR_ADD register value may have 64-bit overflow in this code line, when long type scaled_ppm is large. adj *= scaled_ppm; This patch is to resolve it by using mul_u64_u64_div_u64(). Signed-off-by: Yangbo Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d8c2946f398ecb1fbf7e955eca69d701e04224ea Author: David E. Box Date: Fri Mar 19 13:18:44 2021 -0700 platform/x86: intel_pmc_core: Ignore GBE LTR on Tiger Lake platforms [ Upstream commit d1635448f1105e549b4041aab930dbc6945fc635 ] Due to a HW limitation, the Latency Tolerance Reporting (LTR) value programmed in the Tiger Lake GBE controller is not large enough to allow the platform to enter Package C10, which in turn prevents the platform from achieving its low power target during suspend-to-idle. Ignore the GBE LTR value on Tiger Lake. LTR ignore functionality is currently performed solely by a debugfs write call. Split out the LTR code into its own function that can be called by both the debugfs writer and by this work around. Signed-off-by: David E. Box Reviewed-by: Sasha Neftin Cc: intel-wired-lan@lists.osuosl.org Reviewed-by: Rajneesh Bhardwaj Link: https://lore.kernel.org/r/20210319201844.3305399-2-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 0e6115b6a586211d9e7499d66bc66caba57bafeb Author: David E. Box Date: Tue Mar 16 19:44:54 2021 -0700 platform/x86: intel_pmt_class: Initial resource to 0 [ Upstream commit 7547deff8a221e6bf1e563cf1b636844a8e5378a ] Initialize the struct resource in intel_pmt_dev_register to zero to avoid a fault should the char *name field be non-zero. Signed-off-by: David E. Box Link: https://lore.kernel.org/r/20210317024455.3071477-1-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 278a13a8feb8a62a7ab35e87545f07eacfd4a02b Author: Chris Chiu Date: Tue Mar 23 16:52:19 2021 +0800 block: clear GD_NEED_PART_SCAN later in bdev_disk_changed [ Upstream commit 5116784039f0421e9a619023cfba3e302c3d9adc ] The GD_NEED_PART_SCAN is set by bdev_check_media_change to initiate a partition scan while removing a block device. It should be cleared after blk_drop_paritions because blk_drop_paritions could return -EBUSY and then the consequence __blkdev_get has no chance to do delete_partition if GD_NEED_PART_SCAN already cleared. It causes some problems on some card readers. Ex. Realtek card reader 0bda:0328 and 0bda:0158. The device node of the partition will not disappear after the memory card removed. Thus the user applications can not update the device mapping correctly. BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1920874 Signed-off-by: Chris Chiu Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20210323085219.24428-1-chris.chiu@canonical.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6af7471b713d40efa4207c97be8e11c376ca041c Author: Arnd Bergmann Date: Tue Mar 23 13:48:36 2021 +0100 x86/build: Turn off -fcf-protection for realmode targets [ Upstream commit 9fcb51c14da2953de585c5c6e50697b8a6e91a7b ] The new Ubuntu GCC packages turn on -fcf-protection globally, which causes a build failure in the x86 realmode code: cc1: error: ‘-fcf-protection’ is not compatible with this target Turn it off explicitly on compilers that understand this option. Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210323124846.1584944-1-arnd@kernel.org Signed-off-by: Sasha Levin commit b0b8f8799dd108e72ac33f2df78ca08aec67218b Author: Kalyan Thota Date: Mon Mar 22 02:17:12 2021 -0700 drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume [ Upstream commit 627dc55c273dab308303a5217bd3e767d7083ddb ] DPU runtime resume will request for a min vote on the AXI bus as it is a necessary step before turning ON the AXI clock. The change does below 1) Move the icc path set before requesting runtime get_sync. 2) remove the dependency of hw catalog for min ib vote as it is initialized at a later point. Signed-off-by: Kalyan Thota Tested-by: Matthias Kaehlcke Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit e6aedd5c8da32a6bc3ed22024117aedbd7dbc1b7 Author: Andre Przywara Date: Fri Mar 19 12:01:28 2021 +0000 kselftest/arm64: sve: Do not use non-canonical FFR register value [ Upstream commit 7011d72588d16a9e5f5d85acbc8b10019809599c ] The "First Fault Register" (FFR) is an SVE register that mimics a predicate register, but clears bits when a load or store fails to handle an element of a vector. The supposed usage scenario is to initialise this register (using SETFFR), then *read* it later on to learn about elements that failed to load or store. Explicit writes to this register using the WRFFR instruction are only supposed to *restore* values previously read from the register (for context-switching only). As the manual describes, this register holds only certain values, it: "... contains a monotonic predicate value, in which starting from bit 0 there are zero or more 1 bits, followed only by 0 bits in any remaining bit positions." Any other value is UNPREDICTABLE and is not supposed to be "restored" into the register. The SVE test currently tries to write a signature pattern into the register, which is *not* a canonical FFR value. Apparently the existing setups treat UNPREDICTABLE as "read-as-written", but a new implementation actually only stores canonical values. As a consequence, the sve-test fails immediately when comparing the FFR value: ----------- # ./sve-test Vector length: 128 bits PID: 207 Mismatch: PID=207, iteration=0, reg=48 Expected [cf00] Got [0f00] Aborted ----------- Fix this by only populating the FFR with proper canonical values. Effectively the requirement described above limits us to 17 unique values over 16 bits worth of FFR, so we condense our signature down to 4 bits (2 bits from the PID, 2 bits from the generation) and generate the canonical pattern from it. Any bits describing elements above the minimum 128 bit are set to 0. This aligns the FFR usage to the architecture and fixes the test on microarchitectures implementing FFR in a more restricted way. Signed-off-by: Andre Przywara Reviwed-by: Mark Brown Link: https://lore.kernel.org/r/20210319120128.29452-1-andre.przywara@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit df885c2a19b227ca51316812556e62e65e840f32 Author: Esteve Varela Colominas Date: Mon Mar 15 20:58:24 2021 +0100 platform/x86: thinkpad_acpi: Allow the FnLock LED to change state [ Upstream commit 3d677f12ea3a2097a16ded570623567403dea959 ] On many recent ThinkPad laptops, there's a new LED next to the ESC key, that indicates the FnLock status. When the Fn+ESC combo is pressed, FnLock is toggled, which causes the Media Key functionality to change, making it so that the media keys either perform their media key function, or function as an F-key by default. The Fn key can be used the access the alternate function at any time. With the current linux kernel, the LED doens't change state if you press the Fn+ESC key combo. However, the media key functionality *does* change. This is annoying, since the LED will stay on if it was on during bootup, and it makes it hard to keep track what the current state of the FnLock is. This patch calls an ACPI function, that gets the current media key state, when the Fn+ESC key combo is pressed. Through testing it was discovered that this function causes the LED to update correctly to reflect the current state when this function is called. The relevant ACPI calls are the following: \_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key state, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled. \_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key state, sending a 1 will enable FnLock mode, and a 0 will disable it. Relevant discussion: https://bugzilla.kernel.org/show_bug.cgi?id=207841 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015 Signed-off-by: Esteve Varela Colominas Link: https://lore.kernel.org/r/20210315195823.23212-1-esteve.varela@gmail.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 519ec6848150ec2b20fe33ceed3de927007ba0b5 Author: Alex Elder Date: Sat Mar 20 09:17:28 2021 -0500 net: ipa: fix init header command validation [ Upstream commit b4afd4b90a7cfe54c7cd9db49e3c36d552325eac ] We use ipa_cmd_header_valid() to ensure certain values we will program into hardware are within range, well in advance of when we actually program them. This way we avoid having to check for errors when we actually program the hardware. Unfortunately the dev_err() call for a bad offset value does not supply the arguments to match the format specifiers properly. Fix this. There was also supposed to be a check to ensure the size to be programmed fits in the field that holds it. Add this missing check. Rearrange the way we ensure the header table fits in overall IPA memory range. Finally, update ipa_cmd_table_valid() so the format of messages printed for errors matches what's done in ipa_cmd_header_valid(). Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4beb229ad5f055779e336e4d55a0788b6c77344b Author: Pablo Neira Ayuso Date: Wed Mar 17 21:19:57 2021 +0100 netfilter: nftables: skip hook overlap logic if flowtable is stale [ Upstream commit 86fe2c19eec4728fd9a42ba18f3b47f0d5f9fd7c ] If the flowtable has been previously removed in this batch, skip the hook overlap checks. This fixes spurious EEXIST errors when removing and adding the flowtable in the same batch. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0b62d6d2bea70bb274f69ff3da469bf81b4922ef Author: Ludovic Senecaux Date: Thu Mar 4 04:10:50 2021 -0500 netfilter: conntrack: Fix gre tunneling over ipv6 [ Upstream commit 8b2030b4305951f44afef80225f1475618e25a73 ] This fix permits gre connections to be tracked within ip6tables rules Signed-off-by: Ludovic Senecaux Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e10e4ac5628c835f489394341d78fe9f0e848f68 Author: Rob Clark Date: Wed Mar 17 09:40:38 2021 -0700 drm/msm: Ratelimit invalid-fence message [ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ] We have seen a couple cases where low memory situations cause something bad to happen, followed by a flood of these messages obscuring the root cause. Lets ratelimit the dmesg spam so that next time it happens we don't lose the kernel traces leading up to this. Signed-off-by: Rob Clark Reviewed-by: Douglas Anderson Signed-off-by: Sasha Levin commit c80036a7c7ed451e906e7903fc5547dc3cac8c77 Author: Konrad Dybcio Date: Sun Feb 28 13:36:51 2021 +0100 drm/msm/adreno: a5xx_power: Don't apply A540 lm_setup to other GPUs [ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ] While passing the A530-specific lm_setup func to A530 and A540 to !A530 was fine back when only these two were supported, it certainly is not a good idea to send A540 specifics to smaller GPUs like A508 and friends. Signed-off-by: Konrad Dybcio Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 82f75a45695c96d60124c1b3cca8afa986764c10 Author: Dmitry Baryshkov Date: Thu Feb 25 02:05:28 2021 +0300 drm/msm/dsi_pll_7nm: Fix variable usage for pll_lockdet_rate [ Upstream commit 9daaf31307856defb1070685418ce5a484ecda3a ] The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value directly, but the same value was also being specified in the dsi_pll_regs struct pll_lockdet_rate variable: let's use it! Based on 362cadf34b9f ("drm/msm/dsi_pll_10nm: Fix variable usage for pll_lockdet_rate") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 61e3154889590cefcf739ab8e8b939ea30653682 Author: Karthikeyan Kathirvel Date: Thu Mar 11 10:59:07 2021 +0530 mac80211: choose first enabled channel for monitor [ Upstream commit 041c881a0ba8a75f71118bd9766b78f04beed469 ] Even if the first channel from sband channel list is invalid or disabled mac80211 ends up choosing it as the default channel for monitor interfaces, making them not usable. Fix this by assigning the first available valid or enabled channel instead. Signed-off-by: Karthikeyan Kathirvel Link: https://lore.kernel.org/r/1615440547-7661-1-git-send-email-kathirve@codeaurora.org [reword commit message, comment, code cleanups] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 26ca8f7fda08c8ce8e18a35f87481043d083b362 Author: Daniel Phan Date: Tue Mar 9 12:41:36 2021 -0800 mac80211: Check crypto_aead_encrypt for errors [ Upstream commit 58d25626f6f0ea5bcec3c13387b9f835d188723d ] crypto_aead_encrypt returns <0 on error, so if these calls are not checked, execution may continue with failed encrypts. It also seems that these two crypto_aead_encrypt calls are the only instances in the codebase that are not checked for errors. Signed-off-by: Daniel Phan Link: https://lore.kernel.org/r/20210309204137.823268-1-daniel.phan36@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 311cd0c8dbdc3b68bbf8a113ba53660f31167630 Author: Jimmy Assarsson Date: Tue Mar 9 10:17:24 2021 +0100 can: kvaser_usb: Add support for USBcan Pro 4xHS [ Upstream commit 7507479c46b120c37ef83e59be7683a526e98e1a ] Add support for Kvaser USBcan Pro 4xHS. Link: https://lore.kernel.org/r/20210309091724.31262-2-jimmyassarsson@gmail.com Signed-off-by: Jimmy Assarsson Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 643fed80fca6503a6cce4e11a599e2c6b8971c92 Author: Tong Zhang Date: Sun Mar 14 14:08:36 2021 -0400 net: arcnet: com20020 fix error handling [ Upstream commit 6577b9a551aedb86bca6d4438c28386361845108 ] There are two issues when handling error case in com20020pci_probe() 1. priv might be not initialized yet when calling com20020pci_remove() from com20020pci_probe(), since the priv is set at the very last but it can jump to error handling in the middle and priv remains NULL. 2. memory leak - the net device is allocated in alloc_arcdev but not properly released if error happens in the middle of the big for loop [ 1.529110] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 1.531447] RIP: 0010:com20020pci_remove+0x15/0x60 [com20020_pci] [ 1.536805] Call Trace: [ 1.536939] com20020pci_probe+0x3f2/0x48c [com20020_pci] [ 1.537226] local_pci_probe+0x48/0x80 [ 1.539918] com20020pci_init+0x3f/0x1000 [com20020_pci] Signed-off-by: Tong Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 10d940e77afdd8ee7b909b01b850339e0345fa95 Author: Tong Zhang Date: Wed Mar 10 23:27:35 2021 -0500 mISDN: fix crash in fritzpci [ Upstream commit a9f81244d2e33e6dfcef120fefd30c96b3f7cdb0 ] setup_fritz() in avmfritz.c might fail with -EIO and in this case the isac.type and isac.write_reg is not initialized and remains 0(NULL). A subsequent call to isac_release() will dereference isac->write_reg and crash. [ 1.737444] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.737809] #PF: supervisor instruction fetch in kernel mode [ 1.738106] #PF: error_code(0x0010) - not-present page [ 1.738378] PGD 0 P4D 0 [ 1.738515] Oops: 0010 [#1] SMP NOPTI [ 1.738711] CPU: 0 PID: 180 Comm: systemd-udevd Not tainted 5.12.0-rc2+ #78 [ 1.739077] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-p rebuilt.qemu.org 04/01/2014 [ 1.739664] RIP: 0010:0x0 [ 1.739807] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [ 1.740200] RSP: 0018:ffffc9000027ba10 EFLAGS: 00010202 [ 1.740478] RAX: 0000000000000000 RBX: ffff888102f41840 RCX: 0000000000000027 [ 1.740853] RDX: 00000000000000ff RSI: 0000000000000020 RDI: ffff888102f41800 [ 1.741226] RBP: ffffc9000027ba20 R08: ffff88817bc18440 R09: ffffc9000027b808 [ 1.741600] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888102f41840 [ 1.741976] R13: 00000000fffffffb R14: ffff888102f41800 R15: ffff8881008b0000 [ 1.742351] FS: 00007fda3a38a8c0(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 [ 1.742774] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.743076] CR2: ffffffffffffffd6 CR3: 00000001021ec000 CR4: 00000000000006f0 [ 1.743452] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1.743828] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1.744206] Call Trace: [ 1.744339] isac_release+0xcc/0xe0 [mISDNipac] [ 1.744582] fritzpci_probe.cold+0x282/0x739 [avmfritz] [ 1.744861] local_pci_probe+0x48/0x80 [ 1.745063] pci_device_probe+0x10f/0x1c0 [ 1.745278] really_probe+0xfb/0x420 [ 1.745471] driver_probe_device+0xe9/0x160 [ 1.745693] device_driver_attach+0x5d/0x70 [ 1.745917] __driver_attach+0x8f/0x150 [ 1.746123] ? device_driver_attach+0x70/0x70 [ 1.746354] bus_for_each_dev+0x7e/0xc0 [ 1.746560] driver_attach+0x1e/0x20 [ 1.746751] bus_add_driver+0x152/0x1f0 [ 1.746957] driver_register+0x74/0xd0 [ 1.747157] ? 0xffffffffc00d8000 [ 1.747334] __pci_register_driver+0x54/0x60 [ 1.747562] AVM_init+0x36/0x1000 [avmfritz] [ 1.747791] do_one_initcall+0x48/0x1d0 [ 1.747997] ? __cond_resched+0x19/0x30 [ 1.748206] ? kmem_cache_alloc_trace+0x390/0x440 [ 1.748458] ? do_init_module+0x28/0x250 [ 1.748669] do_init_module+0x62/0x250 [ 1.748870] load_module+0x23ee/0x26a0 [ 1.749073] __do_sys_finit_module+0xc2/0x120 [ 1.749307] ? __do_sys_finit_module+0xc2/0x120 [ 1.749549] __x64_sys_finit_module+0x1a/0x20 [ 1.749782] do_syscall_64+0x38/0x90 Signed-off-by: Tong Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 262703c38c896e1547954f719d13aee462a3d7c4 Author: David Gow Date: Mon Feb 22 21:49:30 2021 -0800 kunit: tool: Fix a python tuple typing error [ Upstream commit 7421b1a4d10c633ca5f14c8236d3e2c1de07e52b ] The first argument to namedtuple() should match the name of the type, which wasn't the case for KconfigEntryBase. Fixing this is enough to make mypy show no python typing errors again. Fixes 97752c39bd ("kunit: kunit_tool: Allow .kunitconfig to disable config items") Signed-off-by: David Gow Reviewed-by: Daniel Latypov Acked-by: Brendan Higgins Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit d86a9741f81f1f4c3a5d212dffd8fbe753fe2190 Author: Pavel Andrianov Date: Wed Mar 10 11:10:46 2021 +0300 net: pxa168_eth: Fix a potential data race in pxa168_eth_remove [ Upstream commit 0571a753cb07982cc82f4a5115e0b321da89e1f3 ] pxa168_eth_remove() firstly calls unregister_netdev(), then cancels a timeout work. unregister_netdev() shuts down a device interface and removes it from the kernel tables. If the timeout occurs in parallel, the timeout work (pxa168_eth_tx_timeout_task) performs stop and open of the device. It may lead to an inconsistent state and memory leaks. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Pavel Andrianov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ed61675f436e86c7c4dcc6b7ebc164d8b341426 Author: Tariq Toukan Date: Tue Jan 12 13:29:14 2021 +0200 net/mlx5e: Enforce minimum value check for ICOSQ size [ Upstream commit 5115daa675ccf70497fe56e8916cf738d8212c10 ] The ICOSQ size should not go below MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE. Enforce this where it's missing. Signed-off-by: Tariq Toukan Reviewed-by: Maxim Mikityanskiy Reviewed-by: Saeed Mahameed Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 4be588ad4e90b7d730370b60784e0841b84371af Author: Yonghong Song Date: Mon Mar 8 17:56:47 2021 -0800 bpf, x86: Use kvmalloc_array instead kmalloc_array in bpf_jit_comp [ Upstream commit de920fc64cbaa031f947e9be964bda05fd090380 ] x86 bpf_jit_comp.c used kmalloc_array to store jited addresses for each bpf insn. With a large bpf program, we have see the following allocation failures in our production server: page allocation failure: order:5, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0" Call Trace: dump_stack+0x50/0x70 warn_alloc.cold.120+0x72/0xd2 ? __alloc_pages_direct_compact+0x157/0x160 __alloc_pages_slowpath+0xcdb/0xd00 ? get_page_from_freelist+0xe44/0x1600 ? vunmap_page_range+0x1ba/0x340 __alloc_pages_nodemask+0x2c9/0x320 kmalloc_order+0x18/0x80 kmalloc_order_trace+0x1d/0xa0 bpf_int_jit_compile+0x1e2/0x484 ? kmalloc_order_trace+0x1d/0xa0 bpf_prog_select_runtime+0xc3/0x150 bpf_prog_load+0x480/0x720 ? __mod_memcg_lruvec_state+0x21/0x100 __do_sys_bpf+0xc31/0x2040 ? close_pdeo+0x86/0xe0 do_syscall_64+0x42/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f2f300f7fa9 Code: Bad RIP value. Dumped assembly: ffffffff810b6d70 : ; { ffffffff810b6d70: e8 eb a5 b4 00 callq 0xffffffff81c01360 <__fentry__> ffffffff810b6d75: 41 57 pushq %r15 ... ffffffff810b6f39: e9 72 fe ff ff jmp 0xffffffff810b6db0 ; addrs = kmalloc_array(prog->len + 1, sizeof(*addrs), GFP_KERNEL); ffffffff810b6f3e: 8b 45 0c movl 12(%rbp), %eax ; return __kmalloc(bytes, flags); ffffffff810b6f41: be c0 0c 00 00 movl $3264, %esi ; addrs = kmalloc_array(prog->len + 1, sizeof(*addrs), GFP_KERNEL); ffffffff810b6f46: 8d 78 01 leal 1(%rax), %edi ; if (unlikely(check_mul_overflow(n, size, &bytes))) ffffffff810b6f49: 48 c1 e7 02 shlq $2, %rdi ; return __kmalloc(bytes, flags); ffffffff810b6f4d: e8 8e 0c 1d 00 callq 0xffffffff81287be0 <__kmalloc> ; if (!addrs) { ffffffff810b6f52: 48 85 c0 testq %rax, %rax Change kmalloc_array() to kvmalloc_array() to avoid potential allocation error for big bpf programs. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210309015647.3657852-1-yhs@fb.com Signed-off-by: Sasha Levin commit 0ea2f3f11986b622d8e31690c5ff07edf60aa8f2 Author: Alban Bedel Date: Mon Feb 22 15:15:59 2021 +0100 platform/x86: intel-hid: Support Lenovo ThinkPad X1 Tablet Gen 2 [ Upstream commit 56678a5f44ef5f0ad9a67194bbee2280c6286534 ] Like a few other system the Lenovo ThinkPad X1 Tablet Gen 2 miss the HEBC method, which prevent the power button from working. Add a quirk to enable the button array on this system family and fix the power button. Signed-off-by: Alban Bedel Tested-by: Alexander Kobel Link: https://lore.kernel.org/r/20210222141559.3775-1-albeu@free.fr Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit ef817ce653db835a0123225d3eda0a7243b18dc2 Author: Jordan Crouse Date: Tue Feb 9 17:52:05 2021 -0700 drm/msm: a6xx: Make sure the SQE microcode is safe [ Upstream commit 8490f02a3ca45fd1bbcadc243b4db9b69d0e3450 ] Most a6xx targets have security issues that were fixed with new versions of the microcode(s). Make sure that we are booting with a safe version of the microcode for the target and print a message and error if not. v2: Add more informative error messages and fix typos Signed-off-by: Jordan Crouse Reviewed-by: Akhil P Oommen Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 17d24f98fd2e265bd4d3f280d8156118dd19334f Author: Tony Lindgren Date: Thu Feb 18 13:06:57 2021 +0200 bus: ti-sysc: Fix warning on unbind if reset is not deasserted [ Upstream commit a7b5d7c4969aba8d1f04c29048906abaa71fb6a9 ] We currently get thefollowing on driver unbind if a reset is configured and asserted: WARNING: CPU: 0 PID: 993 at drivers/reset/core.c:432 reset_control_assert ... (reset_control_assert) from [] (sysc_remove+0x190/0x1e4) (sysc_remove) from [] (platform_remove+0x24/0x3c) (platform_remove) from [] (__device_release_driver+0x154/0x214) (__device_release_driver) from [] (device_driver_detach+0x3c/0x8c) (device_driver_detach) from [] (unbind_store+0x60/0xd4) (unbind_store) from [] (kernfs_fop_write_iter+0x10c/0x1cc) Let's fix it by checking the reset status. Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 873ddf720b835bbf3ad3851aa2e4b2e1b833ba96 Author: Mans Rullgard Date: Thu Jan 28 15:56:44 2021 +0000 ARM: dts: am33xx: add aliases for mmc interfaces [ Upstream commit 9bbce32a20d6a72c767a7f85fd6127babd1410ac ] Without DT aliases, the numbering of mmc interfaces is unpredictable. Adding them makes it possible to refer to devices consistently. The popular suggestion to use UUIDs obviously doesn't work with a blank device fresh from the factory. See commit fa2d0aa96941 ("mmc: core: Allow setting slot index via device tree alias") for more discussion. Signed-off-by: Mans Rullgard Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin