Skip to content
Snippets Groups Projects
  1. Oct 03, 2022
  2. 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
  3. May 10, 2022
  4. Apr 05, 2022
  5. Mar 31, 2022
  6. Feb 17, 2022
  7. Feb 14, 2022
  8. Jan 27, 2022
  9. Jan 22, 2022
  10. 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
  11. 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
  12. 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
  13. Oct 13, 2021
  14. May 01, 2021
  15. Feb 24, 2021
  16. Jan 22, 2021
  17. Jul 31, 2020
  18. 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
  19. May 17, 2020
    • Masahiro Yamada's avatar
      bpfilter: match bit size of bpfilter_umh to that of the kernel · 9371f86e
      Masahiro Yamada authored
      
      bpfilter_umh is built for the default machine bit of the compiler,
      which may not match to the bit size of the kernel.
      
      This happens in the scenario below:
      
      You can use biarch GCC that defaults to 64-bit for building the 32-bit
      kernel. In this case, Kbuild passes -m32 to teach the compiler to
      produce 32-bit kernel space objects. However, it is missing when
      building bpfilter_umh. It is built as a 64-bit ELF, and then embedded
      into the 32-bit kernel.
      
      The 32-bit kernel and 64-bit umh is a bad combination.
      
      In theory, we can have 32-bit umh running on 64-bit kernel, but we do
      not have a good reason to support such a usecase.
      
      The best is to match the bit size between them.
      
      Pass -m32 or -m64 to the umh build command if it is found in
      $(KBUILD_CFLAGS). Evaluate CC_CAN_LINK against the kernel bit-size.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      9371f86e
  20. May 12, 2020
    • Masahiro Yamada's avatar
      kbuild: use -MMD instead of -MD to exclude system headers from dependency · 30a77297
      Masahiro Yamada authored
      
      This omits system headers from the generated header dependency.
      
      System headers are not updated unless you upgrade the compiler. Nor do
      they contain CONFIG options, so fixdep does not need to parse them.
      
      Having said that, the effect of this optimization will be quite small
      because the kernel code generally does not include system headers
      except <stdarg.h>. Host programs include a lot of system headers,
      but there are not so many in the kernel tree.
      
      At first, keeping system headers in .*.cmd files might be useful to
      detect the compiler update, but there is no guarantee that <stdarg.h>
      is included from every file. So, I implemented a more reliable way in
      the previous commit.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      30a77297
  21. Apr 11, 2020
  22. Mar 25, 2020
  23. Mar 17, 2020
    • Eugeniy Paltsev's avatar
      initramfs: restore default compression behavior · 785d74ec
      Eugeniy Paltsev authored
      
      Even though INITRAMFS_SOURCE kconfig option isn't set in most of
      defconfigs it is used (set) extensively by various build systems.
      Commit f26661e1 ("initramfs: make initramfs compression choice
      non-optional") has changed default compression mode. Previously we
      compress initramfs using available compression algorithm. Now
      we don't use any compression at all by default.
      It significantly increases the image size in case of build system
      chooses embedded initramfs. Initially I faced with this issue while
      using buildroot.
      
      As of today it's not possible to set preferred compression mode
      in target defconfig as this option depends on INITRAMFS_SOURCE
      being set. Modification of all build systems either doesn't look
      like good option.
      
      Let's instead rewrite initramfs compression mode choices list
      the way that "INITRAMFS_COMPRESSION_NONE" will be the last option
      in the list. In that case it will be chosen only if all other
      options (which implements any compression) are not available.
      
      Signed-off-by: default avatarEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      785d74ec
  24. Feb 03, 2020
    • Masahiro Yamada's avatar
      initramfs: do not show compression mode choice if INITRAMFS_SOURCE is empty · d4e9056d
      Masahiro Yamada authored
      Since commit ddd09bcc ("initramfs: make compression options not
      depend on INITRAMFS_SOURCE"), Kconfig asks the compression mode for
      the built-in initramfs regardless of INITRAMFS_SOURCE.
      
      It is technically simpler, but pointless from a UI perspective,
      Linus says [1].
      
      When INITRAMFS_SOURCE is empty, usr/Makefile creates a tiny default
      cpio, which is so small that nobody cares about the compression.
      
      This commit hides the Kconfig choice in that case. The default cpio
      is embedded without compression, which was the original behavior.
      
      [1]: https://lkml.org/lkml/2020/2/1/160
      
      
      
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d4e9056d
    • Masahiro Yamada's avatar
      kbuild: rename hostprogs-y/always to hostprogs/always-y · 5f2fb52f
      Masahiro Yamada authored
      
      In old days, the "host-progs" syntax was used for specifying host
      programs. It was renamed to the current "hostprogs-y" in 2004.
      
      It is typically useful in scripts/Makefile because it allows Kbuild to
      selectively compile host programs based on the kernel configuration.
      
      This commit renames like follows:
      
        always       ->  always-y
        hostprogs-y  ->  hostprogs
      
      So, scripts/Makefile will look like this:
      
        always-$(CONFIG_BUILD_BIN2C) += ...
        always-$(CONFIG_KALLSYMS)    += ...
            ...
        hostprogs := $(always-y) $(always-m)
      
      I think this makes more sense because a host program is always a host
      program, irrespective of the kernel configuration. We want to specify
      which ones to compile by CONFIG options, so always-y will be handier.
      
      The "always", "hostprogs-y", "hostprogs-m" will be kept for backward
      compatibility for a while.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      5f2fb52f
Loading