Skip to content
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 192 commits into from
Aug 9, 2024
Merged

Merge duhan_test into duhan_5.1 #1

merged 192 commits into from
Aug 9, 2024

Conversation

duhansysl
Copy link
Owner

No description provided.

ananjaser1211 and others added 30 commits July 27, 2024 04:26
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>
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
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>
zx2c4 and others added 9 commits August 9, 2024 14:08
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
* 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 duhansysl merged commit 5fedb78 into duhan_5.1 Aug 9, 2024
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.