10 Aug, 2020

1 commit

  • To build host programs, you need to add the program names to 'hostprogs'
    to use the necessary build rule, but it is not enough to build them
    because there is no dependency.

    There are two types of host programs: built as the prerequisite of
    another (e.g. gen_crc32table in lib/Makefile), or always built when
    Kbuild visits the Makefile (e.g. genksyms in scripts/genksyms/Makefile).

    The latter is typical in Makefiles under scripts/, which contains host
    programs globally used during the kernel build. To build them, you need
    to add them to both 'hostprogs' and 'always-y'.

    This commit adds hostprogs-always-y as a shorthand.

    The same applies to user programs. net/bpfilter/Makefile builds
    bpfilter_umh on demand, hence always-y is unneeded. In contrast,
    programs under samples/ are added to both 'userprogs' and 'always-y'
    so they are always built when Kbuild visits the Makefiles.

    userprogs-always-y works as a shorthand.

    Signed-off-by: Masahiro Yamada
    Acked-by: Miguel Ojeda

    Masahiro Yamada
     

25 May, 2020

1 commit

  • The current codebase makes use of the zero-length array language
    extension to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning
    in case the flexible array does not occur last in the structure, which
    will help us prevent some kind of undefined behavior bugs from being
    inadvertently introduced[3] to the codebase from now on.

    Also, notice that, dynamic memory allocations won't be affected by
    this change:

    "Flexible array members have incomplete type, and so the sizeof operator
    may not be applied. As a quirk of the original implementation of
    zero-length arrays, sizeof evaluates to zero."[1]

    sizeof(flexible-array-member) triggers a warning because flexible array
    members have incomplete type[1]. There are some instances of code in
    which the sizeof operator is being incorrectly/erroneously applied to
    zero-length arrays and the result is zero. Such instances may be hiding
    some bugs. So, this work (flexible-array member conversions) will also
    help to get completely rid of those sorts of issues.

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: Masahiro Yamada

    Gustavo A. R. Silva
     

04 Apr, 2020

1 commit

  • Pull SPDX updates from Greg KH:
    "Here are three SPDX patches for 5.7-rc1.

    One fixes up the SPDX tag for a single driver, while the other two go
    through the tree and add SPDX tags for all of the .gitignore files as
    needed.

    Nothing too complex, but you will get a merge conflict with your
    current tree, that should be trivial to handle (one file modified by
    two things, one file deleted.)

    All three of these have been in linux-next for a while, with no
    reported issues other than the merge conflict"

    * tag 'spdx-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx:
    ASoC: MT6660: make spdxcheck.py happy
    .gitignore: add SPDX License Identifier
    .gitignore: remove too obvious comments

    Linus Torvalds
     

25 Mar, 2020

1 commit


02 Mar, 2020

2 commits


04 Feb, 2020

1 commit

  • 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: Masahiro Yamada

    Masahiro Yamada
     

29 Aug, 2019

1 commit


01 Jul, 2019

