forked from ananjaser1211/Apollo
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge duhan_test into duhan_5.1 #1
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
commit 1e1b6d63d6340764e00356873e5794225a2a03ea upstream. LLVM implemented a recent "libcall optimization" that lowers calls to `sprintf(dest, "%s", str)` where the return value is used to `stpcpy(dest, str) - dest`. This generally avoids the machinery involved in parsing format strings. `stpcpy` is just like `strcpy` except it returns the pointer to the new tail of `dest`. This optimization was introduced into clang-12. Implement this so that we don't observe linkage failures due to missing symbol definitions for `stpcpy`. Similar to last year's fire drill with: commit 5f074f3e192f ("lib/string.c: implement a basic bcmp") The kernel is somewhere between a "freestanding" environment (no full libc) and "hosted" environment (many symbols from libc exist with the same type, function signature, and semantics). As Peter Anvin notes, there's not really a great way to inform the compiler that you're targeting a freestanding environment but would like to opt-in to some libcall optimizations (see pr/47280 below), rather than opt-out. Arvind notes, -fno-builtin-* behaves slightly differently between GCC and Clang, and Clang is missing many __builtin_* definitions, which I consider a bug in Clang and am working on fixing. Masahiro summarizes the subtle distinction between compilers justly: To prevent transformation from foo() into bar(), there are two ways in Clang to do that; -fno-builtin-foo, and -fno-builtin-bar. There is only one in GCC; -fno-buitin-foo. (Any difference in that behavior in Clang is likely a bug from a missing __builtin_* definition.) Masahiro also notes: We want to disable optimization from foo() to bar(), but we may still benefit from the optimization from foo() into something else. If GCC implements the same transform, we would run into a problem because it is not -fno-builtin-bar, but -fno-builtin-foo that disables that optimization. In this regard, -fno-builtin-foo would be more future-proof than -fno-built-bar, but -fno-builtin-foo is still potentially overkill. We may want to prevent calls from foo() being optimized into calls to bar(), but we still may want other optimization on calls to foo(). It seems that compilers today don't quite provide the fine grain control over which libcall optimizations pseudo-freestanding environments would prefer. Finally, Kees notes that this interface is unsafe, so we should not encourage its use. As such, I've removed the declaration from any header, but it still needs to be exported to avoid linkage errors in modules. Reported-by: Sami Tolvanen <samitolvanen@google.com> Suggested-by: Andy Lavr <andy.lavr@gmail.com> Suggested-by: Arvind Sankar <nivedita@alum.mit.edu> Suggested-by: Joe Perches <joe@perches.com> Suggested-by: Kees Cook <keescook@chromium.org> Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20200914161643.938408-1-ndesaulniers@google.com Link: https://bugs.llvm.org/show_bug.cgi?id=47162 Link: https://bugs.llvm.org/show_bug.cgi?id=47280 Link: ClangBuiltLinux/linux#1126 Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html Link: https://reviews.llvm.org/D85963 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…rom_sram Newer versions of Clang tend to apply heavier optimizations than GCC, especially if -mcpu is set. Because we are applying optimizations to the LITTLE core (see b92e1e70898f515646142736df8d72c43e97e251) kernel panics during boot, citing inability to access memory regions on fvmap_init. <6>[ 0.664609] [0: swapper/0: 1] fvmap_init:fvmap initialize 0000000000000000 <0>[ 0.664625] [0: swapper/0: 1] Unable to handle kernel paging request at virtual address ffffff800b2f2402 <2>[ 0.664640] [0: swapper/0: 1] sec_debug_set_extra_info_fault = KERN / 0xffffff800b2f2402 <6>[ 0.664657] [0: swapper/0: 1] search_item_by_key: (FTYPE) extra_info is not ready <2>[ 0.664666] [0: swapper/0: 1] set_item_val: fail to find FTYPE <6>[ 0.664680] [0: swapper/0: 1] search_item_by_key: (FAULT) extra_info is not ready <2>[ 0.664688] [0: swapper/0: 1] set_item_val: fail to find FAULT <6>[ 0.664702] [0: swapper/0: 1] search_item_by_key: (PC) extra_info is not ready <2>[ 0.664710] [0: swapper/0: 1] set_item_val: fail to find PC <6>[ 0.664724] [0: swapper/0: 1] search_item_by_key: (LR) extra_info is not ready <2>[ 0.664732] [0: swapper/0: 1] set_item_val: fail to find LR <1>[ 0.664746] [0: swapper/0: 1] Mem abort info: <1>[ 0.664760] [0: swapper/0: 1] Exception class = DABT (current EL), IL = 32 bits <1>[ 0.664774] [0: swapper/0: 1] SET = 0, FnV = 0 <1>[ 0.664787] [0: swapper/0: 1] EA = 0, S1PTW = 0 <1>[ 0.664799] [0: swapper/0: 1] Data abort info: <1>[ 0.664814] [0: swapper/0: 1] ISV = 0, ISS = 0x00000021 <1>[ 0.664828] [0: swapper/0: 1] CM = 0, WnR = 0 <1>[ 0.664842] [0: swapper/0: 1] swapper pgtable: 4k pages, 39-bit VAs, pgd = ffffff800a739000 <1>[ 0.664856] [0: swapper/0: 1] [ffffff800b2f2402] *pgd=000000097cdfe003, *pud=000000097cdfe003, *pmd=00000009742a9003, *pte=00e800000204b707 <0>[ 0.664884] [0: swapper/0: 1] Internal error: Oops: 96000021 [#1] PREEMPT SMP <4>[ 0.664899] [0: swapper/0: 1] Modules linked in: <0>[ 0.664916] [0: swapper/0: 1] Process swapper/0 (pid: 1, stack limit = 0xffffff80081a8000) <0>[ 0.664936] [0: swapper/0: 1] debug-snapshot: core register saved(CPU:0) <0>[ 0.664950] [0: swapper/0: 1] L2ECTLR_EL1: 0000000000000007 <0>[ 0.664959] [0: swapper/0: 1] L2ECTLR_EL1 valid_bit(30) is NOT set (0x0) <0>[ 0.664978] [0: swapper/0: 1] CPUMERRSR: 0000000008000001, L2MERRSR: 0000000010200c00 <0>[ 0.664992] [0: swapper/0: 1] CPUMERRSR valid_bit(31) is NOT set (0x0) <0>[ 0.665006] [0: swapper/0: 1] L2MERRSR valid_bit(31) is NOT set (0x0) <0>[ 0.665020] [0: swapper/0: 1] debug-snapshot: context saved(CPU:0) <6>[ 0.665088] [0: swapper/0: 1] debug-snapshot: item - log_kevents is disabled <6>[ 0.665112] [0: swapper/0: 1] TIF_FOREIGN_FPSTATE: 0, FP/SIMD depth 0, cpu: 0 <4>[ 0.665130] [0: swapper/0: 1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.113 - Fresh Core-user #1 <4>[ 0.665144] [0: swapper/0: 1] Hardware name: Samsung A50 LTN OPEN rev04 board based on Exynos9610 (DT) <4>[ 0.665160] [0: swapper/0: 1] task: ffffffc8f4ce8000 task.stack: ffffff80081a8000 <4>[ 0.665180] [0: swapper/0: 1] PC is at fvmap_init+0xac/0x2c8 <4>[ 0.665195] [0: swapper/0: 1] LR is at fvmap_init+0x70/0x2c8 <4>[ 0.665211] [0: swapper/0: 1] pc : [<ffffff80085e12b8>] lr : [<ffffff80085e127c>] pstate: 20400145 <4>[ 0.665225] [0: swapper/0: 1] sp : ffffff80081abb80 <4>[ 0.665238] [0: swapper/0: 1] x29: ffffff80081abbb0 x28: 0000000000000000 <4>[ 0.665256] [0: swapper/0: 1] x27: ffffff8009efc000 x26: 0000000000000000 <4>[ 0.665273] [0: swapper/0: 1] x25: ffffff800b2e5970 x24: ffffff8008fa7222 <4>[ 0.665291] [0: swapper/0: 1] x23: ffffff800b2e5a60 x22: ffffff8009efb000 <4>[ 0.665307] [0: swapper/0: 1] x21: ffffffc8f3480000 x20: ffffff800b2e0000 <4>[ 0.665324] [0: swapper/0: 1] x19: ffffff800b2f2400 x18: 0000000000000000 <4>[ 0.665341] [0: swapper/0: 1] x17: ffffff8009bff23c x16: 0000000000000000 <4>[ 0.665358] [0: swapper/0: 1] x15: 00000000000000c6 x14: 0000000000000054 <4>[ 0.665375] [0: swapper/0: 1] x13: 000000000000d7b8 x12: 0000000000000000 <4>[ 0.665392] [0: swapper/0: 1] x11: 0000000000000000 x10: ffffffc8f3480000 <4>[ 0.665409] [0: swapper/0: 1] x9 : ffffff800b2f2400 x8 : 0000000000000000 <4>[ 0.665426] [0: swapper/0: 1] x7 : 5b20205d39303634 x6 : ffffffc0117d09b7 <4>[ 0.665443] [0: swapper/0: 1] x5 : 0000000000000001 x4 : 000000000000000c <4>[ 0.665459] [0: swapper/0: 1] x3 : 0000000000000a30 x2 : ffffffffffffffce <4>[ 0.665476] [0: swapper/0: 1] x1 : 000000000b040000 x0 : 000000000000000a Since we need these optimizations for performance reasons, the only way to resolve this is to solve the issue. Samsung already did something similar to cal-if before. We only needed to make fvmap_header/header volatile and has been tested to work. Signed-off-by: John Vincent <git@tensevntysevn.cf>
* Breaks clang12+
drivers/gpu/arm/bv_r38p1/../exynos/mali_exynos_kbase_entrypoint.c:260:35: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 260 | void mali_exynos_coherency_reg_map() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/mali_exynos_kbase_entrypoint.c:265:37: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 265 | void mali_exynos_coherency_reg_unmap() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/mali_exynos_kbase_entrypoint.c:270:49: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 270 | void mali_exynos_coherency_set_coherency_feature() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/mali_exynos_kbase_entrypoint.c:275:32: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 275 | void mali_exynos_llc_set_aruser() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/mali_exynos_kbase_entrypoint.c:280:32: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 280 | void mali_exynos_llc_set_awuser() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_platform.c:99:24: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 99 | void gpex_platform_term() | ^ drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.c:63:31: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 63 | int gpexbe_clock_get_boot_freq() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.c:68:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 68 | int gpexbe_clock_get_max_freq() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.c:92:26: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 92 | int gpexbe_clock_get_rate() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.c:97:22: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 97 | int gpexbe_clock_init() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.c:114:23: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 114 | void gpexbe_clock_term() | ^ | void 5 errors generated. make[4]: *** [scripts/Makefile.build:334: drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.o] Error 1 make[4]: *** Waiting for unfinished jobs.... drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:40:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 40 | int gpex_clock_get_boot_clock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:44:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 44 | int gpex_clock_get_max_clock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:48:35: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 48 | int gpex_clock_get_max_clock_limit() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:52:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 52 | int gpex_clock_get_min_clock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:56:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 56 | int gpex_clock_get_cur_clock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:60:28: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 60 | int gpex_clock_get_max_lock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:64:28: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 64 | int gpex_clock_get_min_lock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:334:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 334 | void gpex_clock_term() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:355:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 355 | int gpex_clock_get_clock_slow() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:407:35: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 407 | int gpex_clock_prepare_runtime_off() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:561:27: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 561 | void gpex_clock_mutex_lock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:566:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 566 | void gpex_clock_mutex_unlock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:334:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 334 | void gpex_clock_term() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:355:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 355 | int gpex_clock_get_clock_slow() drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpu_dvfs_governor.c:34:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 34 | int gpex_dvfs_set_clock_callback() CC drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs_external.o drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:175:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 175 | void gpex_dvfs_start() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:180:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 180 | void gpex_dvfs_stop() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:223:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 223 | int gpex_dvfs_enable() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:228:22: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 228 | int gpex_dvfs_disable() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:233:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 233 | static int gpu_dvfs_handler_init() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:246:35: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 246 | static int gpu_dvfs_handler_deinit() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:298:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 298 | void gpex_dvfs_term() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:306:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 306 | int gpex_dvfs_get_status() drivers/gpu/arm/bv_r38p1/../exynos/backend/dummy/gpexbe_secure_dummy.c:28:64: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 28 | struct protected_mode_ops *gpexbe_secure_get_protected_mode_ops() drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_smc.c:44:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 44 | int gpexbe_smc_protection_enable() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_smc.c:71:34: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 71 | int gpexbe_smc_protection_disable() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_smc.c:117:32: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 117 | void gpexbe_smc_notify_power_on() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_smc.c:120:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 120 | void gpexbe_smc_notify_power_off() drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_smc.c:44:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 44 | int gpexbe_smc_protection_enable() drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_qos.c:121:18: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 121 | int gpex_qos_init() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_qos.c:182:19: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 182 | void gpex_qos_term() | drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_qos.c:3:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 3 | int gpexbe_qos_init() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_qos.c:8:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 8 | void gpexbe_qos_term()
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_bts_v1.c:33:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 33 | int gpexbe_bts_init() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_bts_v1.c:38:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 38 | void gpexbe_bts_term() drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_debug_v1.c:39:22: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 39 | int gpexbe_debug_init() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_debug_v1.c:44:23: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 44 | void gpexbe_debug_term() drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_thermal.c:40:28: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 40 | int gpex_thermal_gpu_normal() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_thermal.c:161:22: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 161 | int gpex_thermal_init() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_thermal.c:170:23: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 170 | void gpex_thermal_term() | ^ | void 3 errors generated. drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_notifier.c:109:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 109 | int gpexbe_notifier_init() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_notifier.c:126:26: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 126 | void gpexbe_notifier_term() drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:68:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 68 | int gpexbe_pm_get_status() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:79:56: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 79 | struct exynos_pm_domain *gpexbe_pm_get_exynos_pm_domain() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:84:27: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 84 | void gpexbe_pm_access_lock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:90:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 90 | void gpexbe_pm_access_unlock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:133:28: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 133 | int gpexbe_pm_pd_control_up() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:138:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 138 | int gpexbe_pm_pd_control_down() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:143:19: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 143 | int gpexbe_pm_init() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:159:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 159 | void gpexbe_pm_term() drivers/gpu/arm/bv_r38p1/../exynos/tests/runtime_test_runner_dummy.c:23:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 23 | int runtime_test_runner_init() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/tests/runtime_test_runner_dummy.c:28:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 28 | void runtime_test_runner_term() | ^ | void 2 errors generated. drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_pm.c:104:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 104 | int gpex_pm_get_power_status() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_pm.c:109:18: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 109 | void gpex_pm_lock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_pm.c:114:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 114 | void gpex_pm_unlock() | ^ | void drivers/gpu/arm/bv_r38p1/../exynos/workarounds/gpexwa_ehmp.c:54:23: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 54 | void gpexwa_ehmp_unset() {
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_qos_internal.h:21:15: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] 21 | static inline pmqos_flag_check(mali_pmqos_flags type, mali_pmqos_flags in)
security/sdp/dek_legacy.c:105:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 105 | int is_current_adbd() { | ^ | void security/sdp/dek_legacy.c:121:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 121 | int is_current_epmd() {
drivers/media/tdmb/fc8080/dmbdrv_wrap_fc8080.c:386:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 386 | char *dmb_drv_get_ensemble_label() | ^ | void
drivers/net/wireless/bcmdhd_101_16/dhd_linux.c:19280:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 19280 | dhd_get_time_str_len() drivers/net/wireless/bcmdhd_101_16//wl_cfg_btcoex.c:437:37: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] void wl_cfg80211_btcoex_kill_handler() drivers/net/wireless/bcmdhd_101_16//wl_cfg_btcoex.c:450:31: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] void wl_cfg80211_btcoex_deinit() drivers/net/wireless/bcmdhd_101_16/dhd_linux_platdev.c:867:34: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 867 | static int dhd_wifi_platform_load()
drivers/soc/samsung/exynos-hdcp/exynos-hdcp2-teeif.c:58:19: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 58 | int hdcp_tee_close() | ^ | void
fs/f2fs/super.c:2456:17: error: incompatible integer to pointer conversion initializing 'unsigned int (*)(struct inode *)' with an expression of type 'int' [-Wint-conversion] 2456 | .max_namelen = F2FS_NAME_LEN, | ^~~~~~~~~~~~~ ./include/linux/f2fs_fs.h:194:24: note: expanded from macro 'F2FS_NAME_LEN' 194 | #define F2FS_NAME_LEN 255
* simplify pkg checker * add new clang versions * update debug build * fix invalid char
This reverts commit 39fc5a8.
Apollo Clang support
LLVM's integrated assembler fails with the following error when building KVM: <inline asm>:12:6: error: expected absolute expression .if kvm_update_va_mask == 0 ^ <inline asm>:21:6: error: expected absolute expression .if kvm_update_va_mask == 0 ^ <inline asm>:24:2: error: unrecognized instruction mnemonic NOT_AN_INSTRUCTION ^ LLVM ERROR: Error parsing inline asm These errors come from ALTERNATIVE_CB and __ALTERNATIVE_CFG, which test for the existence of the callback parameter in inline assembly using the following expression: " .if " __stringify(cb) " == 0\n" This works with GNU as, but isn't supported by LLVM. This change splits __ALTERNATIVE_CFG and ALTINSTR_ENTRY into separate macros to fix the LLVM build. Bug: 145210207 Change-Id: I62dd786277bcaf3c730a7489c4b5a2b437f722ce (am from https://lore.kernel.org/patchwork/patch/1136803/) Link: ClangBuiltLinux/linux#472 Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
commit 8708e13c6a0600625eea3aebd027c0715a5d2bb2 upstream. Add keyword support so that our mailing list gets cc'ed for clang/llvm patches. We're pretty active on our mailing list so far as code review. There are numerous Googlers like myself that are paid to support building the Linux kernel with Clang and LLVM. Link: http://lkml.kernel.org/r/20190620001907.255803-1-ndesaulniers@google.com Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Cc: Joe Perches <joe@perches.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fcf1b6a35c16ac500fa908a4022238e5d666eabf upstream. added to kbuild documentation. Provides more official info on building kernels with Clang and LLVM than our wiki. Suggested-by: Kees Cook <keescook@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> [nd: hunk against Documentation/kbuild/index.rst dropped due to not backporting commit cd238effefa2 ("docs: kbuild: convert docs to ReST and rename to *.rst")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0f44fbc162b737ff6251ae248184390ae2279fee upstream. The tool is called llvm-size, not llvm-objsize. Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/ Clang/LLVM") Signed-off-by: Fangrui Song <maskray@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit e00d8880481497474792d28c14479a9fb6752046 ] Commit c3ff2a5193fa ("powerpc/32: add stack protector support") caused kernel panic on PowerPC when an external module is used with CONFIG_STACKPROTECTOR because the 'prepare' target was not executed for the external module build. Commit e07db28eea38 ("kbuild: fix single target build for external module") turned it into a build error because the 'prepare' target is now executed but the 'prepare0' target is missing for the external module build. External module on arm/arm64 with CONFIG_STACKPROTECTOR_PER_TASK is also broken in the same way. Move 'PHONY += prepare0' to the common place. GNU Make is fine with missing rule for phony targets. I also removed the comment which is wrong irrespective of this commit. I minimize the change so it can be easily backported to 4.20.x To fix v4.20, please backport e07db28eea38 ("kbuild: fix single target build for external module"), and then this commit. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201891 Fixes: e07db28eea38 ("kbuild: fix single target build for external module") Fixes: c3ff2a5193fa ("powerpc/32: add stack protector support") Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries") Fixes: 0a1213fa7432 ("arm64: enable per-task stack canaries") Cc: linux-stable <stable@vger.kernel.org> # v4.20 Reported-by: Samuel Holland <samuel@sholland.org> Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7bac98707f65b93bf994ef4e99b1eb9e7dbb9c32 upstream. Define and export OBJSIZE variable for "size" tool from binutils to be used in architecture specific Makefiles (naming the variable just "SIZE" would be too risky). In particular this tool is useful to perform checks that early boot code is not using bss section (which might have not been zeroed yet or intersects with initrd or other files boot loader might have put right after the linux kernel). Link: http://lkml.kernel.org/r/patch-1.thread-2257a1.git-188f5a3d81d5.your-ad-here.call-01565088755-ext-5120@work.hours Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eefb8c124fd969e9a174ff2bedff86aa305a7438 upstream. Introduce a new READELF variable to top-level Makefile, so the name of readelf binary can be specified. Before this change the name of the binary was hardcoded to "$(CROSS_COMPILE)readelf" which might not be present for every toolchain. This allows to build with LLVM Object Reader by using make parameter READELF=llvm-readelf. Link: ClangBuiltLinux/linux#771 Signed-off-by: Dmitry Golovin <dima@golovin.in> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…firmware commit 63b903dfebdea92aa92ad337d8451a6fbfeabf9d upstream. As far as I understood from the Kconfig help text, this build rule is used to rebuild the driver firmware, which runs on an old m68k-based chip. So, you need m68k tools for the firmware rebuild. wanxl.c is a PCI driver, but CONFIG_M68K does not select CONFIG_HAVE_PCI. So, you cannot enable CONFIG_WANXL_BUILD_FIRMWARE for ARCH=m68k. In other words, ifeq ($(ARCH),m68k) is false here. I am keeping the dead code for now, but rebuilding the firmware requires 'as68k' and 'ld68k', which I do not have in hand. Instead, the kernel.org m68k GCC [1] successfully built it. Allowing a user to pass in CROSS_COMPILE_M68K= is handier. [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/9.2.0/x86_64-gcc-9.2.0-nolibc-m68k-linux.tar.xz Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…rmware commit 734f3719d3438f9cc181d674c33ca9762e9148a1 upstream. The firmware source, wanxlfw.S, is currently compiled by the combo of $(CPP) and $(M68KAS). This is not what we usually do for compiling *.S files. In fact, this Makefile is the only user of $(AS) in the kernel build. Instead of combining $(CPP) and (AS) from different tool sets, using $(M68KCC) as an assembler driver is simpler, and saner. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa824e0c962b532d5073cbb41b2efcd6f5e72bae upstream. As commit 5ef872636ca7 ("kbuild: get rid of misleading $(AS) from documents") noted, we rarely use $(AS) directly in the kernel build. Now that the only/last user of $(AS) in drivers/net/wan/Makefile was converted to $(CC), $(AS) is no longer used in the build process. You can still pass in AS=clang, which is just a switch to turn on the LLVM integrated assembler. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7e20e47c70f810d678d02941fa3c671209c4ca97 upstream. The 'AS' variable is unused for building the kernel. Only the remaining usage is to turn on the integrated assembler. A boolean flag is a better fit for this purpose. AS=clang was added for experts. So, I replaced it with LLVM_IAS=1, breaking the backward compatibility. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0d1c951ef08ed24f35129267e3595d86f57f5d3 upstream. As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy. Provide a single switch LLVM=1 to use Clang and LLVM tools instead of GCC and Binutils. You can pass it from the command line or as an environment variable. Please note LLVM=1 does not turn on the integrated assembler. You need to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the integrated assembler, I think we can make it default. We discussed what we need, and we agreed to go with a simple boolean flag that switches both target and host tools: https://lkml.org/lkml/2020/3/28/494 https://lkml.org/lkml/2020/4/3/43 Some items discussed, but not adopted: - LLVM_DIR When multiple versions of LLVM are installed, I just thought supporting LLVM_DIR=/path/to/my/llvm/bin/ might be useful. CC = $(LLVM_DIR)clang LD = $(LLVM_DIR)ld.lld ... However, we can handle this by modifying PATH. So, we decided to not do this. - LLVM_SUFFIX Some distributions (e.g. Debian) package specific versions of LLVM with naming conventions that use the version as a suffix. CC = clang$(LLVM_SUFFIX) LD = ld.lld(LLVM_SUFFIX) ... will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc., but the suffixed versions in /usr/bin/ are symlinks to binaries in /usr/lib/llvm-#/bin/, so this can also be handled by PATH. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] [nd: hunk against Documentation/kbuild/kbuild.rst dropped due to not backporting commit cd238effefa2 ("docs: kbuild: convert docs to ReST and rename to *.rst")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clang's integrated assembler produces the warning for assembly files: warning: DWARF2 only supports one section per compilation unit If -Wa,-gdwarf-* is unspecified, then debug info is not emitted for assembly sources (it is still emitted for C sources). This will be re-enabled for newer DWARF versions in a follow up patch. Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with LLVM=1 LLVM_IAS=1 for x86_64 and arm64. Reported-by: Dmitry Golovin <dima@golovin.in> Reported-by: Nathan Chancellor <natechancellor@gmail.com> Suggested-by: Dmitry Golovin <dima@golovin.in> Suggested-by: Nathan Chancellor <natechancellor@gmail.com> Suggested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Fangrui Song <maskray@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Cc: <stable@vger.kernel.org> Link: ClangBuiltLinux/linux#716 Bug: 141693040 Link: https://lore.kernel.org/lkml/20201109183528.1391885-1-ndesaulniers@google.com/ Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Change-Id: I55c8ad79dfeaae478c8de52d484e76fb2e37c194
commit 4d6ffa27b8e5116c0abb318790fd01d4e12d75e6 upstream. Commit 393f203 ("x86_64: kasan: add interceptors for memset/memmove/memcpy functions") added .weak directives to arch/x86/lib/mem*_64.S instead of changing the existing ENTRY macros to WEAK. This can lead to the assembly snippet .weak memcpy ... .globl memcpy which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL memcpy with LLVM's integrated assembler before LLVM 12. LLVM 12 (since https://reviews.llvm.org/D90108) will error on such an overridden symbol binding. Commit ef1e03152cb0 ("x86/asm: Make some functions local") changed ENTRY in arch/x86/lib/memcpy_64.S to SYM_FUNC_START_LOCAL, which was ineffective due to the preceding .weak directive. Use the appropriate SYM_FUNC_START_WEAK instead. Fixes: 393f203 ("x86_64: kasan: add interceptors for memset/memmove/memcpy functions") Fixes: ef1e03152cb0 ("x86/asm: Make some functions local") Reported-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201103012358.168682-1-maskray@google.com [nd: backport due to missing commit e9b9d020c487 ("x86/asm: Annotate aliases") commit ffedeeb780dc ("linkage: Introduce new macros for assembler symbols")] Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Otherwise modules that use these arithmetic operations will fail to link. We accomplish this with the usual EXPORT_SYMBOL, which on most architectures goes in the .S file but the ARM64 maintainers prefer that insead it goes into arm64ksyms. While we're at it, we also fix this up to use SPDX, and I personally choose to relicense this as GPL2||BSD so that these symbols don't need to be export_symbol_gpl, so all modules can use the routines, since these are important general purpose compiler-generated function calls. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Reported-by: PaX Team <pageexec@freemail.hu> Cc: stable@vger.kernel.org Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit 255845fc43a3aaf806852a1d3bc89bff1411ebe3) Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: kdrag0n <dragon@khronodragon.com>
* Ex when CUDA LLVM is pre-installed ./include/generated/compile.h:8:1: error: unknown type name 'Found' 8 | Found CUDA installation: /usr/local/cuda, version, LLD 18.0.1" | ^ ./include/generated/compile.h:8:11: error: expected ';' after top level declarator 8 | Found CUDA installation: /usr/local/cuda, version, LLD 18.0.1"
* When CUDA is installed the kernel version reflects that * add hot-cold-split optimization * add C/LD flags O2 * Remove duplicates * General changes
* Maintain compatiblity with older clang
* Maintain compatiblity
* Remove redundant configs * clean some up mess * Upgrade compiler setup to download compilers * add MLGO/ThinLTO/POLLY/DFA per compiler * fix some typos with y/n options * add BUILD_OPTIONS to print kernel info before compiling * improve bsdiff checker * add new compilers to list * add default options to prevent crashes and empty options * Remove deprecated GCC compilers
duhansysl
pushed a commit
that referenced
this pull request
Aug 12, 2024
Bing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage() with detailed analysis and a nice repro. unix_stream_sendpage() tries to add data to the last skb in the peer's recv queue without locking the queue. If the peer's FD is passed to another socket and the socket's FD is passed to the peer, there is a loop between them. If we close both sockets without receiving FD, the sockets will be cleaned up by garbage collection. The garbage collection iterates such sockets and unlinks skb with FD from the socket's receive queue under the queue's lock. So, there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free. To avoid the issue, unix_stream_sendpage() must lock the peer's recv queue. Note the issue does not exist in 6.5+ thanks to the recent sendpage() refactoring. This patch is originally written by Linus Torvalds. BUG: unable to handle page fault for address: ffff988004dd6870 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc_node+0xa2/0x1e0 Code: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 <49> 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44 RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246 RAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284 RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0 RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00 R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8 FS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x1a/0x1f ? page_fault_oops+0xa9/0x1e0 ? fixup_exception+0x1d/0x310 ? exc_page_fault+0xa8/0x150 ? asm_exc_page_fault+0x22/0x30 ? kmem_cache_alloc_node+0xa2/0x1e0 ? __alloc_skb+0x16c/0x1e0 __alloc_skb+0x16c/0x1e0 alloc_skb_with_frags+0x48/0x1e0 sock_alloc_send_pskb+0x234/0x270 unix_stream_sendmsg+0x1f5/0x690 sock_sendmsg+0x5d/0x60 ____sys_sendmsg+0x210/0x260 ___sys_sendmsg+0x83/0xd0 ? kmem_cache_alloc+0xc6/0x1c0 ? avc_disable+0x20/0x20 ? percpu_counter_add_batch+0x53/0xc0 ? alloc_empty_file+0x5d/0xb0 ? alloc_file+0x91/0x170 ? alloc_file_pseudo+0x94/0x100 ? __fget_light+0x9f/0x120 __sys_sendmsg+0x54/0xa0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x69/0xd3 RIP: 0033:0x7f174d639a7d Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48 RSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d RDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007 RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28 R13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000 </TASK> Bug: 299922588 Fixes: 869e7c6 ("net: af_unix: implement stream sendpage support") Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg> Reviewed-by: Bing-Jhong Billy Jheng <billy@starlabs.sg> Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 790c2f9d15b594350ae9bca7b236f2b1859de02c) Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: Ied4a40e6ae0e594ef84f36287bc6194602935585
duhansysl
pushed a commit
that referenced
this pull request
Aug 13, 2024
On systems using ACPI cpufreq, at boot-time only CPU0 max_freq has been populated when load_scale_factor/capacity recomputation is triggered on all possible cpus. This leads to the following divide by zero panic when rq->max_freq for any cpu other than CPU0 is accessed: [ 4.827597] divide error: 0000 [#1] PREEMPT SMP [ 4.827604] [<ffffffff862ad88e>] ? notifier_call_chain+0x37/0x57 [ 4.827607] [<ffffffff862adaf3>] ? __blocking_notifier_call_chain+0x46/0x5c [ 4.827611] [<ffffffff8684b9f4>] ? cpufreq_set_policy+0xa6/0x2dc [ 4.827614] [<ffffffff869e4d55>] ? cpufreq_init_policy+0xba/0xde [ 4.827617] [<ffffffff8684bd4c>] ? cpufreq_update_policy+0x122/0x122 [ 4.827620] [<ffffffff8684c51c>] ? cpufreq_online+0x5a7/0x64e [ 4.827623] [<ffffffff8684c63b>] ? cpufreq_add_dev+0x78/0xed [ 4.827627] [<ffffffff866ce412>] ? subsys_interface_register+0xd6/0x117 [ 4.827630] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827632] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827636] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827639] [<ffffffff86f83d43>] ? acpi_cpufreq_init+0x215/0x282 [ 4.827641] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827645] [<ffffffff8620046e>] ? do_one_initcall+0x9c/0x12e [ 4.827649] [<ffffffff86f3d058>] ? kernel_init_freeable+0x190/0x22b [ 4.827651] [<ffffffff869e59d9>] ? rest_init+0x7c/0x7c [ 4.827653] [<ffffffff869e59e3>] ? kernel_init+0xa/0xf3 [ 4.827656] [<ffffffff869ed482>] ? ret_from_fork+0x22/0x30 On ACPI based systems, for CPUs with uninitialized rq->max_freq skip the re-calculation. Reference discussion on a similar issue here: https://www.spinics.net/lists/arm-kernel/msg557612.html Change-Id: I5025e3f6db671e9e72369f85708d3b0482d5dad2 Signed-off-by: Abhilash Kesavan <abhilash.kesavan@intel.com>
duhansysl
pushed a commit
that referenced
this pull request
Aug 13, 2024
[ Upstream commit 1b1d622 ] Bug was noticed via this warning: WARNING: CPU: 6 PID: 1 at kernel/sched/sched.h:804 detach_task_cfs_rq+0x8e8/0xb80 rq->clock_update_flags < RQCF_ACT_SKIP Modules linked in: CPU: 6 PID: 1 Comm: systemd Not tainted 4.10.0-rc5-00140-g0874170baf55-dirty #1 Hardware name: Supermicro SYS-4048B-TRFT/X10QBi, BIOS 1.0 04/11/2014 Call Trace: dump_stack+0x4d/0x65 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 detach_task_cfs_rq+0x8e8/0xb80 ? allocate_cgrp_cset_links+0x59/0x80 task_change_group_fair+0x27/0x150 sched_change_group+0x48/0xf0 sched_move_task+0x53/0x150 cpu_cgroup_attach+0x36/0x70 cgroup_taskset_migrate+0x175/0x300 cgroup_migrate+0xab/0xd0 cgroup_attach_task+0xf0/0x190 __cgroup_procs_write+0x1ed/0x2f0 cgroup_procs_write+0x14/0x20 cgroup_file_write+0x3f/0x100 kernfs_fop_write+0x104/0x180 __vfs_write+0x37/0x140 vfs_write+0xb8/0x1b0 SyS_write+0x55/0xc0 do_syscall_64+0x61/0x170 entry_SYSCALL64_slow_path+0x25/0x25 Reported-by: Ingo Molnar <mingo@kernel.org> Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
duhansysl
pushed a commit
that referenced
this pull request
Aug 14, 2024
On systems using ACPI cpufreq, at boot-time only CPU0 max_freq has been populated when load_scale_factor/capacity recomputation is triggered on all possible cpus. This leads to the following divide by zero panic when rq->max_freq for any cpu other than CPU0 is accessed: [ 4.827597] divide error: 0000 [#1] PREEMPT SMP [ 4.827604] [<ffffffff862ad88e>] ? notifier_call_chain+0x37/0x57 [ 4.827607] [<ffffffff862adaf3>] ? __blocking_notifier_call_chain+0x46/0x5c [ 4.827611] [<ffffffff8684b9f4>] ? cpufreq_set_policy+0xa6/0x2dc [ 4.827614] [<ffffffff869e4d55>] ? cpufreq_init_policy+0xba/0xde [ 4.827617] [<ffffffff8684bd4c>] ? cpufreq_update_policy+0x122/0x122 [ 4.827620] [<ffffffff8684c51c>] ? cpufreq_online+0x5a7/0x64e [ 4.827623] [<ffffffff8684c63b>] ? cpufreq_add_dev+0x78/0xed [ 4.827627] [<ffffffff866ce412>] ? subsys_interface_register+0xd6/0x117 [ 4.827630] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827632] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827636] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827639] [<ffffffff86f83d43>] ? acpi_cpufreq_init+0x215/0x282 [ 4.827641] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827645] [<ffffffff8620046e>] ? do_one_initcall+0x9c/0x12e [ 4.827649] [<ffffffff86f3d058>] ? kernel_init_freeable+0x190/0x22b [ 4.827651] [<ffffffff869e59d9>] ? rest_init+0x7c/0x7c [ 4.827653] [<ffffffff869e59e3>] ? kernel_init+0xa/0xf3 [ 4.827656] [<ffffffff869ed482>] ? ret_from_fork+0x22/0x30 On ACPI based systems, for CPUs with uninitialized rq->max_freq skip the re-calculation. Reference discussion on a similar issue here: https://www.spinics.net/lists/arm-kernel/msg557612.html Change-Id: I5025e3f6db671e9e72369f85708d3b0482d5dad2 Signed-off-by: Abhilash Kesavan <abhilash.kesavan@intel.com>
duhansysl
pushed a commit
that referenced
this pull request
Aug 14, 2024
[ Upstream commit 1b1d622 ] Bug was noticed via this warning: WARNING: CPU: 6 PID: 1 at kernel/sched/sched.h:804 detach_task_cfs_rq+0x8e8/0xb80 rq->clock_update_flags < RQCF_ACT_SKIP Modules linked in: CPU: 6 PID: 1 Comm: systemd Not tainted 4.10.0-rc5-00140-g0874170baf55-dirty #1 Hardware name: Supermicro SYS-4048B-TRFT/X10QBi, BIOS 1.0 04/11/2014 Call Trace: dump_stack+0x4d/0x65 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 detach_task_cfs_rq+0x8e8/0xb80 ? allocate_cgrp_cset_links+0x59/0x80 task_change_group_fair+0x27/0x150 sched_change_group+0x48/0xf0 sched_move_task+0x53/0x150 cpu_cgroup_attach+0x36/0x70 cgroup_taskset_migrate+0x175/0x300 cgroup_migrate+0xab/0xd0 cgroup_attach_task+0xf0/0x190 __cgroup_procs_write+0x1ed/0x2f0 cgroup_procs_write+0x14/0x20 cgroup_file_write+0x3f/0x100 kernfs_fop_write+0x104/0x180 __vfs_write+0x37/0x140 vfs_write+0xb8/0x1b0 SyS_write+0x55/0xc0 do_syscall_64+0x61/0x170 entry_SYSCALL64_slow_path+0x25/0x25 Reported-by: Ingo Molnar <mingo@kernel.org> Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
duhansysl
pushed a commit
that referenced
this pull request
Aug 14, 2024
On systems using ACPI cpufreq, at boot-time only CPU0 max_freq has been populated when load_scale_factor/capacity recomputation is triggered on all possible cpus. This leads to the following divide by zero panic when rq->max_freq for any cpu other than CPU0 is accessed: [ 4.827597] divide error: 0000 [#1] PREEMPT SMP [ 4.827604] [<ffffffff862ad88e>] ? notifier_call_chain+0x37/0x57 [ 4.827607] [<ffffffff862adaf3>] ? __blocking_notifier_call_chain+0x46/0x5c [ 4.827611] [<ffffffff8684b9f4>] ? cpufreq_set_policy+0xa6/0x2dc [ 4.827614] [<ffffffff869e4d55>] ? cpufreq_init_policy+0xba/0xde [ 4.827617] [<ffffffff8684bd4c>] ? cpufreq_update_policy+0x122/0x122 [ 4.827620] [<ffffffff8684c51c>] ? cpufreq_online+0x5a7/0x64e [ 4.827623] [<ffffffff8684c63b>] ? cpufreq_add_dev+0x78/0xed [ 4.827627] [<ffffffff866ce412>] ? subsys_interface_register+0xd6/0x117 [ 4.827630] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827632] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827636] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827639] [<ffffffff86f83d43>] ? acpi_cpufreq_init+0x215/0x282 [ 4.827641] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827645] [<ffffffff8620046e>] ? do_one_initcall+0x9c/0x12e [ 4.827649] [<ffffffff86f3d058>] ? kernel_init_freeable+0x190/0x22b [ 4.827651] [<ffffffff869e59d9>] ? rest_init+0x7c/0x7c [ 4.827653] [<ffffffff869e59e3>] ? kernel_init+0xa/0xf3 [ 4.827656] [<ffffffff869ed482>] ? ret_from_fork+0x22/0x30 On ACPI based systems, for CPUs with uninitialized rq->max_freq skip the re-calculation. Reference discussion on a similar issue here: https://www.spinics.net/lists/arm-kernel/msg557612.html Change-Id: I5025e3f6db671e9e72369f85708d3b0482d5dad2 Signed-off-by: Abhilash Kesavan <abhilash.kesavan@intel.com>
duhansysl
pushed a commit
that referenced
this pull request
Aug 14, 2024
[ Upstream commit 1b1d622 ] Bug was noticed via this warning: WARNING: CPU: 6 PID: 1 at kernel/sched/sched.h:804 detach_task_cfs_rq+0x8e8/0xb80 rq->clock_update_flags < RQCF_ACT_SKIP Modules linked in: CPU: 6 PID: 1 Comm: systemd Not tainted 4.10.0-rc5-00140-g0874170baf55-dirty #1 Hardware name: Supermicro SYS-4048B-TRFT/X10QBi, BIOS 1.0 04/11/2014 Call Trace: dump_stack+0x4d/0x65 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 detach_task_cfs_rq+0x8e8/0xb80 ? allocate_cgrp_cset_links+0x59/0x80 task_change_group_fair+0x27/0x150 sched_change_group+0x48/0xf0 sched_move_task+0x53/0x150 cpu_cgroup_attach+0x36/0x70 cgroup_taskset_migrate+0x175/0x300 cgroup_migrate+0xab/0xd0 cgroup_attach_task+0xf0/0x190 __cgroup_procs_write+0x1ed/0x2f0 cgroup_procs_write+0x14/0x20 cgroup_file_write+0x3f/0x100 kernfs_fop_write+0x104/0x180 __vfs_write+0x37/0x140 vfs_write+0xb8/0x1b0 SyS_write+0x55/0xc0 do_syscall_64+0x61/0x170 entry_SYSCALL64_slow_path+0x25/0x25 Reported-by: Ingo Molnar <mingo@kernel.org> Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
duhansysl
pushed a commit
that referenced
this pull request
Sep 5, 2024
On systems using ACPI cpufreq, at boot-time only CPU0 max_freq has been populated when load_scale_factor/capacity recomputation is triggered on all possible cpus. This leads to the following divide by zero panic when rq->max_freq for any cpu other than CPU0 is accessed: [ 4.827597] divide error: 0000 [#1] PREEMPT SMP [ 4.827604] [<ffffffff862ad88e>] ? notifier_call_chain+0x37/0x57 [ 4.827607] [<ffffffff862adaf3>] ? __blocking_notifier_call_chain+0x46/0x5c [ 4.827611] [<ffffffff8684b9f4>] ? cpufreq_set_policy+0xa6/0x2dc [ 4.827614] [<ffffffff869e4d55>] ? cpufreq_init_policy+0xba/0xde [ 4.827617] [<ffffffff8684bd4c>] ? cpufreq_update_policy+0x122/0x122 [ 4.827620] [<ffffffff8684c51c>] ? cpufreq_online+0x5a7/0x64e [ 4.827623] [<ffffffff8684c63b>] ? cpufreq_add_dev+0x78/0xed [ 4.827627] [<ffffffff866ce412>] ? subsys_interface_register+0xd6/0x117 [ 4.827630] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827632] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827636] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827639] [<ffffffff86f83d43>] ? acpi_cpufreq_init+0x215/0x282 [ 4.827641] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827645] [<ffffffff8620046e>] ? do_one_initcall+0x9c/0x12e [ 4.827649] [<ffffffff86f3d058>] ? kernel_init_freeable+0x190/0x22b [ 4.827651] [<ffffffff869e59d9>] ? rest_init+0x7c/0x7c [ 4.827653] [<ffffffff869e59e3>] ? kernel_init+0xa/0xf3 [ 4.827656] [<ffffffff869ed482>] ? ret_from_fork+0x22/0x30 On ACPI based systems, for CPUs with uninitialized rq->max_freq skip the re-calculation. Reference discussion on a similar issue here: https://www.spinics.net/lists/arm-kernel/msg557612.html Change-Id: I5025e3f6db671e9e72369f85708d3b0482d5dad2 Signed-off-by: Abhilash Kesavan <abhilash.kesavan@intel.com>
duhansysl
pushed a commit
that referenced
this pull request
Sep 5, 2024
[ Upstream commit 1b1d622 ] Bug was noticed via this warning: WARNING: CPU: 6 PID: 1 at kernel/sched/sched.h:804 detach_task_cfs_rq+0x8e8/0xb80 rq->clock_update_flags < RQCF_ACT_SKIP Modules linked in: CPU: 6 PID: 1 Comm: systemd Not tainted 4.10.0-rc5-00140-g0874170baf55-dirty #1 Hardware name: Supermicro SYS-4048B-TRFT/X10QBi, BIOS 1.0 04/11/2014 Call Trace: dump_stack+0x4d/0x65 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 detach_task_cfs_rq+0x8e8/0xb80 ? allocate_cgrp_cset_links+0x59/0x80 task_change_group_fair+0x27/0x150 sched_change_group+0x48/0xf0 sched_move_task+0x53/0x150 cpu_cgroup_attach+0x36/0x70 cgroup_taskset_migrate+0x175/0x300 cgroup_migrate+0xab/0xd0 cgroup_attach_task+0xf0/0x190 __cgroup_procs_write+0x1ed/0x2f0 cgroup_procs_write+0x14/0x20 cgroup_file_write+0x3f/0x100 kernfs_fop_write+0x104/0x180 __vfs_write+0x37/0x140 vfs_write+0xb8/0x1b0 SyS_write+0x55/0xc0 do_syscall_64+0x61/0x170 entry_SYSCALL64_slow_path+0x25/0x25 Reported-by: Ingo Molnar <mingo@kernel.org> Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
duhansysl
pushed a commit
that referenced
this pull request
Sep 5, 2024
On systems using ACPI cpufreq, at boot-time only CPU0 max_freq has been populated when load_scale_factor/capacity recomputation is triggered on all possible cpus. This leads to the following divide by zero panic when rq->max_freq for any cpu other than CPU0 is accessed: [ 4.827597] divide error: 0000 [#1] PREEMPT SMP [ 4.827604] [<ffffffff862ad88e>] ? notifier_call_chain+0x37/0x57 [ 4.827607] [<ffffffff862adaf3>] ? __blocking_notifier_call_chain+0x46/0x5c [ 4.827611] [<ffffffff8684b9f4>] ? cpufreq_set_policy+0xa6/0x2dc [ 4.827614] [<ffffffff869e4d55>] ? cpufreq_init_policy+0xba/0xde [ 4.827617] [<ffffffff8684bd4c>] ? cpufreq_update_policy+0x122/0x122 [ 4.827620] [<ffffffff8684c51c>] ? cpufreq_online+0x5a7/0x64e [ 4.827623] [<ffffffff8684c63b>] ? cpufreq_add_dev+0x78/0xed [ 4.827627] [<ffffffff866ce412>] ? subsys_interface_register+0xd6/0x117 [ 4.827630] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827632] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827636] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827639] [<ffffffff86f83d43>] ? acpi_cpufreq_init+0x215/0x282 [ 4.827641] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827645] [<ffffffff8620046e>] ? do_one_initcall+0x9c/0x12e [ 4.827649] [<ffffffff86f3d058>] ? kernel_init_freeable+0x190/0x22b [ 4.827651] [<ffffffff869e59d9>] ? rest_init+0x7c/0x7c [ 4.827653] [<ffffffff869e59e3>] ? kernel_init+0xa/0xf3 [ 4.827656] [<ffffffff869ed482>] ? ret_from_fork+0x22/0x30 On ACPI based systems, for CPUs with uninitialized rq->max_freq skip the re-calculation. Reference discussion on a similar issue here: https://www.spinics.net/lists/arm-kernel/msg557612.html Change-Id: I5025e3f6db671e9e72369f85708d3b0482d5dad2 Signed-off-by: Abhilash Kesavan <abhilash.kesavan@intel.com>
duhansysl
pushed a commit
that referenced
this pull request
Sep 5, 2024
[ Upstream commit 1b1d622 ] Bug was noticed via this warning: WARNING: CPU: 6 PID: 1 at kernel/sched/sched.h:804 detach_task_cfs_rq+0x8e8/0xb80 rq->clock_update_flags < RQCF_ACT_SKIP Modules linked in: CPU: 6 PID: 1 Comm: systemd Not tainted 4.10.0-rc5-00140-g0874170baf55-dirty #1 Hardware name: Supermicro SYS-4048B-TRFT/X10QBi, BIOS 1.0 04/11/2014 Call Trace: dump_stack+0x4d/0x65 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 detach_task_cfs_rq+0x8e8/0xb80 ? allocate_cgrp_cset_links+0x59/0x80 task_change_group_fair+0x27/0x150 sched_change_group+0x48/0xf0 sched_move_task+0x53/0x150 cpu_cgroup_attach+0x36/0x70 cgroup_taskset_migrate+0x175/0x300 cgroup_migrate+0xab/0xd0 cgroup_attach_task+0xf0/0x190 __cgroup_procs_write+0x1ed/0x2f0 cgroup_procs_write+0x14/0x20 cgroup_file_write+0x3f/0x100 kernfs_fop_write+0x104/0x180 __vfs_write+0x37/0x140 vfs_write+0xb8/0x1b0 SyS_write+0x55/0xc0 do_syscall_64+0x61/0x170 entry_SYSCALL64_slow_path+0x25/0x25 Reported-by: Ingo Molnar <mingo@kernel.org> Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
duhansysl
pushed a commit
that referenced
this pull request
Sep 10, 2024
On systems using ACPI cpufreq, at boot-time only CPU0 max_freq has been populated when load_scale_factor/capacity recomputation is triggered on all possible cpus. This leads to the following divide by zero panic when rq->max_freq for any cpu other than CPU0 is accessed: [ 4.827597] divide error: 0000 [#1] PREEMPT SMP [ 4.827604] [<ffffffff862ad88e>] ? notifier_call_chain+0x37/0x57 [ 4.827607] [<ffffffff862adaf3>] ? __blocking_notifier_call_chain+0x46/0x5c [ 4.827611] [<ffffffff8684b9f4>] ? cpufreq_set_policy+0xa6/0x2dc [ 4.827614] [<ffffffff869e4d55>] ? cpufreq_init_policy+0xba/0xde [ 4.827617] [<ffffffff8684bd4c>] ? cpufreq_update_policy+0x122/0x122 [ 4.827620] [<ffffffff8684c51c>] ? cpufreq_online+0x5a7/0x64e [ 4.827623] [<ffffffff8684c63b>] ? cpufreq_add_dev+0x78/0xed [ 4.827627] [<ffffffff866ce412>] ? subsys_interface_register+0xd6/0x117 [ 4.827630] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827632] [<ffffffff8684b410>] ? cpufreq_register_driver+0x168/0x2b2 [ 4.827636] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827639] [<ffffffff86f83d43>] ? acpi_cpufreq_init+0x215/0x282 [ 4.827641] [<ffffffff86f83b2e>] ? cpufreq_gov_dbs_init+0xc/0xc [ 4.827645] [<ffffffff8620046e>] ? do_one_initcall+0x9c/0x12e [ 4.827649] [<ffffffff86f3d058>] ? kernel_init_freeable+0x190/0x22b [ 4.827651] [<ffffffff869e59d9>] ? rest_init+0x7c/0x7c [ 4.827653] [<ffffffff869e59e3>] ? kernel_init+0xa/0xf3 [ 4.827656] [<ffffffff869ed482>] ? ret_from_fork+0x22/0x30 On ACPI based systems, for CPUs with uninitialized rq->max_freq skip the re-calculation. Reference discussion on a similar issue here: https://www.spinics.net/lists/arm-kernel/msg557612.html Change-Id: I5025e3f6db671e9e72369f85708d3b0482d5dad2 Signed-off-by: Abhilash Kesavan <abhilash.kesavan@intel.com>
duhansysl
pushed a commit
that referenced
this pull request
Sep 10, 2024
[ Upstream commit 1b1d622 ] Bug was noticed via this warning: WARNING: CPU: 6 PID: 1 at kernel/sched/sched.h:804 detach_task_cfs_rq+0x8e8/0xb80 rq->clock_update_flags < RQCF_ACT_SKIP Modules linked in: CPU: 6 PID: 1 Comm: systemd Not tainted 4.10.0-rc5-00140-g0874170baf55-dirty #1 Hardware name: Supermicro SYS-4048B-TRFT/X10QBi, BIOS 1.0 04/11/2014 Call Trace: dump_stack+0x4d/0x65 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 detach_task_cfs_rq+0x8e8/0xb80 ? allocate_cgrp_cset_links+0x59/0x80 task_change_group_fair+0x27/0x150 sched_change_group+0x48/0xf0 sched_move_task+0x53/0x150 cpu_cgroup_attach+0x36/0x70 cgroup_taskset_migrate+0x175/0x300 cgroup_migrate+0xab/0xd0 cgroup_attach_task+0xf0/0x190 __cgroup_procs_write+0x1ed/0x2f0 cgroup_procs_write+0x14/0x20 cgroup_file_write+0x3f/0x100 kernfs_fop_write+0x104/0x180 __vfs_write+0x37/0x140 vfs_write+0xb8/0x1b0 SyS_write+0x55/0xc0 do_syscall_64+0x61/0x170 entry_SYSCALL64_slow_path+0x25/0x25 Reported-by: Ingo Molnar <mingo@kernel.org> Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
duhansysl
pushed a commit
that referenced
this pull request
Sep 10, 2024
Syzbot recently found a number of issues related to incremental-fs (see bug numbers below). All have to do with the fact that incr-fs allows mounts of the same source and target multiple times. The correct behavior for a file system is to allow only one such mount, and then every subsequent attempt should fail with a -EBUSY error code. In case of the issues listed below the common pattern is that the reproducer calls: mount("./file0", "./file0", "incremental-fs", 0, NULL) many times and then invokes a file operation like chmod, setxattr, or open on the ./file0. This causes a recursive call for all the mounted instances, which eventually causes a stack overflow and a kernel crash: BUG: stack guard page was hit at ffffc90000c0fff8 kernel stack overflow (double-fault): 0000 [#1] PREEMPT SMP KASAN The reason why many mounts with the same source and target are possible is because the incfs_mount_fs() as it is allocates a new super_block for every call, regardless of whether a given mount already exists or not. This happens every time the sget() function is called with a test param equal to NULL. The correct behavior for an FS mount implementation is to call appropriate mount vfs call for it's type, i.e. mount_bdev() for a block device backed FS, mount_single() for a pseudo file system, like sysfs that is mounted in a single, well know location, or mount_nodev() for other special purpose FS like overlayfs. In case of incremental-fs the open coded mount logic doesn't check for abusive mount attempts such as overlays. To fix this issue the logic needs to be changed to pass a proper test function to sget() call, which then checks if a super_block for a mount instance has already been allocated and also allows the VFS to properly verify invalid mount attempts. Bug: 211066171 Bug: 213140206 Bug: 213215835 Bug: 211914587 Bug: 211213635 Bug: 213137376 Bug: 211161296 Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org> Change-Id: I66cfc3f1b5aaffb32b0845b2dad3ff26fe952e27
duhansysl
pushed a commit
that referenced
this pull request
Sep 10, 2024
Syzbot recently found a number of issues related to incremental-fs (see bug numbers below). All have to do with the fact that incr-fs allows mounts of the same source and target multiple times. This is a design decision and the user space component "Data Loader" expects this to work for app re-install use case. The mounting depth needs to be controlled, however, and only allowed to be two levels deep. In case of more than two mount attempts the driver needs to return an error. In case of the issues listed below the common pattern is that the reproducer calls: mount("./file0", "./file0", "incremental-fs", 0, NULL) many times and then invokes a file operation like chmod, setxattr, or open on the ./file0. This causes a recursive call for all the mounted instances, which eventually causes a stack overflow and a kernel crash: BUG: stack guard page was hit at ffffc90000c0fff8 kernel stack overflow (double-fault): 0000 [#1] PREEMPT SMP KASAN This change also cleans up the mount error path to properly clean allocated resources and call deactivate_locked_super(), which causes the incfs_kill_sb() to be called, where the sb is freed. Bug: 211066171 Bug: 213140206 Bug: 213215835 Bug: 211914587 Bug: 211213635 Bug: 213137376 Bug: 211161296 Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org> Change-Id: I08d9b545a2715423296bf4beb67bdbbed78d1be1
ExtremeXT
pushed a commit
to ExtremeXT/exynos9810-kernel
that referenced
this pull request
Feb 3, 2025
syzbot reported a possible deadlock in perf_event_detach_bpf_prog. The error details: ====================================================== WARNING: possible circular locking dependency detected 4.16.0-rc7+ duhansysl#3 Not tainted ------------------------------------------------------ syz-executor7/24531 is trying to acquire lock: (bpf_event_mutex){+.+.}, at: [<000000008a849b07>] perf_event_detach_bpf_prog+0x92/0x3d0 kernel/trace/bpf_trace.c:854 but task is already holding lock: (&mm->mmap_sem){++++}, at: [<0000000038768f87>] vm_mmap_pgoff+0x198/0x280 mm/util.c:353 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> duhansysl#1 (&mm->mmap_sem){++++}: __might_fault+0x13a/0x1d0 mm/memory.c:4571 _copy_to_user+0x2c/0xc0 lib/usercopy.c:25 copy_to_user include/linux/uaccess.h:155 [inline] bpf_prog_array_copy_info+0xf2/0x1c0 kernel/bpf/core.c:1694 perf_event_query_prog_array+0x1c7/0x2c0 kernel/trace/bpf_trace.c:891 _perf_ioctl kernel/events/core.c:4750 [inline] perf_ioctl+0x3e1/0x1480 kernel/events/core.c:4770 vfs_ioctl fs/ioctl.c:46 [inline] do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686 SYSC_ioctl fs/ioctl.c:701 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 -> #0 (bpf_event_mutex){+.+.}: lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920 __mutex_lock_common kernel/locking/mutex.c:756 [inline] __mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908 perf_event_detach_bpf_prog+0x92/0x3d0 kernel/trace/bpf_trace.c:854 perf_event_free_bpf_prog kernel/events/core.c:8147 [inline] _free_event+0xbdb/0x10f0 kernel/events/core.c:4116 put_event+0x24/0x30 kernel/events/core.c:4204 perf_mmap_close+0x60d/0x1010 kernel/events/core.c:5172 remove_vma+0xb4/0x1b0 mm/mmap.c:172 remove_vma_list mm/mmap.c:2490 [inline] do_munmap+0x82a/0xdf0 mm/mmap.c:2731 mmap_region+0x59e/0x15a0 mm/mmap.c:1646 do_mmap+0x6c0/0xe00 mm/mmap.c:1483 do_mmap_pgoff include/linux/mm.h:2223 [inline] vm_mmap_pgoff+0x1de/0x280 mm/util.c:355 SYSC_mmap_pgoff mm/mmap.c:1533 [inline] SyS_mmap_pgoff+0x462/0x5f0 mm/mmap.c:1491 SYSC_mmap arch/x86/kernel/sys_x86_64.c:100 [inline] SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:91 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(bpf_event_mutex); lock(&mm->mmap_sem); lock(bpf_event_mutex); *** DEADLOCK *** ====================================================== The bug is introduced by Commit f371b304f12e ("bpf/tracing: allow user space to query prog array on the same tp") where copy_to_user, which requires mm->mmap_sem, is called inside bpf_event_mutex lock. At the same time, during perf_event file descriptor close, mm->mmap_sem is held first and then subsequent perf_event_detach_bpf_prog needs bpf_event_mutex lock. Such a senario caused a deadlock. As suggested by Daniel, moving copy_to_user out of the bpf_event_mutex lock should fix the problem. Fixes: f371b304f12e ("bpf/tracing: allow user space to query prog array on the same tp") Reported-by: syzbot+dc5ca0e4c9bfafaf2bae@syzkaller.appspotmail.com Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
duhansysl
pushed a commit
that referenced
this pull request
Feb 4, 2025
syzbot reported a possible deadlock in perf_event_detach_bpf_prog. The error details: ====================================================== WARNING: possible circular locking dependency detected 4.16.0-rc7+ #3 Not tainted ------------------------------------------------------ syz-executor7/24531 is trying to acquire lock: (bpf_event_mutex){+.+.}, at: [<000000008a849b07>] perf_event_detach_bpf_prog+0x92/0x3d0 kernel/trace/bpf_trace.c:854 but task is already holding lock: (&mm->mmap_sem){++++}, at: [<0000000038768f87>] vm_mmap_pgoff+0x198/0x280 mm/util.c:353 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++}: __might_fault+0x13a/0x1d0 mm/memory.c:4571 _copy_to_user+0x2c/0xc0 lib/usercopy.c:25 copy_to_user include/linux/uaccess.h:155 [inline] bpf_prog_array_copy_info+0xf2/0x1c0 kernel/bpf/core.c:1694 perf_event_query_prog_array+0x1c7/0x2c0 kernel/trace/bpf_trace.c:891 _perf_ioctl kernel/events/core.c:4750 [inline] perf_ioctl+0x3e1/0x1480 kernel/events/core.c:4770 vfs_ioctl fs/ioctl.c:46 [inline] do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686 SYSC_ioctl fs/ioctl.c:701 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 -> #0 (bpf_event_mutex){+.+.}: lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920 __mutex_lock_common kernel/locking/mutex.c:756 [inline] __mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908 perf_event_detach_bpf_prog+0x92/0x3d0 kernel/trace/bpf_trace.c:854 perf_event_free_bpf_prog kernel/events/core.c:8147 [inline] _free_event+0xbdb/0x10f0 kernel/events/core.c:4116 put_event+0x24/0x30 kernel/events/core.c:4204 perf_mmap_close+0x60d/0x1010 kernel/events/core.c:5172 remove_vma+0xb4/0x1b0 mm/mmap.c:172 remove_vma_list mm/mmap.c:2490 [inline] do_munmap+0x82a/0xdf0 mm/mmap.c:2731 mmap_region+0x59e/0x15a0 mm/mmap.c:1646 do_mmap+0x6c0/0xe00 mm/mmap.c:1483 do_mmap_pgoff include/linux/mm.h:2223 [inline] vm_mmap_pgoff+0x1de/0x280 mm/util.c:355 SYSC_mmap_pgoff mm/mmap.c:1533 [inline] SyS_mmap_pgoff+0x462/0x5f0 mm/mmap.c:1491 SYSC_mmap arch/x86/kernel/sys_x86_64.c:100 [inline] SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:91 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(bpf_event_mutex); lock(&mm->mmap_sem); lock(bpf_event_mutex); *** DEADLOCK *** ====================================================== The bug is introduced by Commit f371b304f12e ("bpf/tracing: allow user space to query prog array on the same tp") where copy_to_user, which requires mm->mmap_sem, is called inside bpf_event_mutex lock. At the same time, during perf_event file descriptor close, mm->mmap_sem is held first and then subsequent perf_event_detach_bpf_prog needs bpf_event_mutex lock. Such a senario caused a deadlock. As suggested by Daniel, moving copy_to_user out of the bpf_event_mutex lock should fix the problem. Fixes: f371b304f12e ("bpf/tracing: allow user space to query prog array on the same tp") Reported-by: syzbot+dc5ca0e4c9bfafaf2bae@syzkaller.appspotmail.com Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
duhansysl
pushed a commit
that referenced
this pull request
Feb 8, 2025
syzbot reported a possible deadlock in perf_event_detach_bpf_prog. The error details: ====================================================== WARNING: possible circular locking dependency detected 4.16.0-rc7+ #3 Not tainted ------------------------------------------------------ syz-executor7/24531 is trying to acquire lock: (bpf_event_mutex){+.+.}, at: [<000000008a849b07>] perf_event_detach_bpf_prog+0x92/0x3d0 kernel/trace/bpf_trace.c:854 but task is already holding lock: (&mm->mmap_sem){++++}, at: [<0000000038768f87>] vm_mmap_pgoff+0x198/0x280 mm/util.c:353 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++}: __might_fault+0x13a/0x1d0 mm/memory.c:4571 _copy_to_user+0x2c/0xc0 lib/usercopy.c:25 copy_to_user include/linux/uaccess.h:155 [inline] bpf_prog_array_copy_info+0xf2/0x1c0 kernel/bpf/core.c:1694 perf_event_query_prog_array+0x1c7/0x2c0 kernel/trace/bpf_trace.c:891 _perf_ioctl kernel/events/core.c:4750 [inline] perf_ioctl+0x3e1/0x1480 kernel/events/core.c:4770 vfs_ioctl fs/ioctl.c:46 [inline] do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686 SYSC_ioctl fs/ioctl.c:701 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 -> #0 (bpf_event_mutex){+.+.}: lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920 __mutex_lock_common kernel/locking/mutex.c:756 [inline] __mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908 perf_event_detach_bpf_prog+0x92/0x3d0 kernel/trace/bpf_trace.c:854 perf_event_free_bpf_prog kernel/events/core.c:8147 [inline] _free_event+0xbdb/0x10f0 kernel/events/core.c:4116 put_event+0x24/0x30 kernel/events/core.c:4204 perf_mmap_close+0x60d/0x1010 kernel/events/core.c:5172 remove_vma+0xb4/0x1b0 mm/mmap.c:172 remove_vma_list mm/mmap.c:2490 [inline] do_munmap+0x82a/0xdf0 mm/mmap.c:2731 mmap_region+0x59e/0x15a0 mm/mmap.c:1646 do_mmap+0x6c0/0xe00 mm/mmap.c:1483 do_mmap_pgoff include/linux/mm.h:2223 [inline] vm_mmap_pgoff+0x1de/0x280 mm/util.c:355 SYSC_mmap_pgoff mm/mmap.c:1533 [inline] SyS_mmap_pgoff+0x462/0x5f0 mm/mmap.c:1491 SYSC_mmap arch/x86/kernel/sys_x86_64.c:100 [inline] SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:91 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(bpf_event_mutex); lock(&mm->mmap_sem); lock(bpf_event_mutex); *** DEADLOCK *** ====================================================== The bug is introduced by Commit f371b304f12e ("bpf/tracing: allow user space to query prog array on the same tp") where copy_to_user, which requires mm->mmap_sem, is called inside bpf_event_mutex lock. At the same time, during perf_event file descriptor close, mm->mmap_sem is held first and then subsequent perf_event_detach_bpf_prog needs bpf_event_mutex lock. Such a senario caused a deadlock. As suggested by Daniel, moving copy_to_user out of the bpf_event_mutex lock should fix the problem. Fixes: f371b304f12e ("bpf/tracing: allow user space to query prog array on the same tp") Reported-by: syzbot+dc5ca0e4c9bfafaf2bae@syzkaller.appspotmail.com Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.