1. 12 Feb, 2019 3 commits
  2. 26 Jan, 2019 3 commits
    • Masahiro Yamada's avatar
      kconfig: fix memory leak when EOF is encountered in quotation · 507a004e
      Masahiro Yamada authored
      [ Upstream commit fbac5977 ]
      
      An unterminated string literal followed by new line is passed to the
      parser (with "multi-line strings not supported" warning shown), then
      handled properly there.
      
      On the other hand, an unterminated string literal at end of file is
      never passed to the parser, then results in memory leak.
      
      [Test Code]
      
        ----------(Kconfig begin)----------
        source "Kconfig.inc"
      
        config A
                bool "a"
        -----------(Kconfig end)-----------
      
        --------(Kconfig.inc begin)--------
        config B
                bool "b\No new line at end of file
        ---------(Kconfig.inc end)---------
      
      [Summary from Valgrind]
      
        Before the fix:
      
          LEAK SUMMARY:
             definitely lost: 16 bytes in 1 blocks
             ...
      
        After the fix:
      
          LEAK SUMMARY:
             definitely lost: 0 bytes in 0 blocks
             ...
      
      Eliminate the memory leak path by handling this case. Of course, such
      a Kconfig file is wrong already, so I will add an error message later.
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      507a004e
    • Masahiro Yamada's avatar
      kconfig: fix file name and line number of warn_ignored_character() · c0a4b0c7
      Masahiro Yamada authored
      [ Upstream commit 77c1c0fa ]
      
      Currently, warn_ignore_character() displays invalid file name and
      line number.
      
      The lexer should use current_file->name and yylineno, while the parser
      should use zconf_curname() and zconf_lineno().
      
      This difference comes from that the lexer is always going ahead
      of the parser. The parser needs to look ahead one token to make a
      shift/reduce decision, so the lexer is requested to scan more text
      from the input file.
      
      This commit fixes the warning message from warn_ignored_character().
      
      [Test Code]
      
        ----(Kconfig begin)----
        /
        -----(Kconfig end)-----
      
      [Output]
      
        Before the fix:
      
        <none>:0:warning: ignoring unsupported character '/'
      
        After the fix:
      
        Kconfig:1:warning: ignoring unsupported character '/'
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      c0a4b0c7
    • Masahiro Yamada's avatar
      kbuild: let fixdep directly write to .*.cmd files · a41c9b57
      Masahiro Yamada authored
      [ Upstream commit 392885ee ]
      
      Currently, fixdep writes dependencies to .*.tmp, which is renamed to
      .*.cmd after everything succeeds. This is a very safe way to avoid
      corrupted .*.cmd files. The if_changed_dep has carried this safety
      mechanism since it was added in 2002.
      
      If fixdep fails for some reasons or a user terminates the build while
      fixdep is running, the incomplete output from the fixdep could be
      troublesome.
      
      This is my insight about some bad scenarios:
      
      [1] If the compiler succeeds to generate *.o file, but fixdep fails
          to write necessary dependencies to .*.cmd file, Make will miss
          to rebuild the object when headers or CONFIG options are changed.
          In this case, fixdep should not generate .*.cmd file at all so
          that 'arg-check' will surely trigger the rebuild of the object.
      
      [2] A partially constructed .*.cmd file may not be a syntactically
          correct makefile. The next time Make runs, it would include it,
          then fail to parse it. Once this happens, 'make clean' is be the
          only way to fix it.
      
      In fact, [1] is no longer a problem since commit 9c2af1c7 ("kbuild:
      add .DELETE_ON_ERROR special target"). Make deletes a target file on
      any failure in its recipe. Because fixdep is a part of the recipe of
      *.o target, if it fails, the *.o is deleted anyway. However, I am a
      bit worried about the slight possibility of [2].
      
      So, here is a solution. Let fixdep directly write to a .*.cmd file,
      but allow makefiles to include it only when its corresponding target
      exists.
      
      This effectively reverts commit 2982c953 ("kbuild: remove redundant
      $(wildcard ...) for cmd_files calculation"), and commit 00d78ab2
      ("kbuild: remove dead code in cmd_files calculation in top Makefile")
      because now we must check the presence of targets.
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      a41c9b57
  3. 16 Jan, 2019 1 commit
  4. 19 Dec, 2018 1 commit
  5. 14 Dec, 2018 2 commits
  6. 06 Dec, 2018 1 commit
  7. 30 Nov, 2018 1 commit
    • Linus Torvalds's avatar
      unifdef: use memcpy instead of strncpy · 38c7b224
      Linus Torvalds authored
      New versions of gcc reasonably warn about the odd pattern of
      
      	strncpy(p, q, strlen(q));
      
      which really doesn't make sense: the strncpy() ends up being just a slow
      and odd way to write memcpy() in this case.
      
      There was a comment about _why_ the code used strncpy - to avoid the
      terminating NUL byte, but memcpy does the same and avoids the warning.
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      38c7b224
  8. 28 Nov, 2018 1 commit
  9. 18 Nov, 2018 2 commits
  10. 11 Nov, 2018 4 commits
  11. 05 Nov, 2018 2 commits
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: fix bindeb-pkg breakage when O= is used · 02826a6b
      Masahiro Yamada authored
      Ard Biesheuvel reports bindeb-pkg with O= option is broken in the
      following way:
      
        ...
          LD [M]  sound/soc/rockchip/snd-soc-rk3399-gru-sound.ko
          LD [M]  sound/soc/rockchip/snd-soc-rockchip-pcm.ko
          LD [M]  sound/soc/rockchip/snd-soc-rockchip-rt5645.ko
          LD [M]  sound/soc/rockchip/snd-soc-rockchip-spdif.ko
          LD [M]  sound/soc/sh/rcar/snd-soc-rcar.ko
         fakeroot -u debian/rules binary
        make KERNELRELEASE=4.19.0-12677-g19beffaf7a99-dirty ARCH=arm64 KBUILD_SRC= intdeb-pkg
        /bin/bash /home/ard/linux/scripts/package/builddeb
        Makefile:600: include/config/auto.conf: No such file or directory
        ***
        *** Configuration file ".config" not found!
        ***
        *** Please run some configurator (e.g. "make oldconfig" or
        *** "make menuconfig" or "make xconfig").
        ***
        make[12]: *** [syncconfig] Error 1
        make[11]: *** [syncconfig] Error 2
        make[10]: *** [include/config/auto.conf] Error 2
        make[9]: *** [__sub-make] Error 2
        ...
      
      Prior to commit 80463f1b ("kbuild: add --include-dir flag only
      for out-of-tree build"), both srctree and objtree were added to
      --include-dir redundantly, and the wrong code '$MAKE image_name'
      was working by relying on that. Now, the potential issue that had
      previously been hidden just showed up.
      
      '$MAKE image_name' recurses to the generated $(objtree)/Makefile and
      ends up with running in srctree, which is incorrect. It should be
      invoked with '-f $srctree/Makefile' (or KBUILD_SRC=) to be executed
      in objtree.
      
      Fixes: 80463f1b ("kbuild: add --include-dir flag only for out-of-tree build")
      Reported-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      02826a6b
    • Masahiro Yamada's avatar
      kbuild: rpm-pkg: fix binrpm-pkg breakage when O= is used · 21b42eb4
      Masahiro Yamada authored
      Zhenzhong Duan reported that running 'make O=/build/kernel binrpm-pkg'
      failed with the following errors:
      
        Running 'make O=/build/kernel binrpm-pkg' failed with below two errors.
      
        Makefile:600: include/config/auto.conf: No such file or directory
      
        + cp make -C /mnt/root/kernel O=/build/kernel image_name make -f
        /mnt/root/kernel/Makefile ...
        cp: invalid option -- 'C'
        Try 'cp --help' for more information.
      
      Prior to commit 80463f1b ("kbuild: add --include-dir flag only
      for out-of-tree build"), both srctree and objtree were added to
      --include-dir redundantly, and the wrong code 'make image_name'
      was working by relying on that. Now, the potential issue that had
      previously been hidden just showed up.
      
      'make image_name' recurses to the generated $(objtree)/Makefile and
      ends up with running in srctree, which is incorrect. It should be
      invoked with '-f $srctree/Makefile' (or KBUILD_SRC=) to be executed
      in objtree.
      
      Fixes: 80463f1b ("kbuild: add --include-dir flag only for out-of-tree build")
      Reported-by: 's avatarZhenzhong Duan <zhenzhong.duan@oracle.com>
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      21b42eb4
  12. 02 Nov, 2018 2 commits
  13. 01 Nov, 2018 4 commits
  14. 31 Oct, 2018 1 commit
  15. 28 Oct, 2018 2 commits
  16. 26 Oct, 2018 1 commit
  17. 19 Oct, 2018 3 commits
  18. 18 Oct, 2018 1 commit
    • Randy Dunlap's avatar
      kernel-doc: fix declaration type determination · cf419d54
      Randy Dunlap authored
      Make declaration type determination more robust.
      
      When scripts/kernel-doc is deciding if some kernel-doc notation
      contains an enum, a struct, a union, a typedef, or a function,
      it does a pattern match on the beginning of the string, looking
      for a match with one of "struct", "union", "enum", or "typedef",
      and otherwise defaults to a function declaration type.
      However, if a function or a function-like macro has a name that
      begins with "struct" (e.g., struct_size()), then kernel-doc
      incorrectly decides that this is a struct declaration.
      
      Fix this by looking for the declaration type keywords having an
      ending word boundary (\b), so that "struct_size" will not match
      a struct declaration.
      
      I compared lots of html before/after output from core-api, driver-api,
      and networking.  There were no differences in any of the files that
      I checked.
      Signed-off-by: 's avatarRandy Dunlap <rdunlap@infradead.org>
      Acked-by: 's avatarJani Nikula <jani.nikula@intel.com>
      Tested-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarJonathan Corbet <corbet@lwn.net>
      cf419d54
  19. 17 Oct, 2018 1 commit
    • Helge Deller's avatar
      extract-vmlinux: Check for uncompressed image as fallback · db139d71
      Helge Deller authored
      As on x86-64 and other architectures, the boot kernel on parisc (vmlinuz
      and bzImage) contains a full compressed copy of the final kernel
      executable (vmlinux.bin.gz), which one should be able to extract with
      the extract-vmlinux script.
      
      But on parisc extracting the kernel with extract-vmlinux fails.
      Currently the script first checks if the given file is an ELF file
      (which is true on parisc) and if so returns it.  Thus on parisc we
      unexpectedly get back the vmlinuz boot file instead of the uncompressed
      vmlinux image.
      
      This patch fixes this issue by reverting the logic. It now first tries
      to find a compression signature in the given file and if that fails it
      checks the file itself as fallback.
      Signed-off-by: 's avatarHelge Deller <deller@gmx.de>
      db139d71
  20. 11 Oct, 2018 1 commit
  21. 04 Oct, 2018 3 commits