1 commit

  • When there is not enough space on your storage device, the build will
    fail with 'No space left on device' error message.

    The reason is obvious from the message, so you will free up some disk
    space, then you will resume the build.

    However, sometimes you may still see a mysterious error message:

    unterminated call to function 'wildcard': missing ')'.

    If you run out of the disk space, fixdep may end up with generating
    incomplete .*.cmd files.

    For example, if the disk-full error occurs while fixdep is running
    print_dep(), the .*.cmd might be truncated like this:

    $(wildcard include/config/

    When you run 'make' next time, this broken .*.cmd will be included,
    then Make will terminate parsing since it is a wrong syntax.

    Once this happens, you need to run 'make clean' or delete the broken
    .*.cmd file manually.

    Even if you do not see any error message, the .*.cmd files after any
    error could be potentially incomplete, and unreliable. You may miss
    the re-compilation due to missing header dependency.

    If printf() cannot output the string for disk shortage or whatever
    reason, it returns a negative value, but currently fixdep does not
    check it at all. Consequently, fixdep *successfully* generates a
    broken .*.cmd file. Make never notices that since fixdep exits with 0,
    which means success.

    Given the intended usage of fixdep, it must respect the return value
    of not only malloc(), but also printf() and putchar().

    This seems a long-standing issue since the introduction of fixdep.

    In old days, Kbuild tried to provide an extra safety by letting fixdep
    output to a temporary file and renaming it after everything is done:

    scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp;\
    rm -f $(depfile); \
    mv -f $(dot-target).tmp $(dot-target).cmd)

    It was no help to avoid the current issue; fixdep successfully created
    a truncated tmp file, which would be renamed to a .*.cmd file.

    This problem should be fixed by propagating the error status to the
    build system because:

    [1] Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
    target"), Make will delete the target automatically on any failure
    in the recipe.

    [2] Since commit 392885ee82d3 ("kbuild: let fixdep directly write to
    .*.cmd files"), .*.cmd file is included only when the corresponding
    target already exists.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

21 May, 2019

1 commit


01 Dec, 2018

1 commit

  • My main motivation of this commit is to clean up scripts/Kbuild.include
    and scripts/Makefile.build.

    Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick;
    possibly exported symbols are detected by letting $(CPP) replace
    EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is
    post-processed by sed, and passed to fixdep. The extra preprocessing
    is costly, and hacking cmd_and_fixdep is ugly.

    I came up with a new way to find exported symbols; insert a dummy
    symbol __ksym_marker_* to each potentially exported symbol. Those
    dummy symbols are picked up by $(NM), post-processed by sed, then
    appended to .*.cmd files. I collected the post-process part to a
    new shell script scripts/gen_ksymdeps.sh for readability. The dummy
    symbols are put into the .discard.* section so that the linker
    script rips them off the final vmlinux or modules.

    A nice side-effect is building with CONFIG_TRIM_UNUSED_KSYMS will
    be much faster.

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Nicolas Pitre

    Masahiro Yamada
     

18 Jul, 2018

1 commit

  • Commit 8370edea81e3 ("bin2c: move bin2c in scripts/basic") moved bin2c
    to the scripts/basic/ directory, incorrectly stating "Kexec wants to
    use bin2c and it wants to use it really early in the build process.
    See arch/x86/purgatory/ code in later patches."

    Commit bdab125c9301 ("Revert "kexec/purgatory: Add clean-up for
    purgatory directory"") and commit d6605b6bbee8 ("x86/build: Remove
    unnecessary preparation for purgatory") removed the redundant
    purgatory build magic entirely.

    That means that the move of bin2c was unnecessary in the first place.

    fixdep is the only host program that deserves to sit in the
    scripts/basic/ directory.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

07 May, 2018

1 commit


26 Mar, 2018

1 commit

  • The idea of using fixdep was inspired by Kconfig, but autoksyms
    belongs to a different group. So, I want to move those touched
    files under include/config/ksym/ to include/ksym/.

    The directory include/ksym/ can be removed by 'make clean' because
    it is meaningless for the external module building.

    Signed-off-by: Masahiro Yamada
    Acked-by: Nicolas Pitre

    Masahiro Yamada
     

05 Mar, 2018

3 commits

  • kconfig.h was excluded from consideration by fixdep by
    6a5be57f0f00 (fixdep: fix extraneous dependencies) to avoid some false
    positive hits

    (1) include/config/.h
    (2) include/config/h.h
    (3) include/config/foo.h

    (1) occurred because kconfig.h contains the string CONFIG_ in a
    comment. However, since dee81e988674 (fixdep: faster CONFIG_ search), we
    have a check that the part after CONFIG_ is non-empty, so this does not
    happen anymore (and CONFIG_ appears by itself elsewhere, so that check
    is worthwhile).

    (2) comes from the include guard, __LINUX_KCONFIG_H. But with the
    previous patch, we no longer match that either.

    That leaves (3), which amounts to one [1] false dependency (aka stat() call
    done by make), which I think we can live with:

    We've already had one case [2] where the lack of include/linux/kconfig.h in
    the .o.cmd file caused a missing rebuild, and while I originally thought
    we should just put kconfig.h in the dependency list without parsing it
    for the CONFIG_ pattern, we actually do have some real CONFIG_ symbols
    mentioned in it, and one can imagine some translation unit that just
    does '#ifdef __BIG_ENDIAN' but doesn't through some other header
    actually depend on CONFIG_CPU_BIG_ENDIAN - so changing the target
    endianness could end up rebuilding the world, minus that small
    TU. Quoting Linus,

    ... when missing dependencies cause a missed re-compile, the resulting
    bugs can be _really_ subtle.

    [1] well, two, we now also have CONFIG_BOOGER/booger.h - we could change
    that to FOO if we care

    [2] https://lkml.org/lkml/2018/2/22/838

    Cc: Linus Torvalds
    Signed-off-by: Rasmus Villemoes
    Signed-off-by: Masahiro Yamada

    Rasmus Villemoes
     
  • The string CONFIG_ quite often appears after other alphanumerics,
    meaning that that instance cannot be referencing a Kconfig
    symbol. Omitting these means make has fewer files to stat() when
    deciding what needs to be rebuilt - for a defconfig build, this seems to
    remove about 2% of the (wildcard ...) lines from the .o.cmd files.

    Signed-off-by: Rasmus Villemoes
    Signed-off-by: Masahiro Yamada

    Rasmus Villemoes
     
  • uml-config.h hasn't existed in this decade (87e299e5c750 - x86, um: get
    rid of uml-config.h). The few remaining UML_CONFIG instances are defined
    directly in terms of their real CONFIG symbol in common-offsets.h, so
    unlike when the symbols got defined via a sed script, anything that uses
    UML_CONFIG_FOO now should also automatically pick up a dependency on
    CONFIG_FOO via the normal fixdep mechanism (since common-offsets.h
    should at least recursively be a dependency). Hence I believe we should
    actually be able to ignore the HELLO_CONFIG_BOOM cases.

    Cc: Al Viro
    Cc: Richard Weinberger
    Cc: user-mode-linux-devel@lists.sourceforge.net
    Signed-off-by: Rasmus Villemoes
    Signed-off-by: Masahiro Yamada

    Rasmus Villemoes
     

18 Jan, 2018

7 commits

  • str_ends_with() tests if the given token ends with a particular string.
    Currently, it is used to check file paths without $(srctree).

    Actually, we have one more place where this helper is useful. Use it
    to check if CONFIG option ends with _MODULE.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • parse_dep_file() has too much indentation, and puts the code far to
    the right. This commit refactors the code and reduces the one level
    of indentation.

    strrcmp() computes 'slen' by itself, but the caller already knows the
    length of the token, so 'slen' can be passed via function argument.
    With this, we can swap the order of strrcmp() and "*p = \0;"

    Also, strrcmp() is an ambiguous function name. Flip the logic and
    rename it to str_ends_with().

    I added a new helper is_ignored_file() - this returns 1 if the token
    represents a file that should be ignored.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • I do not mind global variables where they are useful enough. In this
    case, I do not see a good reason to use global variables since they
    are just referenced in shallow places. It is easy to pass them via
    function arguments.

    I squashed print_cmdline() into main() since it is just one line code.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Each token in the depfile is copied to the temporary buffer 's' to
    terminate the token with zero. We do not need to do this any more
    because the parsed buffer is now writable. Insert '\0' directly in
    the buffer without calling memcpy().

    is no longer necessary. (It was needed for PATH_MAX).

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Now, do_config_files() and print_deps() are almost the same. Only
    the difference is the parser function called (parse_config_file vs
    parse_dep_file).

    We can reduce the code duplication by factoring out the common code
    into read_file() - this function allocates a buffer and loads a file
    to it. It returns the pointer to the allocated buffer. (As before,
    it bails out by exit(2) for any error.) The caller must free the
    buffer when done.

    Having empty source files is possible; fixdep should simply skip them.
    I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte
    buffer for an empty file. strstr() will immediately return NULL, and
    this is what we expect.

    On the other hand, an empty dep_file should be treated as an error.
    In this case, parse_dep_file() will error out with "no targets found"
    and it is a correct error message.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Commit dee81e988674 ("fixdep: faster CONFIG_ search") changed how to
    read files in which CONFIG options are searched. It used malloc()
    and read() instead of mmap() because it needed to zero-terminate the
    buffer in order to use strstr(). print_deps() was left untouched
    since there was no reason to change it.

    Now, I have two motivations to change it in the same way.

    - do_config_file() and print_deps() do quite similar things; they
    open a file, load it onto memory, and pass it to a parser function.
    If we use malloc() and read() for print_deps() too, we can factor
    out the common code. (I will do this in the next commit.)

    - parse_dep_file() copies each token to a temporary buffer because
    it needs to zero-terminate it to be passed to printf(). It is not
    possible to modify the buffer directly because it is mmap'ed with
    O_RDONLY. If we load the file content into a malloc'ed buffer, we
    can insert '\0' after each token, and save memcpy(). (I will do
    this in the commit after next.)

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • was included for ntohl(), but it was removed by
    commit dee81e988674 ("fixdep: faster CONFIG_ search").

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

08 Jan, 2018

1 commit

  • do_config_file() should exit with an error code on internal run-time
    errors, and not return if it fails as then the error in do_config_file()
    would go unnoticed in the current code and allow the build to continue.
    The exit with error code will make the build fail in those very
    exceptional cases. If this occurs, this actually indicates a deeper
    problem in the execution of the kernel build process.

    Now, in these error cases, we do not explicitly free memory and close
    the file handlers in do_config_file(), as this is covered by exit().

    This issue in the fixdep script was introduced with its initial
    implementation back in 2002 by the original author Kai Germaschewski with
    this commit 04bd72170653 ("kbuild: Make dependencies at compile time")
    in the linux history git tree, i.e.,
    git://git.kernel.org/pub/scm/linux/kernel/git/history/history.git.

    This issue was identified during the review of a previous patch that
    intended to address a memory leak detected by a static analysis tool.

    Link: https://lkml.org/lkml/2017/12/14/736

    Suggested-by: Nicholas Mc Guire
    Suggested-by: Masahiro Yamada
    Signed-off-by: Lukas Bulwahn
    Signed-off-by: Masahiro Yamada

    Lukas Bulwahn
     

10 Aug, 2017

1 commit


09 Aug, 2017

1 commit


25 Aug, 2016

1 commit

  • Do you think kernel build is 100% dominated by gcc? You are wrong!
    One small utility called "fixdep" consistently manages to sneak into
    profile's first page (unless you have small monitor of course).

    The choke point is this clever code:

    for (; m < end; m++) {
    if (*m == INT_CONF) { p = (char *) m ; goto conf; }
    if (*m == INT_ONFI) { p = (char *) m-1; goto conf; }
    if (*m == INT_NFIG) { p = (char *) m-2; goto conf; }
    if (*m == INT_FIG_) { p = (char *) m-3; goto conf; }

    4 branches per 4 characters is not fast.

    Use strstr(3), so that SSE2 etc can be used.

    With this patch, fixdep is so deep at the bottom, it is hard to find it.

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Michal Marek

    Alexey Dobriyan
     

22 Jul, 2016

1 commit

  • bin2c is used to create a valid C file out of a binary file where two
    symbols will be globally defined: and _size. is
    passed as the first parameter of the host binary.

    Building using goto-cc reported that the purgatory binary code (the only
    current user of this utility) declares kexec_purgatory_size as 'size_t'
    where bin2c generate _size to be 'int' so in a 64-bit host where
    sizeof(size_t) > sizeof(int) this type mismatch will always yield the
    wrong value for big-endian architectures while for little-endian it will
    be wrong if the object laid in memory directly after
    kexec_purgatory_size contains non-zero value at the time of reading.

    This commit changes _size to be size_t instead.

    Note:

    Another way to fix the problem is to change the type of
    kexec_purgatory_size to be 'int' as there's this check in code:
    (kexec_purgatory_size
    Cc: Vivek Goyal
    Acked-by: Dave Young
    Signed-off-by: Michal Marek

    Tautschnig, Michael
     

30 Mar, 2016

2 commits

  • Like with kconfig options, we now have the ability to compile in and
    out individual EXPORT_SYMBOL() declarations based on the content of
    include/generated/autoksyms.h. However we don't want the entire
    world to be rebuilt whenever that file is touched.

    Let's apply the same build dependency trick used for CONFIG_* symbols
    where the time stamp of empty files whose paths matching those symbols
    is used to trigger fine grained rebuilds. In our case the key is the
    symbol name passed to EXPORT_SYMBOL().

    However, unlike config options, we cannot just use fixdep to parse
    the source code for EXPORT_SYMBOL(ksym) because several variants exist
    and parsing them all in a separate tool, and keeping it in synch, is
    not trivially maintainable. Furthermore, there are variants such as

    EXPORT_SYMBOL_GPL(pci_user_read_config_##size);

    that are instanciated via a macro for which we can't easily determine
    the actual exported symbol name(s) short of actually running the
    preprocessor on them.

    Storing the symbol name string in a special ELF section doesn't work
    for targets that output assembly or preprocessed source.

    So the best way is really to leverage the preprocessor by having it
    output actual symbol names anchored by a special sequence that can be
    easily filtered out. Then the list of symbols is simply fed to fixdep
    to be merged with the other dependencies.

    That implies the preprocessor is executed twice for each source file.
    A previous attempt relied on a warning pragma for each EXPORT_SYMBOL()
    instance that was filtered apart from stderr by the build system with
    a sed script during the actual compilation pass. Unfortunately the
    preprocessor/compiler diagnostic output isn't stable between versions
    and this solution, although more efficient, was deemed too fragile.

    Because of the lowercasing performed by fixdep, there might be name
    collisions triggering spurious rebuilds for similar symbols. But this
    shouldn't be a big issue in practice. (This is the case for CONFIG_*
    symbols and I didn't want to be different here, whatever the original
    reason for doing so.)

    To avoid needless build overhead, the exported symbol name gathering is
    performed only when CONFIG_TRIM_UNUSED_KSYMS is selected.

    Signed-off-by: Nicolas Pitre
    Acked-by: Rusty Russell

    Nicolas Pitre
     
  • ... and merge them in the list of parsed dependencies.

    Signed-off-by: Nicolas Pitre

    Nicolas Pitre
     

18 Feb, 2016

1 commit

  • Coverity has recently added a check that will find when we don't check
    the return code from fstat(2). Copy/paste the checking logic that
    print_deps() has with an appropriate re-wording of the perror() message.

    Signed-off-by: Tom Rini
    Signed-off-by: Michal Marek

    Tom Rini
     

07 Dec, 2015

1 commit


24 Aug, 2015

2 commits


09 Aug, 2014

2 commits

  • currently bin2c builds only if CONFIG_IKCONFIG=y. But bin2c will now be
    used by kexec too. So make it compilation dependent on CONFIG_BUILD_BIN2C
    and this config option can be selected by CONFIG_KEXEC and CONFIG_IKCONFIG.

    Signed-off-by: Vivek Goyal
    Cc: Borislav Petkov
    Cc: Michael Kerrisk
    Cc: Yinghai Lu
    Cc: Eric Biederman
    Cc: H. Peter Anvin
    Cc: Matthew Garrett
    Cc: Greg Kroah-Hartman
    Cc: Dave Young
    Cc: WANG Chao
    Cc: Baoquan He
    Cc: Andy Lutomirski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vivek Goyal
     
  • This patch series does not do kernel signature verification yet. I plan
    to post another patch series for that. Now distributions are already
    signing PE/COFF bzImage with PKCS7 signature I plan to parse and verify
    those signatures.

    Primary goal of this patchset is to prepare groundwork so that kernel
    image can be signed and signatures be verified during kexec load. This
    should help with two things.

    - It should allow kexec/kdump on secureboot enabled machines.

    - In general it can help even without secureboot. By being able to verify
    kernel image signature in kexec, it should help with avoiding module
    signing restrictions. Matthew Garret showed how to boot into a custom
    kernel, modify first kernel's memory and then jump back to old kernel and
    bypass any policy one wants to.

    This patch (of 15):

    Kexec wants to use bin2c and it wants to use it really early in the build
    process. See arch/x86/purgatory/ code in later patches.

    So move bin2c in scripts/basic so that it can be built very early and
    be usable by arch/x86/purgatory/

    Signed-off-by: Vivek Goyal
    Cc: Borislav Petkov
    Cc: Michael Kerrisk
    Cc: Yinghai Lu
    Cc: Eric Biederman
    Cc: H. Peter Anvin
    Cc: Matthew Garrett
    Cc: Greg Kroah-Hartman
    Cc: Dave Young
    Cc: WANG Chao
    Cc: Baoquan He
    Cc: Andy Lutomirski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vivek Goyal
     

10 Jun, 2014

1 commit


06 Apr, 2013

1 commit

  • The current use-case for fixdep is: a source file is run through a single
    processing step, which creates a single dependency file as a side-effect,
    which fixdep transforms into the file used by the kernel build process.

    In order to transparently run the C pre-processor on device-tree files,
    we wish to run both gcc -E and dtc on a source file in a single rule.
    This generates two dependency files, which must be transformed together
    into the file used by the kernel build process. This change modifies
    fixdep so it can process the concatenation of multiple separate input
    dependency files, and produce a correct unified output.

    The code changes have the slight benefit of transforming the loop in
    parse_dep_file() into more of a lexer/tokenizer, with the loop body being
    more of a parser. Previously, some of this logic was mixed together
    before the loop. I also added some comments, which I hope are useful.

    Benchmarking shows that on a cross-compiled ARM tegra_defconfig build,
    there is less than 0.5 seconds speed decrease with this change, on top
    of a build time of ~2m24s. This is probably within the noise.

    Signed-off-by: Stephen Warren
    Acked-by: Rob Herring

    Stephen Warren
     

09 Jan, 2013

1 commit