1. 13 10月, 2019 1 次提交
  2. 08 10月, 2019 4 次提交
    • M
      nsdeps: make generated patches independent of locale · df6f0987
      Masahiro Yamada 提交于
      scripts/nsdeps automatically generates a patch to add MODULE_IMPORT_NS
      tags, and what is nicer, it sorts the lines alphabetically with the
      'sort' command. However, the output from the 'sort' command depends on
      locale.
      
      For example, I got this:
      
      $ { echo usbstorage; echo usb_storage; } | LANG=en_US.UTF-8 sort
      usbstorage
      usb_storage
      $ { echo usbstorage; echo usb_storage; } | LANG=C sort
      usb_storage
      usbstorage
      
      So, this means people might potentially send different patches.
      
      This kind of issue was reported in the past, for example,
      commit f55f2328 ("kbuild: make sorting initramfs contents
      independent of locale").
      
      Adding 'LANG=C' is a conventional way of fixing when a deterministic
      result is desirable.
      
      I added 'LANG=C' very close to the 'sort' command since changing
      locale affects the language of error messages etc. We should respect
      users' choice as much as possible.
      Reviewed-by: NMatthias Maennich <maennich@google.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      df6f0987
    • M
      nsdeps: fix hashbang of scripts/nsdeps · 40997fb8
      Masahiro Yamada 提交于
      This script does not use bash-extension. I am guessing this hashbang
      was copied from scripts/coccicheck, which really uses bash-extension.
      
      /bin/sh is enough for this script.
      Reviewed-by: NMatthias Maennich <maennich@google.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      40997fb8
    • M
      modpost: fix broken sym->namespace for external module builds · 389eb3f5
      Masahiro Yamada 提交于
      Currently, external module builds produce tons of false-positives:
      
        WARNING: module <mod> uses symbol <sym> from namespace <ns>, but does not import it.
      
      Here, the <ns> part shows a random string.
      
      When you build external modules, the symbol info of vmlinux and
      in-kernel modules are read from $(objtree)/Module.symvers, but
      read_dump() is buggy in multiple ways:
      
      [1] When the modpost is run for vmlinux and in-kernel modules,
      sym_extract_namespace() allocates memory for the namespace. On the
      other hand, read_dump() does not, then sym->namespace will point to
      somewhere in the line buffer of get_next_line(). The data in the
      buffer will be replaced soon, and sym->namespace will end up with
      pointing to unrelated data. As a result, check_exports() will show
      random strings in the warning messages.
      
      [2] When there is no namespace, sym_extract_namespace() returns NULL.
      On the other hand, read_dump() sets namespace to an empty string "".
      (but, it will be later replaced with unrelated data due to bug [1].)
      The check_exports() shows a warning unless exp->namespace is NULL,
      so every symbol read from read_dump() emits the warning, which is
      mostly false positive.
      
      To address [1], sym_add_exported() calls strdup() for s->namespace.
      The namespace from sym_extract_namespace() must be freed to avoid
      memory leak.
      
      For [2], I changed the if-conditional in check_exports().
      
      This commit also fixes sym_add_exported() to set s->namespace correctly
      when the symbol is preloaded.
      Reviewed-by: NMatthias Maennich <maennich@google.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      389eb3f5
    • M
      module: swap the order of symbol.namespace · bf70b050
      Masahiro Yamada 提交于
      Currently, EXPORT_SYMBOL_NS(_GPL) constructs the kernel symbol as
      follows:
      
        __ksymtab_SYMBOL.NAMESPACE
      
      The sym_extract_namespace() in modpost allocates memory for the part
      SYMBOL.NAMESPACE when '.' is contained. One problem is that the pointer
      returned by strdup() is lost because the symbol name will be copied to
      malloc'ed memory by alloc_symbol(). No one will keep track of the
      pointer of strdup'ed memory.
      
      sym->namespace still points to the NAMESPACE part. So, you can free it
      with complicated code like this:
      
         free(sym->namespace - strlen(sym->name) - 1);
      
      It complicates memory free.
      
      To fix it elegantly, I swapped the order of the symbol and the
      namespace as follows:
      
        __ksymtab_NAMESPACE.SYMBOL
      
      then, simplified sym_extract_namespace() so that it allocates memory
      only for the NAMESPACE part.
      
      I prefer this order because it is intuitive and also matches to major
      languages. For example, NAMESPACE::NAME in C++, MODULE.NAME in Python.
      Reviewed-by: NMatthias Maennich <maennich@google.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      bf70b050
  3. 07 10月, 2019 1 次提交
  4. 05 10月, 2019 2 次提交
    • M
      scripts/setlocalversion: clear local variable to make it work for sh · 7a82e3fa
      Masahiro Yamada 提交于
      Geert Uytterhoeven reports a strange side-effect of commit 858805b3
      ("kbuild: add $(BASH) to run scripts with bash-extension"), which
      inserts the contents of a localversion file in the build directory twice.
      
      [Steps to Reproduce]
        $ echo bar > localversion
        $ mkdir build
        $ cd build/
        $ echo foo > localversion
        $ make -s -f ../Makefile defconfig include/config/kernel.release
        $ cat include/config/kernel.release
        5.4.0-rc1foofoobar
      
      This comes down to the behavior change of local variables.
      
      The 'man sh' on my Ubuntu machine, where sh is an alias to dash,
      explains as follows:
        When a variable is made local, it inherits the initial value and
        exported and readonly flags from the variable with the same name
        in the surrounding scope, if there is one. Otherwise, the variable
        is initially unset.
      
      [Test Code]
      
        foo ()
        {
                local res
                echo "res: $res"
        }
      
        res=1
        foo
      
      [Result]
      
        $ sh test.sh
        res: 1
        $ bash test.sh
        res:
      
      So, scripts/setlocalversion correctly works only for bash in spite of
      its hashbang being #!/bin/sh. Nobody had noticed it before because
      CONFIG_SHELL was previously set to bash almost all the time.
      
      Now that CONFIG_SHELL is set to sh, we must write portable and correct
      code. I gave the Fixes tag to the commit that uncovered the issue.
      
      Clear the variable 'res' in collect_files() to make it work for sh
      (and it also works on distributions where sh is an alias to bash).
      
      Fixes: 858805b3 ("kbuild: add $(BASH) to run scripts with bash-extension")
      Reported-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      7a82e3fa
    • J
      namespace: fix namespace.pl script to support relative paths · 82fdd12b
      Jacob Keller 提交于
      The namespace.pl script does not work properly if objtree is not set to
      an absolute path. The do_nm function is run from within the find
      function, which changes directories.
      
      Because of this, appending objtree, $File::Find::dir, and $source, will
      return a path which is not valid from the current directory.
      
      This used to work when objtree was set to an absolute path when using
      "make namespacecheck". It appears to have not worked when calling
      ./scripts/namespace.pl directly.
      
      This behavior was changed in 7e1c0477 ("kbuild: Use relative path
      for $(objtree)", 2014-05-14)
      
      Rather than fixing the Makefile to set objtree to an absolute path, just
      fix namespace.pl to work when srctree and objtree are relative. Also fix
      the script to use an absolute path for these by default.
      
      Use the File::Spec module for this purpose. It's been part of perl
      5 since 5.005.
      
      The curdir() function is used to get the current directory when the
      objtree and srctree aren't set in the environment.
      
      rel2abs() is used to convert possibly relative objtree and srctree
      environment variables to absolute paths.
      
      Finally, the catfile() function is used instead of string appending
      paths together, since this is more robust when joining paths together.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      Tested-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      82fdd12b
  5. 01 10月, 2019 2 次提交
    • M
      modpost: fix static EXPORT_SYMBOL warnings for UML build · 47346e96
      Masahiro Yamada 提交于
      Johannes Berg reports lots of modpost warnings on ARCH=um builds:
      
      WARNING: "rename" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "lseek" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "ftruncate64" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "getuid" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "lseek64" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "unlink" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "pwrite64" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "close" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "opendir" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "pread64" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "syscall" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "readdir" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "readdir64" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "futimes" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "__lxstat" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "write" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "closedir" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "__xstat" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "fsync" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "__lxstat64" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "__fxstat64" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "telldir" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "printf" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "readlink" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "__sprintf_chk" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "link" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "rmdir" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "fdatasync" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "truncate" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "statfs" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "__errno_location" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "__xmknod" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "open64" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "truncate64" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "open" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "read" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "chown" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "chmod" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "utime" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "fchmod" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "seekdir" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "ioctl" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "dup2" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "statfs64" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "utimes" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "mkdir" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "fchown" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "__guard" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "symlink" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "access" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "__stack_smash_handler" [vmlinux] is a static EXPORT_SYMBOL
      
      When you run "make", the modpost is run twice; before linking vmlinux,
      and before building modules. All the warnings above are from the second
      modpost.
      
      The offending symbols are defined not in vmlinux, but in the C library.
      The first modpost is run against the relocatable vmlinux.o, and those
      warnings are nicely suppressed because the SH_UNDEF entries from the
      symbol table clear the ->is_static flag.
      
      The second modpost is run against the executable vmlinux (+ modules),
      where those symbols have been resolved, but the definitions do not
      exist.
      
      This commit fixes it in a straightforward way; suppress the static
      EXPORT_SYMBOL warnings from "vmlinux".
      
      Without this commit, we see valid warnings twice anyway. For example,
      ARCH=arm64 defconfig shows the following warning twice:
      
      WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
      
      So, it is reasonable to suppress the second one.
      
      Fixes: 15bfc234 ("modpost: check for static EXPORT_SYMBOL* functions")
      Reported-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: NJohannes Berg <johannes@sipsolutions.net>
      Tested-by: NDenis Efremov <efremov@linux.com>
      47346e96
    • M
      kbuild: remove ar-option and KBUILD_ARFLAGS · 13dc8c02
      Masahiro Yamada 提交于
      Commit 40df759e ("kbuild: Fix build with binutils <= 2.19")
      introduced ar-option and KBUILD_ARFLAGS to deal with old binutils.
      
      According to Documentation/process/changes.rst, the current minimal
      supported version of binutils is 2.21 so you can assume the 'D' option
      is always supported. Not only GNU ar but also llvm-ar supports it.
      
      With the 'D' option hard-coded, there is no more user of ar-option
      or KBUILD_ARFLAGS.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Tested-by: NNick Desaulniers <ndesaulniers@google.com>
      13dc8c02
  6. 26 9月, 2019 10 次提交
  7. 14 9月, 2019 4 次提交
    • M
      genksyms: convert to SPDX License Identifier for lex.l and parse.y · 77564a48
      Masahiro Yamada 提交于
      I used the C comment style (/* ... */) for the flex and bison files
      as in Kconfig (scripts/kconfig/{lexer.l,parser.y})
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      77564a48
    • M
      modpost: use __section in the output to *.mod.c · a3d0cb04
      Masahiro Yamada 提交于
      Use the __section() shorthand. This avoids escaping double-quotes,
      and improves the readability.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      a3d0cb04
    • M
      modpost: use MODULE_INFO() for __module_depends · 6df7e1ec
      Masahiro Yamada 提交于
      This makes *.mod.c much more readable. I confirmed depmod still
      produced the same modules.dep file.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      6df7e1ec
    • M
      export.h, genksyms: do not make genksyms calculate CRC of trimmed symbols · 69a94abb
      Masahiro Yamada 提交于
      Arnd Bergmann reported false-positive modpost warnings detected by his
      randconfig testing of linux-next.
      
      Actually, this happens under the combination of CONFIG_MODVERSIONS
      and CONFIG_TRIM_UNUSED_KSYMS since commit 15bfc234 ("modpost:
      check for static EXPORT_SYMBOL* functions").
      
      For example, arch/arm/config/multi_v7_defconfig + CONFIG_MODVERSIONS
      + CONFIG_TRIM_UNUSED_KSYMS produces the following false-positives:
      
      WARNING: "__lshrdi3" [vmlinux] is a static (unknown)
      WARNING: "__ashrdi3" [vmlinux] is a static (unknown)
      WARNING: "__aeabi_lasr" [vmlinux] is a static (unknown)
      WARNING: "__aeabi_llsr" [vmlinux] is a static (unknown)
      WARNING: "ftrace_set_clr_event" [vmlinux] is a static (unknown)
      WARNING: "__muldi3" [vmlinux] is a static (unknown)
      WARNING: "__aeabi_ulcmp" [vmlinux] is a static (unknown)
      WARNING: "__ucmpdi2" [vmlinux] is a static (unknown)
      WARNING: "__aeabi_lmul" [vmlinux] is a static (unknown)
      WARNING: "__bswapsi2" [vmlinux] is a static (unknown)
      WARNING: "__bswapdi2" [vmlinux] is a static (unknown)
      WARNING: "__ashldi3" [vmlinux] is a static (unknown)
      WARNING: "__aeabi_llsl" [vmlinux] is a static (unknown)
      
      The root cause of the problem is not in the modpost, but in the
      implementation of CONFIG_TRIM_UNUSED_KSYMS.
      
      If there is at least one untrimmed symbol in the file, genksyms is
      invoked to calculate CRC of *all* the exported symbols in that file
      even if some of them have been trimmed due to no caller existing.
      
      As a result, .tmp_*.ver files contain CRC of trimmed symbols, thus
      unneeded, orphan __crc* symbols are added to objects. It had been
      harmless until recently.
      
      With commit 15bfc234 ("modpost: check for static EXPORT_SYMBOL*
      functions"), it is now harmful because the bogus __crc* symbols make
      modpost call sym_update_crc() to add the symbols to the hash table,
      but there is no one that clears the ->is_static member.
      
      I gave Fixes to the first commit that uncovered the issue, but the
      potential problem has long existed since commit f2355416
      ("export.h: allow for per-symbol configurable EXPORT_SYMBOL()").
      
      Fixes: 15bfc234 ("modpost: check for static EXPORT_SYMBOL* functions")
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: NArnd Bergmann <arnd@arndb.de>
      69a94abb
  8. 10 9月, 2019 3 次提交
  9. 09 9月, 2019 1 次提交
    • M
      kbuild: allow Clang to find unused static inline functions for W=1 build · 6863f564
      Masahiro Yamada 提交于
      GCC and Clang have different policy for -Wunused-function; GCC does not
      warn unused static inline functions at all whereas Clang does if they
      are defined in source files instead of included headers although it has
      been suppressed since commit abb2ea7d ("compiler, clang: suppress
      warning for unused static inline functions").
      
      We often miss to delete unused functions where 'static inline' is used
      in *.c files since there is no tool to detect them. Unused code remains
      until somebody notices. For example, commit 075ddd75 ("regulator:
      core: remove unused rdev_get_supply()").
      
      Let's remove __maybe_unused from the inline macro to allow Clang to
      start finding unused static inline functions. For now, we do this only
      for W=1 build since it is not a good idea to sprinkle warnings for the
      normal build (e.g. 35 warnings for arch/x86/configs/x86_64_defconfig).
      
      My initial attempt was to add -Wno-unused-function for no W= build
      (https://lore.kernel.org/patchwork/patch/1120594/)
      
      Nathan Chancellor pointed out that would weaken Clang's checks since
      we would no longer get -Wunused-function without W=1. It is true GCC
      would catch unused static non-inline functions, but it would weaken
      Clang as a standalone compiler, at least.
      
      Hence, here is a counter implementation. The current problem is, W=...
      only controls compiler flags, which are globally effective. There is
      no way to address only 'static inline' functions.
      
      This commit defines KBUILD_EXTRA_WARN[123] corresponding to W=[123].
      When KBUILD_EXTRA_WARN1 is defined, __maybe_unused is omitted from
      the 'inline' macro.
      
      The new macro __inline_maybe_unused makes the code a bit uglier, so I
      hope we can remove it entirely after fixing most of the warnings.
      
      If you contribute to code clean-up, please run "make CC=clang W=1"
      and check -Wunused-function warnings. You will find lots of unused
      functions.
      
      Some of them are false-positives because the call-sites are disabled
      by #ifdef. I do not like to abuse the inline keyword for suppressing
      unused-function warnings because it is intended to be a hint for the
      compiler optimization. I prefer #ifdef around the definition, or
      __maybe_unused if #ifdef would make the code too ugly.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Tested-by: NNathan Chancellor <natechancellor@gmail.com>
      6863f564
  10. 07 9月, 2019 1 次提交
  11. 06 9月, 2019 3 次提交
    • M
      kbuild: rename KBUILD_ENABLE_EXTRA_GCC_CHECKS to KBUILD_EXTRA_WARN · e27128db
      Masahiro Yamada 提交于
      KBUILD_ENABLE_EXTRA_GCC_CHECKS started as a switch to add extra warning
      options for GCC, but now it is a historical misnomer since we use it
      also for Clang, DTC, and even kernel-doc.
      
      Rename it to more sensible, shorter KBUILD_EXTRA_WARN.
      
      For the backward compatibility, KBUILD_ENABLE_EXTRA_GCC_CHECKS is still
      supported (but not advertised in the documentation).
      
      I also fixed up 'make help', and updated the documentation.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: NSedat Dilek <sedat.dilek@gmail.com>
      e27128db
    • M
      kbuild: refactor scripts/Makefile.extrawarn · 64a91907
      Masahiro Yamada 提交于
      Instead of the warning-[123] magic, let's accumulate compiler options
      to KBUILD_CFLAGS directly as the top Makefile does. I think this makes
      it easier to understand what is going on in this file.
      
      This commit slightly changes the behavior, I think all of which are OK.
      
      [1] Currently, cc-option calls are needlessly evaluated. For example,
            warning-3 += $(call cc-option, -Wpacked-bitfield-compat)
          needs evaluating only when W=3, but it is actually evaluated for
          W=1, W=2 as well. With this commit, only relevant cc-option calls
          will be evaluated. This is a slight optimization.
      
      [2] Currently, unsupported level like W=4 is checked by:
            $(error W=$(KBUILD_ENABLE_EXTRA_GCC_CHECKS) is unknown)
          This will no longer be checked, but I do not think it is a big
          deal.
      
      [3] Currently, 4 Clang warnings (Winitializer-overrides, Wformat,
          Wsign-compare, Wformat-zero-length) are shown by any of W=1, W=2,
          and W=3. With this commit, they will be warned only by W=1. I
          think this is a more correct behavior since each warning belongs
          to only one group.
      
      For understanding this commit correctly:
      
      We have 3 warning groups, W=1, W=2, and W=3. You may think W=3 has a
      higher level than W=1, but they are actually independent. If you like,
      you can combine them like W=13. To enable all the warnings, you can
      pass W=123. It is shown by 'make help', but not noticed much. Since we
      support W= combination, there should not exist intersection among the
      three groups. If we enable Winitializer-overrides for W=1, we do not
      need to for W=2 or W=3. This is the reason why I think the change [3]
      makes sense.
      
      The documentation says -Winitializer-overrides is enabled by default.
      (https://clang.llvm.org/docs/DiagnosticsReference.html#winitializer-overrides)
      We negate it by passing -Wno-initializer-overrides for the normal
      build, but we do not do that for W=1. This means, W=1 effectively
      enables -Winitializer-overrides by the clang's default. The same for
      the other three.
      
      Add comments in case people are confused with the code.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
      Acked-by: NNick Desaulniers <ndesaulniers@google.com>
      Acked-by: NMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      64a91907
    • Y
      coccinelle: platform_get_irq: Fix parse error · ca7ce5a2
      YueHaibing 提交于
      When do coccicheck, I get this error:
      
      spatch -D report --no-show-diff --very-quiet --cocci-file
      ./scripts/coccinelle/api/platform_get_irq.cocci --include-headers
      --dir . -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include
       -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi
       -I ./include/uapi -I ./include/generated/uapi
       --include ./include/linux/kconfig.h --jobs 192 --chunksize 1
      minus: parse error:
        File "./scripts/coccinelle/api/platform_get_irq.cocci", line 24, column 9, charpos = 355
        around = '\(',
        whole content = if ( ret \( < \| <= \) 0 )
      
      In commit e56476897448 ("fpga: Remove dev_err() usage
      after platform_get_irq()") log, I found the semantic patch,
      it fix this issue.
      
      Fixes: 98051ba2 ("coccinelle: Add script to check for platform_get_irq() excessive prints")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: NStephen Boyd <swboyd@chromium.org>
      Acked-by: NJulia Lawall <julia.lawall@lip6.fr>
      Link: https://lore.kernel.org/r/20190906033006.17616-1-yuehaibing@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca7ce5a2
  12. 04 9月, 2019 5 次提交
    • G
      merge_config.sh: ignore unwanted grep errors · 60bef52c
      Guillaume Tucker 提交于
      The merge_config.sh script verifies that all the config options have
      their expected value in the resulting file and prints any issues as
      warnings.  These checks aren't intended to be treated as errors given
      the current implementation.  However, since "set -e" was added, if the
      grep command to look for a config option does not find it the script
      will then abort prematurely.
      
      Handle the case where the grep exit status is non-zero by setting
      ACTUAL_VAL to an empty string to restore previous functionality.
      
      Fixes: cdfca821 ("merge_config.sh: Check error codes from make")
      Signed-off-by: NGuillaume Tucker <guillaume.tucker@collabora.com>
      Acked-by: NJon Hunter <jonathanh@nvidia.com>
      Tested-by: NJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      60bef52c
    • M
      kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj) · 54b8ae66
      Masahiro Yamada 提交于
      Kbuild provides per-file compiler flag addition/removal:
      
        CFLAGS_<basetarget>.o
        CFLAGS_REMOVE_<basetarget>.o
        AFLAGS_<basetarget>.o
        AFLAGS_REMOVE_<basetarget>.o
        CPPFLAGS_<basetarget>.lds
        HOSTCFLAGS_<basetarget>.o
        HOSTCXXFLAGS_<basetarget>.o
      
      The <basetarget> is the filename of the target with its directory and
      suffix stripped.
      
      This syntax comes into a trouble when two files with the same basename
      appear in one Makefile, for example:
      
        obj-y += foo.o
        obj-y += dir/foo.o
        CFLAGS_foo.o := <some-flags>
      
      Here, the <some-flags> applies to both foo.o and dir/foo.o
      
      The real world problem is:
      
        scripts/kconfig/util.c
        scripts/kconfig/lxdialog/util.c
      
      Both files are compiled into scripts/kconfig/mconf, but only the
      latter should be given with the ncurses flags.
      
      It is more sensible to use the relative path to the Makefile, like this:
      
        obj-y += foo.o
        CFLAGS_foo.o := <some-flags>
        obj-y += dir/foo.o
        CFLAGS_dir/foo.o := <other-flags>
      
      At first, I attempted to replace $(basetarget) with $*. The $* variable
      is replaced with the stem ('%') part in a pattern rule. This works with
      most of cases, but does not for explicit rules.
      
      For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
      explicit rules, so $* will be empty, resulting in ignoring the per-file
      AFLAGS.
      
      I introduced a new variable, target-stem, which can be used also from
      explicit rules.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NMarc Zyngier <maz@kernel.org>
      54b8ae66
    • D
      modpost: add NOFAIL to strndup · 6f02bdfc
      Denis Efremov 提交于
      Add NOFAIL check for the strndup call, because the function
      allocates memory and can return NULL. All calls to strdup in
      modpost are checked with NOFAIL.
      Signed-off-by: NDenis Efremov <efremov@linux.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      6f02bdfc
    • H
      modpost: add guid_t type definition · 389c9af7
      Heikki Krogerus 提交于
      Since guid_t is the recommended data type for UUIDs in
      kernel (and I guess uuid_le is meant to be ultimately
      replaced with it), it should be made available here as
      well.
      Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      389c9af7
    • M
      kbuild: add $(BASH) to run scripts with bash-extension · 858805b3
      Masahiro Yamada 提交于
      CONFIG_SHELL falls back to sh when bash is not installed on the system,
      but nobody is testing such a case since bash is usually installed.
      So, shell scripts invoked by CONFIG_SHELL are only tested with bash.
      
      It makes it difficult to test whether the hashbang #!/bin/sh is real.
      For example, #!/bin/sh in arch/powerpc/kernel/prom_init_check.sh is
      false. (I fixed it up)
      
      Besides, some shell scripts invoked by CONFIG_SHELL use bash-extension
      and #!/bin/bash is specified as the hashbang, while CONFIG_SHELL may
      not always be set to bash.
      
      Probably, the right thing to do is to introduce BASH, which is bash by
      default, and always set CONFIG_SHELL to sh. Replace $(CONFIG_SHELL)
      with $(BASH) for bash scripts.
      
      If somebody tries to add bash-extension to a #!/bin/sh script, it will
      be caught in testing because /bin/sh is a symlink to dash on some major
      distributions.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      858805b3
  13. 01 9月, 2019 3 次提交
反馈
建议
客服 返回
顶部