Skip to content
  1. Apr 30, 2019
  2. Apr 25, 2019
  3. Apr 23, 2019
  4. Apr 10, 2019
  5. Apr 03, 2019
  6. Mar 18, 2019
  7. Mar 17, 2019
    • kbuild test robot's avatar
      perf/x86/intel: Make dev_attr_allow_tsx_force_abort static · c634dc6b
      kbuild test robot authored
      Fixes: 400816f6
      
       ("perf/x86/intel: Implement support for TSX Force Abort")
      Signed-off-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: kbuild-all@01.org
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190313184243.GA10820@lkp-sb-ep06
      c634dc6b
    • Masahiro Yamada's avatar
      kconfig: remove stale lxdialog/.gitignore · c71bb9f8
      Masahiro Yamada authored
      
      
      When this .gitignore was added, lxdialog was an independent hostprogs-y.
      
      Now that all objects in lxdialog/ are directly linked to mconf, the
      lxdialog is no longer generated.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      c71bb9f8
    • Masahiro Yamada's avatar
      kbuild: force all architectures except um to include mandatory-y · 037fc336
      Masahiro Yamada authored
      
      
      Currently, every arch/*/include/uapi/asm/Kbuild explicitly includes
      the common Kbuild.asm file. Factor out the duplicated include directives
      to scripts/Makefile.asm-generic so that no architecture would opt out
      of the mandatory-y mechanism.
      
      um is not forced to include mandatory-y since it is a very exceptional
      case which does not support UAPI.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      037fc336
    • Masahiro Yamada's avatar
      kbuild: warn redundant generic-y · 7cbbbb8b
      Masahiro Yamada authored
      
      
      The generic-y is redundant under the following condition:
      
       - arch has its own implementation
      
       - the same header is added to generated-y
      
       - the same header is added to mandatory-y
      
      If a redundant generic-y is found, the warning like follows is displayed:
      
        scripts/Makefile.asm-generic:20: redundant generic-y found in arch/arm/include/asm/Kbuild: timex.h
      
      I fixed up arch Kbuild files found by this.
      
      Suggested-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      7cbbbb8b
    • Douglas Anderson's avatar
      Revert "modsign: Abort modules_install when signing fails" · f84dde10
      Douglas Anderson authored
      This reverts commit caf6fe91.
      
      The commit was fine but is no longer needed as of commit 3a2429e1
      ("kbuild: change if_changed_rule for multi-line recipe").  Let's go
      back to using ";" to be consistent.
      
      For some discussion, see:
      
      https://lkml.kernel.org/r/CAK7LNASde0Q9S5GKeQiWhArfER4S4wL1=R_FW8q0++_X3T5=hQ@mail.gmail.com
      
      
      
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      f84dde10
    • Douglas Anderson's avatar
      kbuild: Make NOSTDINC_FLAGS a simply expanded variable · 0c22be07
      Douglas Anderson authored
      During a simple no-op (nothing changed) build I saw 39 invocations of
      the C compiler with the argument "-print-file-name=include".  We don't
      need to call the C compiler 39 times for this--one time will suffice.
      
      Let's change NOSTDINC_FLAGS to a simply expanded variable to avoid
      this since there doesn't appear to be any reason it should be
      recursively expanded.
      
      On my build this shaved ~400 ms off my "no-op" build.
      
      Note that the recursive expansion seems to date back to the (really
      old) commit e8f5bdb0
      
       ("[PATCH] Makefile include path ordering").
      It's a little unclear to me if the point of that patch was to switch
      the variable to be recursively expanded (which it did) or to avoid
      directly assigning to NOSTDINC_FLAGS (AKA to switch to +=) because
      someone else (out of tree?) was setting it.  I presume later since if
      the only goal was to switch to recursive expansion the patch would
      have just removed the ":".
      
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      0c22be07
    • Arseny Maslennikov's avatar
      kbuild: deb-pkg: avoid implicit effects · f6d9db63
      Arseny Maslennikov authored
      
      
      * The man page for dpkg-source(1) notes:
      
      >      -b, --build directory [format-specific-parameters]
      >             Build  a  source  package  (--build since dpkg 1.17.14).
      >             <...>
      >
      >             dpkg-source will build the source package with the first
      >             format found in this ordered list: the format  indicated
      >             with  the  --format  command  line  option,  the  format
      >             indicated in debian/source/format, “1.0”.  The  fallback
      >             to “1.0” is deprecated and will be removed at some point
      >             in the future, you should always  document  the  desired
      >             source   format  in  debian/source/format.  See  section
      >             SOURCE PACKAGE FORMATS for an extensive  description  of
      >             the various source package formats.
      
        Thus it would be more foolproof to explicitly use 1.0 (as we always
        did) than to rely on dpkg-source's defaults.
      
      * In a similar vein, debian/rules is not made executable by mkdebian,
        and dpkg-source warns about that but still silently fixes the file.
        Let's be explicit once again.
      
      Signed-off-by: default avatarArseny Maslennikov <ar@cs.msu.ru>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      f6d9db63
    • Wen Yang's avatar
      coccinelle: semantic code search for missing put_device() · da9cfb87
      Wen Yang authored
      The of_find_device_by_node() takes a reference to the underlying device
      structure, we should release that reference.
      The implementation of this semantic code search is:
      In a function, for a local variable returned by calling
      of_find_device_by_node(),
      a, if it is released by a function such as
         put_device()/of_dev_put()/platform_device_put() after the last use,
         it is considered that there is no reference leak;
      b, if it is passed back to the caller via
         dev_get_drvdata()/platform_get_drvdata()/get_device(), etc., the
         reference will be released in other functions, and the current function
         also considers that there is no reference leak;
      c, for the rest of the situation, the current function should release the
         reference by calling put_device, this code search will report the
         corresponding error message.
      
      By using this semantic code search, we have found some object reference leaks,
      such as:
      commit 11907e9d ("ASoC: fsl-asoc-card: fix object reference leaks in
      fsl_asoc_card_probe")
      commit a12085d1 ("mtd: rawnand: atmel: fix possible object reference leak")
      commit 11493f26
      
       ("mtd: rawnand: jz4780: fix possible object reference leak")
      
      There are still dozens of reference leaks in the current kernel code.
      
      Further, for the case of b, the object returned to other functions may also
      have a reference leak, we will continue to develop other cocci scripts to
      further check the reference leak.
      
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Reviewed-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Reviewed-by: default avatarMarkus Elfring <Markus.Elfring@web.de>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      da9cfb87
    • Linus Torvalds's avatar
      Merge tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux · a9dce667
      Linus Torvalds authored
      Pull pidfd system call from Christian Brauner:
       "This introduces the ability to use file descriptors from /proc/<pid>/
        as stable handles on struct pid. Even if a pid is recycled the handle
        will not change. For a start these fds can be used to send signals to
        the processes they refer to.
      
        With the ability to use /proc/<pid> fds as stable handles on struct
        pid we can fix a long-standing issue where after a process has exited
        its pid can be reused by another process. If a caller sends a signal
        to a reused pid it will end up signaling the wrong process.
      
        With this patchset we enable a variety of use cases. One obvious
        example is that we can now safely delegate an important part of
        process management - sending signals - to processes other than the
        parent of a given process by sending file descriptors around via scm
        rights and not fearing that the given process will have been recycled
        in the meantime. It also allows for easy testing whether a given
        process is still alive or not by sending signal 0 to a pidfd which is
        quite handy.
      
        There has been some interest in this feature e.g. from systems
        management (systemd, glibc) and container managers. I have requested
        and gotten comments from glibc to make sure that this syscall is
        suitable for their needs as well. In the future I expect it to take on
        most other pid-based signal syscalls. But such features are left for
        the future once they are needed.
      
        This has been sitting in linux-next for quite a while and has not
        caused any issues. It comes with selftests which verify basic
        functionality and also test that a recycled pid cannot be signaled via
        a pidfd.
      
        Jon has written about a prior version of this patchset. It should
        cover the basic functionality since not a lot has changed since then:
      
            https://lwn.net/Articles/773459/
      
        The commit message for the syscall itself is extensively documenting
        the syscall, including it's functionality and extensibility"
      
      * tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
        selftests: add tests for pidfd_send_signal()
        signal: add pidfd_send_signal() syscall
      a9dce667