Skip to content
Snippets Groups Projects
  1. Jul 15, 2024
  2. May 09, 2024
    • Masahiro Yamada's avatar
      kbuild: use $(src) instead of $(srctree)/$(src) for source directory · b1992c37
      Masahiro Yamada authored
      
      Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
      checked-in source files. It is merely a convention without any functional
      difference. In fact, $(obj) and $(src) are exactly the same, as defined
      in scripts/Makefile.build:
      
          src := $(obj)
      
      When the kernel is built in a separate output directory, $(src) does
      not accurately reflect the source directory location. While Kbuild
      resolves this discrepancy by specifying VPATH=$(srctree) to search for
      source files, it does not cover all cases. For example, when adding a
      header search path for local headers, -I$(srctree)/$(src) is typically
      passed to the compiler.
      
      This introduces inconsistency between upstream and downstream Makefiles
      because $(src) is used instead of $(srctree)/$(src) for the latter.
      
      To address this inconsistency, this commit changes the semantics of
      $(src) so that it always points to the directory in the source tree.
      
      Going forward, the variables used in Makefiles will have the following
      meanings:
      
        $(obj)     - directory in the object tree
        $(src)     - directory in the source tree  (changed by this commit)
        $(objtree) - the top of the kernel object tree
        $(srctree) - the top of the kernel source tree
      
      Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
      with $(src).
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <nicolas@fjasle.eu>
      b1992c37
  3. Dec 29, 2023
    • Dmitry Safonov's avatar
      gen_init_cpio: Apply mtime supplied by user to all file types · f3b2306b
      Dmitry Safonov authored
      
      Currently gen_init_cpio -d <timestamp> is applied to symlinks,
      directories and special files. These files are created by
      gen_init_cpio from their description. Without <timestamp> option
      current time(NULL) is used. And regular files that go in initramfs
      are created before cpio generation, so their mtime(s) are preserved.
      
      This is usually not an issue as reproducible builds should rebuild
      everything in the distribution, including binaries, configs and whatever
      other regular files may find their way into kernel's initramfs.
      
      On the other hand, gen_initramfs.sh usage claims:
      >	-d <date>      Use date for all file mtime values
      
      Ar Arista initramfs files are managed with version control system
      that preserves mtime. Those are configs, boot parameters, init scripts,
      version files, platform-specific files, probably some others, too.
      
      While it's certainly possible to work this around by copying the file
      into temp directory and adjusting mtime prior to gen_init_cpio call,
      I don't see why it needs workarounds.
      
      The intended user of -d <date> option is the one that needs to create
      a reproducible build, see commit a8b8017c ("initramfs: Use
      KBUILD_BUILD_TIMESTAMP for generated entries"). If a user wants
      the build reproduction, they use -d <date>, which can be set on all
      types of files, without surprising exceptions and workarounds.
      Let's KISS here and just apply the time that user specified
      with -d option.
      
      Based-on-a-patch-by: default avatarBaptiste Covolato <baptiste@arista.com>
      Link: https://lore.kernel.org/lkml/20181025215133.20138-1-baptiste@arista.com/
      
      
      Signed-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      f3b2306b
  4. Dec 20, 2023
  5. Sep 11, 2023
    • Ard Biesheuvel's avatar
      arch: Remove Itanium (IA-64) architecture · cf8e8658
      Ard Biesheuvel authored
      The Itanium architecture is obsolete, and an informal survey [0] reveals
      that any residual use of Itanium hardware in production is mostly HP-UX
      or OpenVMS based. The use of Linux on Itanium appears to be limited to
      enthusiasts that occasionally boot a fresh Linux kernel to see whether
      things are still working as intended, and perhaps to churn out some
      distro packages that are rarely used in practice.
      
      None of the original companies behind Itanium still produce or support
      any hardware or software for the architecture, and it is listed as
      'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers
      that contributed on behalf of those companies (nor anyone else, for that
      matter) have been willing to support or maintain the architecture
      upstream or even be responsible for applying the odd fix. The Intel
      firmware team removed all IA-64 support from the Tianocore/EDK2
      reference implementation of EFI in 2018. (Itanium is the original
      architecture for which EFI was developed, and the way Linux supports it
      deviates significantly from other architectures.) Some distros, such as
      Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have
      dropped support years ago.
      
      While the argument is being made [1] that there is a 'for the common
      good' angle to being able to build and run existing projects such as the
      Grid Community Toolkit [2] on Itanium for interoperability testing, the
      fact remains that none of those projects are known to be deployed on
      Linux/ia64, and very few people actually have access to such a system in
      the first place. Even if there were ways imaginable in which Linux/ia64
      could be put to good use today, what matters is whether anyone is
      actually doing that, and this does not appear to be the case.
      
      There are no emulators widely available, and so boot testing Itanium is
      generally infeasible for ordinary contributors. GCC still supports IA-64
      but its compile farm [3] no longer has any IA-64 machines. GLIBC would
      like to get rid of IA-64 [4] too because it would permit some overdue
      code cleanups. In summary, the benefits to the ecosystem of having IA-64
      be part of it are mostly theoretical, whereas the maintenance overhead
      of keeping it supported is real.
      
      So let's rip off the band aid, and remove the IA-64 arch code entirely.
      This follows the timeline proposed by the Debian/ia64 maintainer [5],
      which removes support in a controlled manner, leaving IA-64 in a known
      good state in the most recent LTS release. Other projects will follow
      once the kernel support is removed.
      
      [0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/
      [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/
      [2] https://gridcf.org/gct-docs/latest/index.html
      [3] https://cfarm.tetaneutral.net/machines/list/
      [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/
      [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/
      
      
      
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      cf8e8658
  6. Jun 06, 2023
  7. Apr 16, 2023
  8. Oct 03, 2022
  9. May 13, 2022
    • Masahiro Yamada's avatar
      sparc: add asm/stat.h to UAPI compile-test coverage · 31a088b6
      Masahiro Yamada authored
      
      asm/stat.h is currently excluded from the UAPI compile-test for
      ARCH=sparc because of the errors like follows:
      
        In file included from <command-line>:
        ./usr/include/asm/stat.h:11:2: error: unknown type name 'ino_t'
           11 |  ino_t   st_ino;
              |  ^~~~~
          HDRTEST usr/include/asm/param.h
        ./usr/include/asm/stat.h:12:2: error: unknown type name 'mode_t'
           12 |  mode_t  st_mode;
              |  ^~~~~~
        ./usr/include/asm/stat.h:14:2: error: unknown type name 'uid_t'
           14 |  uid_t   st_uid;
              |  ^~~~~
        ./usr/include/asm/stat.h:15:2: error: unknown type name 'gid_t'
           15 |  gid_t   st_gid;
              |  ^~~~~
      
      The errors can be fixed by prefixing the types with __kernel_.
      
      Then, remove the no-header-test entry from user/include/Makefile.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      31a088b6
    • Masahiro Yamada's avatar
      powerpc: add asm/stat.h to UAPI compile-test coverage · c01013a2
      Masahiro Yamada authored
      
      asm/stat.h is currently excluded from the UAPI compile-test for
      ARCH=powerpc because of the errors like follows:
      
          HDRTEST usr/include/asm/stat.h
        In file included from <command-line>:32:
        ./usr/include/asm/stat.h:32:2: error: unknown type name 'ino_t'
           32 |  ino_t  st_ino;
              |  ^~~~~
        ./usr/include/asm/stat.h:35:2: error: unknown type name 'mode_t'
           35 |  mode_t  st_mode;
              |  ^~~~~~
        ./usr/include/asm/stat.h:40:2: error: unknown type name 'uid_t'
           40 |  uid_t  st_uid;
              |  ^~~~~
        ./usr/include/asm/stat.h:41:2: error: unknown type name 'gid_t'
           41 |  gid_t  st_gid;
              |  ^~~~~
      
      The errors can be fixed by prefixing the types with __kernel_.
      
      Then, remove the no-header-test entry from user/include/Makefile.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      c01013a2
    • Masahiro Yamada's avatar
      mips: add asm/stat.h to UAPI compile-test coverage · 8c1a381a
      Masahiro Yamada authored
      
      asm/stat.h is currently excluded from the UAPI compile-test for
      ARCH=mips because of the errors like follows:
      
          HDRTEST usr/include/asm/stat.h
        In file included from <command-line>:32:
        ./usr/include/asm/stat.h:22:2: error: unknown type name 'ino_t'
           22 |  ino_t  st_ino;
              |  ^~~~~
        ./usr/include/asm/stat.h:23:2: error: unknown type name 'mode_t'
           23 |  mode_t  st_mode;
              |  ^~~~~~
        ./usr/include/asm/stat.h:25:2: error: unknown type name 'uid_t'
           25 |  uid_t  st_uid;
              |  ^~~~~
        ./usr/include/asm/stat.h:26:2: error: unknown type name 'gid_t'
           26 |  gid_t  st_gid;
              |  ^~~~~
        ./usr/include/asm/stat.h:58:2: error: unknown type name 'mode_t'
           58 |  mode_t  st_mode;
              |  ^~~~~~
        ./usr/include/asm/stat.h:61:2: error: unknown type name 'uid_t'
           61 |  uid_t  st_uid;
              |  ^~~~~
        ./usr/include/asm/stat.h:62:2: error: unknown type name 'gid_t'
           62 |  gid_t  st_gid;
              |  ^~~~~
      
      The errors can be fixed by prefixing the types with __kernel_.
      
      Then, remove the no-header-test entry from user/include/Makefile.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      8c1a381a
    • Masahiro Yamada's avatar
      riscv: add linux/bpf_perf_event.h to UAPI compile-test coverage · 5c41778e
      Masahiro Yamada authored
      
      I can compile this for ARCH=riscv with CONFIG_UAPI_HEADER_TEST=y.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      5c41778e
    • Masahiro Yamada's avatar
      kbuild: prevent exported headers from including <stdlib.h>, <stdbool.h> · 02a6e4be
      Masahiro Yamada authored
      
      Some UAPI headers included <stdlib.h>, like this:
      
        #ifndef __KERNEL__
        #include <stdlib.h>
        #endif
      
      As it turned out, they just included it for no good reason.
      
      After some fixes, now I can compile-test UAPI headers
      (CONFIG_UAPI_HEADER_TEST=y) without including <stdlib.h> from the
      system header search paths.
      
      To avoid somebody getting it back again, this commit adds the dummy
      header, usr/dummy-include/stdlib.h
      
      I added $(srctree)/usr/dummy-include to the header search paths.
      Because it is searched before the system directories, if someone
      tries to include <stdlib.h>, they will see the error message.
      
      While I am here, I also replaced $(objtree)/usr/include with $(obj),
      but it has no functional change.
      
      If we can make kernel headers self-contained (that is, none of exported
      kernel headers includes system headers), we will be able to add the
      -nostdinc flag, but that is much far from where we stand now.
      
      As a realistic solution, we can ban header inclusion individually by
      putting a dummy header into usr/dummy-include/.
      
      Currently, no header include <stdbool.h>. I put it as well before somebody
      attempts to use it.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02a6e4be
  10. May 10, 2022
  11. Apr 05, 2022
  12. Mar 31, 2022
  13. Feb 17, 2022
  14. Feb 14, 2022
  15. Jan 27, 2022
  16. Jan 22, 2022
  17. Jan 13, 2022
    • Masahiro Yamada's avatar
      kbuild: rename cmd_{bzip2,lzma,lzo,lz4,xzkern,zstd22} · 7ce7e984
      Masahiro Yamada authored
      
      GZIP-compressed files end with 4 byte data that represents the size
      of the original input. The decompressors (the self-extracting kernel)
      exploit it to know the vmlinux size beforehand. To mimic the GZIP's
      trailer, Kbuild provides cmd_{bzip2,lzma,lzo,lz4,xzkern,zstd22}.
      Unfortunately these macros are used everywhere despite the appended
      size data is only useful for the decompressors.
      
      There is no guarantee that such hand-crafted trailers are safely ignored.
      In fact, the kernel refuses compressed initramdfs with the garbage data.
      That is why usr/Makefile overrides size_append to make it no-op.
      
      To limit the use of such broken compressed files, this commit renames
      the existing macros as follows:
      
        cmd_bzip2   --> cmd_bzip2_with_size
        cmd_lzma    --> cmd_lzma_with_size
        cmd_lzo     --> cmd_lzo_with_size
        cmd_lz4     --> cmd_lz4_with_size
        cmd_xzkern  --> cmd_xzkern_with_size
        cmd_zstd22  --> cmd_zstd22_with_size
      
      To keep the decompressors working, I updated the following Makefiles
      accordingly:
      
        arch/arm/boot/compressed/Makefile
        arch/h8300/boot/compressed/Makefile
        arch/mips/boot/compressed/Makefile
        arch/parisc/boot/compressed/Makefile
        arch/s390/boot/compressed/Makefile
        arch/sh/boot/compressed/Makefile
        arch/x86/boot/compressed/Makefile
      
      I reused the current macro names for the normal usecases; they produce
      the compressed data in the proper format.
      
      I did not touch the following:
      
        arch/arc/boot/Makefile
        arch/arm64/boot/Makefile
        arch/csky/boot/Makefile
        arch/mips/boot/Makefile
        arch/riscv/boot/Makefile
        arch/sh/boot/Makefile
        kernel/Makefile
      
      This means those Makefiles will stop appending the size data.
      
      I dropped the 'override size_append' hack from usr/Makefile.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      7ce7e984
  18. Jan 08, 2022
    • Masahiro Yamada's avatar
      kbuild: do not quote string values in include/config/auto.conf · 129ab0d2
      Masahiro Yamada authored
      
      The previous commit fixed up all shell scripts to not include
      include/config/auto.conf.
      
      Now that include/config/auto.conf is only included by Makefiles,
      we can change it into a more Make-friendly form.
      
      Previously, Kconfig output string values enclosed with double-quotes
      (both in the .config and include/config/auto.conf):
      
          CONFIG_X="foo bar"
      
      Unlike shell, Make handles double-quotes (and single-quotes as well)
      verbatim. We must rip them off when used.
      
      There are some patterns:
      
        [1] $(patsubst "%",%,$(CONFIG_X))
        [2] $(CONFIG_X:"%"=%)
        [3] $(subst ",,$(CONFIG_X))
        [4] $(shell echo $(CONFIG_X))
      
      These are not only ugly, but also fragile.
      
      [1] and [2] do not work if the value contains spaces, like
         CONFIG_X=" foo bar "
      
      [3] does not work correctly if the value contains double-quotes like
         CONFIG_X="foo\"bar"
      
      [4] seems to work better, but has a cost of forking a process.
      
      Anyway, quoted strings were always PITA for our Makefiles.
      
      This commit changes Kconfig to stop quoting in include/config/auto.conf.
      
      These are the string type symbols referenced in Makefiles or scripts:
      
          ACPI_CUSTOM_DSDT_FILE
          ARC_BUILTIN_DTB_NAME
          ARC_TUNE_MCPU
          BUILTIN_DTB_SOURCE
          CC_IMPLICIT_FALLTHROUGH
          CC_VERSION_TEXT
          CFG80211_EXTRA_REGDB_KEYDIR
          EXTRA_FIRMWARE
          EXTRA_FIRMWARE_DIR
          EXTRA_TARGETS
          H8300_BUILTIN_DTB
          INITRAMFS_SOURCE
          LOCALVERSION
          MODULE_SIG_HASH
          MODULE_SIG_KEY
          NDS32_BUILTIN_DTB
          NIOS2_DTB_SOURCE
          OPENRISC_BUILTIN_DTB
          SOC_CANAAN_K210_DTB_SOURCE
          SYSTEM_BLACKLIST_HASH_LIST
          SYSTEM_REVOCATION_KEYS
          SYSTEM_TRUSTED_KEYS
          TARGET_CPU
          UNUSED_KSYMS_WHITELIST
          XILINX_MICROBLAZE0_FAMILY
          XILINX_MICROBLAZE0_HW_VER
          XTENSA_VARIANT_NAME
      
      I checked them one by one, and fixed up the code where necessary.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      129ab0d2
    • Masahiro Yamada's avatar
      kbuild: move headers_check.pl to usr/include/ · 50a48340
      Masahiro Yamada authored
      
      This script is only used by usr/include/Makefile. Make it local to
      the directory.
      
      Update the comment in include/uapi/linux/soundcard.h because
      'make headers_check' is no longer functional.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      50a48340
  19. Oct 24, 2021
    • Nicolas Schier's avatar
      initramfs: Check timestamp to prevent broken cpio archive · 4c9d410f
      Nicolas Schier authored
      
      Cpio format reserves 8 bytes for an ASCII representation of a time_t timestamp.
      While 2106-02-07 06:28:15 UTC (time_t = 0xffffffff) is still some years in the
      future, a poorly chosen date string for KBUILD_BUILD_TIMESTAMP, converted into
      seconds since the epoch, might lead to exceeded cpio timestamp limits that
      result in a broken cpio archive.  Add timestamp checks to prevent overrun of
      the 8-byte cpio header field.
      
      My colleague Thomas Kühnel discovered the behaviour, when we accidentally fed
      SOURCE_DATE_EPOCH to KBUILD_BUILD_TIMESTAMP as is: some timestamps (e.g.
      1607420928 = 2021-12-08 9:48:48 UTC) will be interpreted by `date` as a valid
      date specification of science fictional times (here: year 160742).  Even though
      this is bad input for KBUILD_BUILD_TIMESTAMP, it should not break the initramfs
      cpio format.
      
      Signed-off-by: default avatarNicolas Schier <nicolas@fjasle.eu>
      Cc: Thomas Kühnel <thomas.kuehnel@avm.de>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      4c9d410f
  20. Oct 13, 2021
  21. May 01, 2021
  22. Feb 24, 2021
  23. Jan 22, 2021
  24. Jul 31, 2020
  25. Jul 27, 2020
    • Al Viro's avatar
      unexport linux/elfcore.h · 1e6b57d6
      Al Viro authored
      
      It's unusable from userland - it uses elf_gregset_t, which is not
      provided by exported headers.  glibc has it in sys/procfs.h, but
      the same file defines struct elf_prstatus, so linux/elfcore.h can't
      be included once sys/procfs.h has been pulled.  Same goes for uclibc
      and dietlibc simply doesn't have elf_gregset_t defined anywhere.
      
      IOW, no userland source is including that thing.
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      1e6b57d6
Loading