user/sven/linux.git, branch v5.10.52

Linux 5.10.52

2021-07-20T14:05:59Z

Link: https://lore.kernel.org/r/20210719144940.904087935@linuxfoundation.org Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20210719184320.888029606@linuxfoundation.org Tested-by: Salvatore Bonaccorso Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Fox Chen Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

seq_file: disallow extremely large seq buffer allocations

2021-07-20T14:05:59Z

commit 8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b upstream. There is no reasonable need for a buffer larger than this, and it avoids int overflow pitfalls. Fixes: 058504edd026 ("fs/seq_file: fallback to vmalloc allocation") Suggested-by: Al Viro Reported-by: Qualys Security Advisory Signed-off-by: Eric Sandeen Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()

2021-07-20T14:05:59Z

commit 80927822e8b6be46f488524cd7d5fe683de97fc4 upstream. The "retval" variable needs to be signed for the error handling to work. Link: https://lore.kernel.org/r/YLjMEAFNxOas1mIp@mwanda Fixes: 7e26e3ea0287 ("scsi: scsi_dh_alua: Check for negative result value") Reviewed-by: Martin Wilck Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

MIPS: vdso: Invalid GIC access through VDSO

2021-07-20T14:05:59Z

[ Upstream commit 47ce8527fbba145a7723685bc9a27d9855e06491 ] Accessing raw timers (currently only CLOCK_MONOTONIC_RAW) through VDSO doesn't return the correct time when using the GIC as clock source. The address of the GIC mapped page is in this case not calculated correctly. The GIC mapped page is calculated from the VDSO data by subtracting PAGE_SIZE: void *get_gic(const struct vdso_data *data) { return (void __iomem *)data - PAGE_SIZE; } However, the data pointer is not page aligned for raw clock sources. This is because the VDSO data for raw clock sources (CS_RAW = 1) is stored after the VDSO data for coarse clock sources (CS_HRES_COARSE = 0). Therefore, only the VDSO data for CS_HRES_COARSE is page aligned: +--------------------+ | | | vd[CS_RAW] | ---+ | vd[CS_HRES_COARSE] | | +--------------------+ | -PAGE_SIZE | | | | GIC mapped page | <--+ | | +--------------------+ When __arch_get_hw_counter() is called with &vd[CS_RAW], get_gic returns the wrong address (somewhere inside the GIC mapped page). The GIC counter values are not returned which results in an invalid time. Fixes: a7f4df4e21dd ("MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()") Signed-off-by: Martin Fäcknitz Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

mips: disable branch profiling in boot/decompress.o

2021-07-20T14:05:58Z

[ Upstream commit 97e488073cfca0eea84450169ca4cbfcc64e33e3 ] Use DISABLE_BRANCH_PROFILING for arch/mips/boot/compressed/decompress.o to prevent linkage errors. mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `LZ4_decompress_fast_extDict': decompress.c:(.text+0x8c): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0xf4): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0x200): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0x230): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0x320): undefined reference to `ftrace_likely_update' mips64-linux-ld: arch/mips/boot/compressed/decompress.o:decompress.c:(.text+0x3f4): more undefined references to `ftrace_likely_update' follow Fixes: e76e1fdfa8f8 ("lib: add support for LZ4-compressed kernel") Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Thomas Bogendoerfer Cc: linux-mips@vger.kernel.org Cc: Kyungsik Lee Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

mips: always link byteswap helpers into decompressor

2021-07-20T14:05:58Z

