Skip to content
  1. Apr 01, 2024
  2. Mar 31, 2024
    • Isak Ellmer's avatar
      kconfig: Fix typo HEIGTH to HEIGHT · 89e5462b
      Isak Ellmer authored
      
      
      Fixed a typo in some variables where height was misspelled as heigth.
      
      Signed-off-by: default avatarIsak Ellmer <isak01@gmail.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      89e5462b
    • Nathan Chancellor's avatar
      Documentation/llvm: Note s390 LLVM=1 support with LLVM 18.1.0 and newer · 978fa00e
      Nathan Chancellor authored
      As of the first s390 pull request during the 6.9 merge window,
      commit 691632f0 ("Merge tag 's390-6.9-1' of
      git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux"
      
      ), s390 can be
      built with LLVM=1 when using LLVM 18.1.0, which is the first version
      that has SystemZ support implemented in ld.lld and llvm-objcopy.
      
      Update the supported architectures table in the Kbuild LLVM
      documentation to note this explicitly to make it more discoverable by
      users and other developers. Additionally, this brings s390 in line with
      the rest of the architectures in the table, which all support LLVM=1.
      
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      978fa00e
    • Borislav Petkov (AMD)'s avatar
      kbuild: Disable KCSAN for autogenerated *.mod.c intermediaries · 54babdc0
      Borislav Petkov (AMD) authored
      
      
      When KCSAN and CONSTRUCTORS are enabled, one can trigger the
      
        "Unpatched return thunk in use. This should not happen!"
      
      catch-all warning.
      
      Usually, when objtool runs on the .o objects, it does generate a section
      .return_sites which contains all offsets in the objects to the return
      thunks of the functions present there. Those return thunks then get
      patched at runtime by the alternatives.
      
      KCSAN and CONSTRUCTORS add this to the object file's .text.startup
      section:
      
        -------------------
        Disassembly of section .text.startup:
      
        ...
      
        0000000000000010 <_sub_I_00099_0>:
          10:   f3 0f 1e fa             endbr64
          14:   e8 00 00 00 00          call   19 <_sub_I_00099_0+0x9>
                                15: R_X86_64_PLT32      __tsan_init-0x4
          19:   e9 00 00 00 00          jmp    1e <__UNIQUE_ID___addressable_cryptd_alloc_aead349+0x6>
                                1a: R_X86_64_PLT32      __x86_return_thunk-0x4
        -------------------
      
      which, if it is built as a module goes through the intermediary stage of
      creating a <module>.mod.c file which, when translated, receives a second
      constructor:
      
        -------------------
        Disassembly of section .text.startup:
      
        0000000000000010 <_sub_I_00099_0>:
          10:   f3 0f 1e fa             endbr64
          14:   e8 00 00 00 00          call   19 <_sub_I_00099_0+0x9>
                                15: R_X86_64_PLT32      __tsan_init-0x4
          19:   e9 00 00 00 00          jmp    1e <_sub_I_00099_0+0xe>
                                1a: R_X86_64_PLT32      __x86_return_thunk-0x4
      
        ...
      
        0000000000000030 <_sub_I_00099_0>:
          30:   f3 0f 1e fa             endbr64
          34:   e8 00 00 00 00          call   39 <_sub_I_00099_0+0x9>
                                35: R_X86_64_PLT32      __tsan_init-0x4
          39:   e9 00 00 00 00          jmp    3e <__ksymtab_cryptd_alloc_ahash+0x2>
                                3a: R_X86_64_PLT32      __x86_return_thunk-0x4
        -------------------
      
      in the .ko file.
      
      Objtool has run already so that second constructor's return thunk cannot
      be added to the .return_sites section and thus the return thunk remains
      unpatched and the warning rightfully fires.
      
      Drop KCSAN flags from the mod.c generation stage as those constructors
      do not contain data races one would be interested about.
      
      Debugged together with David Kaplan <David.Kaplan@amd.com> and Nikolay
      Borisov <nik.borisov@suse.com>.
      
      Reported-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
      Closes: https://lore.kernel.org/r/0851a207-7143-417e-be31-8bf2b3afb57d@molgen.mpg.de
      
      
      Signed-off-by: default avatarBorislav Petkov (AMD) <bp@alien8.de>
      Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # Dell XPS 13
      Reviewed-by: default avatarNikolay Borisov <nik.borisov@suse.com>
      Reviewed-by: default avatarMarco Elver <elver@google.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      54babdc0
    • Arnd Bergmann's avatar
      kbuild: make -Woverride-init warnings more consistent · c40845e3
      Arnd Bergmann authored
      The -Woverride-init warn about code that may be intentional or not,
      but the inintentional ones tend to be real bugs, so there is a bit of
      disagreement on whether this warning option should be enabled by default
      and we have multiple settings in scripts/Makefile.extrawarn as well as
      individual subsystems.
      
      Older versions of clang only supported -Wno-initializer-overrides with
      the same meaning as gcc's -Woverride-init, though all supported versions
      now work with both. Because of this difference, an earlier cleanup of
      mine accidentally turned the clang warning off for W=1 builds and only
      left it on for W=2, while it's still enabled for gcc with W=1.
      
      There is also one driver that only turns the warning off for newer
      versions of gcc but not other compilers, and some but not all the
      Makefiles still use a cc-disable-warning conditional that is no
      longer needed with supported compilers here.
      
      Address all of the above by removing the special cases for clang
      and always turning the warning off unconditionally where it got
      in the way, using the syntax that is supported by both compilers.
      
      Fixes: 2cd3271b
      
       ("kbuild: avoid duplicate warning options")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarHamza Mahfooz <hamza.mahfooz@amd.com>
      Acked-by: default avatarJani Nikula <jani.nikula@intel.com>
      Acked-by: default avatarAndrew Jeffery <andrew@codeconstruct.com.au>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      c40845e3
    • Mikulas Patocka's avatar
      objtool: Fix compile failure when using the x32 compiler · 6205125b
      Mikulas Patocka authored
      
      
      When compiling the v6.9-rc1 kernel with the x32 compiler, the following
      errors are reported. The reason is that we take an "unsigned long"
      variable and print it using "PRIx64" format string.
      
      	In file included from check.c:16:
      	check.c: In function ‘add_dead_ends’:
      	/usr/src/git/linux-2.6/tools/objtool/include/objtool/warn.h:46:17: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 5 has type ‘long unsigned int’ [-Werror=format=]
      	   46 |                 "%s: warning: objtool: " format "\n",   \
      	      |                 ^~~~~~~~~~~~~~~~~~~~~~~~
      	check.c:613:33: note: in expansion of macro ‘WARN’
      	  613 |                                 WARN("can't find unreachable insn at %s+0x%" PRIx64,
      	      |                                 ^~~~
      	...
      
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: linux-kernel@vger.kernel.org
      6205125b
    • Linus Torvalds's avatar
      Merge tag 'xfs-6.9-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 712e1425
      Linus Torvalds authored
      Pull xfs fixes from Chandan Babu:
      
       - Allow stripe unit/width value passed via mount option to be written
         over existing values in the super block
      
       - Do not set current->journal_info to avoid its value from being miused
         by another filesystem context
      
      * tag 'xfs-6.9-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: don't use current->journal_info
        xfs: allow sunit mount option to repair bad primary sb stripe values
      712e1425