[ Upstream commit cddc40f5617e53f97ef019d5b29c1bd6cbb031ec ] My series to clean up the unaligned access implementation across architectures caused some mips randconfig builds to fail with: mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `decompress_kernel': decompress.c:(.text.decompress_kernel+0x54): undefined reference to `__bswapsi2' It turns out that this problem has already been fixed for the XZ decompressor but now it also shows up in (at least) LZO and LZ4. From my analysis I concluded that the compiler could always have emitted those calls, but the different implementation allowed it to make otherwise better decisions about not inlining the byteswap, which results in the link error when the out-of-line code is missing. While it could be addressed by adding it to the two decompressor implementations that are known to be affected, but as this only adds 112 bytes to the kernel, the safer choice is to always add them. Fixes: c50ec6787536 ("MIPS: zboot: Fix the build with XZ compression on older GCC versions") Fixes: 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers") Link: https://lore.kernel.org/linux-mm/202106301304.gz2wVY9w-lkp@intel.com/ Link: https://lore.kernel.org/linux-mm/202106260659.TyMe8mjr-lkp@intel.com/ Link: https://lore.kernel.org/linux-mm/202106172016.onWT6Tza-lkp@intel.com/ Link: https://lore.kernel.org/linux-mm/202105231743.JJcALnhS-lkp@intel.com/ Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

static_call: Fix static_call_text_reserved() vs __init

2021-07-20T14:05:58Z

[ Upstream commit 2bee6d16e4379326b1eea454e68c98b17456769e ] It turns out that static_call_text_reserved() was reporting __init text as being reserved past the time when the __init text was freed and re-used. This is mostly harmless and will at worst result in refusing a kprobe. Fixes: 6333e8f73b83 ("static_call: Avoid kprobes on inline static_call()s") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Masami Hiramatsu Link: https://lore.kernel.org/r/20210628113045.106211657@infradead.org Signed-off-by: Sasha Levin

jump_label: Fix jump_label_text_reserved() vs __init

2021-07-20T14:05:58Z

[ Upstream commit 9e667624c291753b8a5128f620f493d0b5226063 ] It turns out that jump_label_text_reserved() was reporting __init text as being reserved past the time when the __init text was freed and re-used. For a long time, this resulted in, at worst, not being able to kprobe text that happened to land at the re-used address. However a recent commit e7bf1ba97afd ("jump_label, x86: Emit short JMP") made it a fatal mistake because it now needs to read the instruction in order to determine the conflict -- an instruction that's no longer there. Fixes: 4c3ef6d79328 ("jump label: Add jump_label_text_reserved() to reserve jump points") Reported-by: kernel test robot Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Masami Hiramatsu Link: https://lore.kernel.org/r/20210628113045.045141693@infradead.org Signed-off-by: Sasha Levin

sched/uclamp: Ignore max aggregation if rq is idle

2021-07-20T14:05:58Z

[ Upstream commit 3e1493f46390618ea78607cb30c58fc19e2a5035 ] When a task wakes up on an idle rq, uclamp_rq_util_with() would max aggregate with rq value. But since there is no task enqueued yet, the values are stale based on the last task that was running. When the new task actually wakes up and enqueued, then the rq uclamp values should reflect that of the newly woken up task effective uclamp values. This is a problem particularly for uclamp_max because it default to 1024. If a task p with uclamp_max = 512 wakes up, then max aggregation would ignore the capping that should apply when this task is enqueued, which is wrong. Fix that by ignoring max aggregation if the rq is idle since in that case the effective uclamp value of the rq will be the ones of the task that will wake up. Fixes: 9d20ad7dfc9a ("sched/uclamp: Add uclamp_util_with()") Signed-off-by: Xuewen Yan Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider [qias: Changelog] Reviewed-by: Qais Yousef Link: https://lore.kernel.org/r/20210630141204.8197-1-xuewen.yan94@gmail.com Signed-off-by: Sasha Levin

scsi: be2iscsi: Fix an error handling path in beiscsi_dev_probe()

2021-07-20T14:05:58Z

[ Upstream commit 030e4138d11fced3b831c2761e4cecf347bae99c ] If an error occurs after a pci_enable_pcie_error_reporting() call, it must be undone by a corresponding pci_disable_pcie_error_reporting() call, as already done in the remove function. Link: https://lore.kernel.org/r/77adb02cfea7f1364e5603ecf3930d8597ae356e.1623482155.git.christophe.jaillet@wanadoo.fr Fixes: 3567f36a09d1 ("[SCSI] be2iscsi: Fix AER handling in driver") Signed-off-by: Christophe JAILLET Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin