1. 10 Jul, 2019 1 commit
  2. 25 Jun, 2019 1 commit
  3. 11 Jun, 2019 1 commit
    • Kirill Smelkov's avatar
      fs: stream_open - opener for stream-like files so that read and write can run... · b673f99c
      Kirill Smelkov authored
      fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock
      
      commit 10dce8af34226d90fa56746a934f8da5dcdba3df upstream.
      
      Commit 9c225f26 ("vfs: atomic f_pos accesses as per POSIX") added
      locking for file.f_pos access and in particular made concurrent read and
      write not possible - now both those functions take f_pos lock for the
      whole run, and so if e.g. a read is blocked waiting for data, write will
      deadlock waiting for that read to complete.
      
      This caused regression for stream-like files where previously read and
      write could run simultaneously, but after that patch could not do so
      anymore. See e.g. commit 581d21a2 ("xenbus: fix deadlock on writes
      to /proc/xen/xenbus") which fixes such regression for particular case of
      /proc/xen/xenbus.
      
      The patch that added f_pos lock in 2014 did so to guarantee POSIX thread
      safety for read/write/lseek and added the locking to file descriptors of
      all regular files. In 2014 that thread-safety problem was not new as it
      was already discussed earlier in 2006.
      
      However even though 2006'th version of Linus's patch was adding f_pos
      locking "only for files that are marked seekable with FMODE_LSEEK (thus
      avoiding the stream-like objects like pipes and sockets)", the 2014
      version - the one that actually made it into the tree as 9c225f26 -
      is doing so irregardless of whether a file is seekable or not.
      
      See
      
          https://lore.kernel.org/lkml/53022DB1.4070805@gmail.com/
          https://lwn.net/Articles/180387
          https://lwn.net/Articles/180396
      
      for historic context.
      
      The reason that it did so is, probably, that there are many files that
      are marked non-seekable, but e.g. their read implementation actually
      depends on knowing current position to correctly handle the read. Some
      examples:
      
      	kernel/power/user.c		snapshot_read
      	fs/debugfs/file.c		u32_array_read
      	fs/fuse/control.c		fuse_conn_waiting_read + ...
      	drivers/hwmon/asus_atk0110.c	atk_debugfs_ggrp_read
      	arch/s390/hypfs/inode.c		hypfs_read_iter
      	...
      
      Despite that, many nonseekable_open users implement read and write with
      pure stream semantics - they don't depend on passed ppos at all. And for
      those cases where read could wait for something inside, it creates a
      situation similar to xenbus - the write could be never made to go until
      read is done, and read is waiting for some, potentially external, event,
      for potentially unbounded time -> deadlock.
      
      Besides xenbus, there are 14 such places in the kernel that I've found
      with semantic patch (see below):
      
      	drivers/xen/evtchn.c:667:8-24: ERROR: evtchn_fops: .read() can deadlock .write()
      	drivers/isdn/capi/capi.c:963:8-24: ERROR: capi_fops: .read() can deadlock .write()
      	drivers/input/evdev.c:527:1-17: ERROR: evdev_fops: .read() can deadlock .write()
      	drivers/char/pcmcia/cm4000_cs.c:1685:7-23: ERROR: cm4000_fops: .read() can deadlock .write()
      	net/rfkill/core.c:1146:8-24: ERROR: rfkill_fops: .read() can deadlock .write()
      	drivers/s390/char/fs3270.c:488:1-17: ERROR: fs3270_fops: .read() can deadlock .write()
      	drivers/usb/misc/ldusb.c:310:1-17: ERROR: ld_usb_fops: .read() can deadlock .write()
      	drivers/hid/uhid.c:635:1-17: ERROR: uhid_fops: .read() can deadlock .write()
      	net/batman-adv/icmp_socket.c:80:1-17: ERROR: batadv_fops: .read() can deadlock .write()
      	drivers/media/rc/lirc_dev.c:198:1-17: ERROR: lirc_fops: .read() can deadlock .write()
      	drivers/leds/uleds.c:77:1-17: ERROR: uleds_fops: .read() can deadlock .write()
      	drivers/input/misc/uinput.c:400:1-17: ERROR: uinput_fops: .read() can deadlock .write()
      	drivers/infiniband/core/user_mad.c:985:7-23: ERROR: umad_fops: .read() can deadlock .write()
      	drivers/gnss/core.c:45:1-17: ERROR: gnss_fops: .read() can deadlock .write()
      
      In addition to the cases above another regression caused by f_pos
      locking is that now FUSE filesystems that implement open with
      FOPEN_NONSEEKABLE flag, can no longer implement bidirectional
      stream-like files - for the same reason as above e.g. read can deadlock
      write locking on file.f_pos in the kernel.
      
      FUSE's FOPEN_NONSEEKABLE was added in 2008 in a7c1b990 ("fuse:
      implement nonseekable open") to support OSSPD. OSSPD implements /dev/dsp
      in userspace with FOPEN_NONSEEKABLE flag, with corresponding read and
      write routines not depending on current position at all, and with both
      read and write being potentially blocking operations:
      
      See
      
          https://github.com/libfuse/osspd
          https://lwn.net/Articles/308445
      
          https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1406
          https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1438-L1477
          https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1479-L1510
      
      Corresponding libfuse example/test also describes FOPEN_NONSEEKABLE as
      "somewhat pipe-like files ..." with read handler not using offset.
      However that test implements only read without write and cannot exercise
      the deadlock scenario:
      
          https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L124-L131
          https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L146-L163
          https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L209-L216
      
      I've actually hit the read vs write deadlock for real while implementing
      my FUSE filesystem where there is /head/watch file, for which open
      creates separate bidirectional socket-like stream in between filesystem
      and its user with both read and write being later performed
      simultaneously. And there it is semantically not easy to split the
      stream into two separate read-only and write-only channels:
      
          https://lab.nexedi.com/kirr/wendelin.core/blob/f13aa600/wcfs/wcfs.go#L88-169
      
      Let's fix this regression. The plan is:
      
      1. We can't change nonseekable_open to include &~FMODE_ATOMIC_POS -
         doing so would break many in-kernel nonseekable_open users which
         actually use ppos in read/write handlers.
      
      2. Add stream_open() to kernel to open stream-like non-seekable file
         descriptors. Read and write on such file descriptors would never use
         nor change ppos. And with that property on stream-like files read and
         write will be running without taking f_pos lock - i.e. read and write
         could be running simultaneously.
      
      3. With semantic patch search and convert to stream_open all in-kernel
         nonseekable_open users for which read and write actually do not
         depend on ppos and where there is no other methods in file_operations
         which assume @offset access.
      
      4. Add FOPEN_STREAM to fs/fuse/ and open in-kernel file-descriptors via
         steam_open if that bit is present in filesystem open reply.
      
         It was tempting to change fs/fuse/ open handler to use stream_open
         instead of nonseekable_open on just FOPEN_NONSEEKABLE flags, but
         grepping through Debian codesearch shows users of FOPEN_NONSEEKABLE,
         and in particular GVFS which actually uses offset in its read and
         write handlers
      
      	https://codesearch.debian.net/search?q=-%3Enonseekable+%3D
      	https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1080
      	https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1247-1346
      	https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1399-1481
      
         so if we would do such a change it will break a real user.
      
      5. Add stream_open and FOPEN_STREAM handling to stable kernels starting
         from v3.14+ (the kernel where 9c225f26 first appeared).
      
         This will allow to patch OSSPD and other FUSE filesystems that
         provide stream-like files to return FOPEN_STREAM | FOPEN_NONSEEKABLE
         in their open handler and this way avoid the deadlock on all kernel
         versions. This should work because fs/fuse/ ignores unknown open
         flags returned from a filesystem and so passing FOPEN_STREAM to a
         kernel that is not aware of this flag cannot hurt. In turn the kernel
         that is not aware of FOPEN_STREAM will be < v3.14 where just
         FOPEN_NONSEEKABLE is sufficient to implement streams without read vs
         write deadlock.
      
      This patch adds stream_open, converts /proc/xen/xenbus to it and adds
      semantic patch to automatically locate in-kernel places that are either
      required to be converted due to read vs write deadlock, or that are just
      safe to be converted because read and write do not use ppos and there
      are no other funky methods in file_operations.
      
      Regarding semantic patch I've verified each generated change manually -
      that it is correct to convert - and each other nonseekable_open instance
      left - that it is either not correct to convert there, or that it is not
      converted due to current stream_open.cocci limitations.
      
      The script also does not convert files that should be valid to convert,
      but that currently have .llseek = noop_llseek or generic_file_llseek for
      unknown reason despite file being opened with nonseekable_open (e.g.
      drivers/input/mousedev.c)
      
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Yongzhi Pan <panyongzhi@gmail.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Cc: Nikolaus Rath <Nikolaus@rath.org>
      Cc: Han-Wen Nienhuys <hanwen@google.com>
      Signed-off-by: default avatarKirill Smelkov <kirr@nexedi.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      b673f99c
  4. 09 Jun, 2019 1 commit
    • Kees Cook's avatar
      gcc-plugins: Fix build failures under Darwin host · ed69b64c
      Kees Cook authored
      commit 7210e060155b9cf557fb13128353c3e494fa5ed3 upstream.
      
      The gcc-common.h file did not take into account certain macros that
      might have already been defined in the build environment. This updates
      the header to avoid redefining the macros, as seen on a Darwin host
      using gcc 4.9.2:
      
       HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o - due to: scripts/gcc-plugins/gcc-common.h
      In file included from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:0:
      scripts/gcc-plugins/gcc-common.h:153:0: warning: "__unused" redefined
      ^
      In file included from /usr/include/stdio.h:64:0,
                      from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/system.h:40,
                      from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/gcc-plugin.h:28,
                      from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/plugin.h:23,
                      from scripts/gcc-plugins/gcc-common.h:9,
                      from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:
      /usr/include/sys/cdefs.h:161:0: note: this is the location of the previous definition
      ^
      Reported-and-tested-by: default avatar"H. Nikolaus Schaller" <hns@goldelico.com>
      Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed69b64c
  5. 04 May, 2019 2 commits
  6. 02 May, 2019 1 commit
    • Masahiro Yamada's avatar
      kbuild: simplify ld-option implementation · 1f855871
      Masahiro Yamada authored
      commit 0294e6f4 upstream.
      
      Currently, linker options are tested by the coordination of $(CC) and
      $(LD) because $(LD) needs some object to link.
      
      As commit 86a9df59 ("kbuild: fix linker feature test macros when
      cross compiling with Clang") addressed, we need to make sure $(CC)
      and $(LD) agree the underlying architecture of the passed object.
      
      This could be a bit complex when we combine tools from different groups.
      For example, we can use clang for $(CC), but we still need to rely on
      GCC toolchain for $(LD).
      
      So, I was searching for a way of standalone testing of linker options.
      A trick I found is to use '-v'; this not only prints the version string,
      but also tests if the given option is recognized.
      
      If a given option is supported,
      
        $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419
        GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706
        $ echo $?
        0
      
      If unsupported,
      
        $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419
        GNU ld (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 2.23.1
        aarch64-linux-gnu-ld: unrecognized option '--fix-cortex-a53-843419'
        aarch64-linux-gnu-ld: use the --help option for usage information
        $ echo $?
        1
      
      Gold works likewise.
      
        $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-843419
        GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14
        masahiro@pug:~/ref/linux$ echo $?
        0
        $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-999999
        GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14
        aarch64-linux-gnu-ld.gold: --fix-cortex-a53-999999: unknown option
        aarch64-linux-gnu-ld.gold: use the --help option for usage information
        $ echo $?
        1
      
      LLD too.
      
        $ ld.lld -v --gc-sections
        LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
        $ echo $?
        0
        $ ld.lld -v --fix-cortex-a53-843419
        LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
        $ echo $?
        0
        $ ld.lld -v --fix-cortex-a53-999999
        ld.lld: error: unknown argument: --fix-cortex-a53-999999
        LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
        $ echo $?
        1
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      [nc: try-run-cached was added later, just use try-run, which is the
           current mainline state]
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f855871
  7. 27 Apr, 2019 2 commits
  8. 03 Apr, 2019 1 commit
    • Fredrik Noring's avatar
      kbuild: modversions: Fix relative CRC byte order interpretation · e75c894d
      Fredrik Noring authored
      commit 54a7151b1496cddbb7a83546b7998103e98edc88 upstream.
      
      Fix commit 56067812 ("kbuild: modversions: add infrastructure for
      emitting relative CRCs") where CRCs are interpreted in host byte order
      rather than proper kernel byte order. The bug is conditional on
      CONFIG_MODULE_REL_CRCS.
      
      For example, when loading a BE module into a BE kernel compiled with a LE
      system, the error "disagrees about version of symbol module_layout" is
      produced. A message such as "Found checksum D7FA6856 vs module 5668FAD7"
      will be given with debug enabled, which indicates an obvious endian
      problem within __kcrctab within the kernel image.
      
      The general solution is to use the macro TO_NATIVE, as is done in
      similar cases throughout modpost.c. With this correction it has been
      verified that a BE kernel compiled with a LE system accepts BE modules.
      
      This change has also been verified with a LE kernel compiled with a LE
      system, in which case TO_NATIVE returns its value unmodified since the
      byte orders match. This is by far the common case.
      
      Fixes: 56067812 ("kbuild: modversions: add infrastructure for emitting relative CRCs")
      Signed-off-by: default avatarFredrik Noring <noring@nocrew.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e75c894d
  9. 12 Feb, 2019 3 commits
  10. 26 Jan, 2019 2 commits
    • Masahiro Yamada's avatar
      kconfig: fix memory leak when EOF is encountered in quotation · 3f96ff44
      Masahiro Yamada authored
      [ Upstream commit fbac5977d81cb2b2b7e37b11c459055d9585273c ]
      
      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: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3f96ff44
    • Masahiro Yamada's avatar
      kconfig: fix file name and line number of warn_ignored_character() · 407148e8
      Masahiro Yamada authored
      [ Upstream commit 77c1c0fa8b1477c5799bdad65026ea5ff676da44 ]
      
      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: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      407148e8
  11. 16 Jan, 2019 1 commit
    • WANG Chao's avatar
      x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE · 64ac5483
      WANG Chao authored
      commit e4f358916d528d479c3c12bd2fd03f2d5a576380 upstream.
      
      Commit
      
        4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
      
      replaced the RETPOLINE define with CONFIG_RETPOLINE checks. Remove the
      remaining pieces.
      
       [ bp: Massage commit message. ]
      
      Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
      Signed-off-by: default avatarWANG Chao <chao.wang@ucloud.cn>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarZhenzhong Duan <zhenzhong.duan@oracle.com>
      Reviewed-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: linux-kbuild@vger.kernel.org
      Cc: srinivas.eeda@oracle.com
      Cc: stable <stable@vger.kernel.org>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20181210163725.95977-1-chao.wang@ucloud.cnSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64ac5483
  12. 13 Jan, 2019 3 commits
  13. 08 Dec, 2018 2 commits
  14. 05 Dec, 2018 1 commit
  15. 04 Nov, 2018 1 commit
  16. 26 Sep, 2018 1 commit
    • Masahiro Yamada's avatar
      kbuild: add .DELETE_ON_ERROR special target · ee83ce18
      Masahiro Yamada authored
      [ Upstream commit 9c2af1c7 ]
      
      If Make gets a fatal signal while a shell is executing, it may delete
      the target file that the recipe was supposed to update.  This is needed
      to make sure that it is remade from scratch when Make is next run; if
      Make is interrupted after the recipe has begun to write the target file,
      it results in an incomplete file whose time stamp is newer than that
      of the prerequisites files.  Make automatically deletes the incomplete
      file on interrupt unless the target is marked .PRECIOUS.
      
      The situation is just the same as when the shell fails for some reasons.
      Usually when a recipe line fails, if it has changed the target file at
      all, the file is corrupted, or at least it is not completely updated.
      Yet the file’s time stamp says that it is now up to date, so the next
      time Make runs, it will not try to update that file.
      
      However, Make does not cater to delete the incomplete target file in
      this case.  We need to add .DELETE_ON_ERROR somewhere in the Makefile
      to request it.
      
      scripts/Kbuild.include seems a suitable place to add it because it is
      included from almost all sub-makes.
      
      Please note .DELETE_ON_ERROR is not effective for phony targets.
      
      The external module building should never ever touch the kernel tree.
      The following recipe fails if include/generated/autoconf.h is missing.
      However, include/config/auto.conf is not deleted since it is a phony
      target.
      
       PHONY += include/config/auto.conf
      
       include/config/auto.conf:
               $(Q)test -e include/generated/autoconf.h -a -e $@ || (          \
               echo >&2;                                                       \
               echo >&2 "  ERROR: Kernel configuration is invalid.";           \
               echo >&2 "         include/generated/autoconf.h or $@ are missing.";\
               echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it."; \
               echo >&2 ;                                                      \
               /bin/false)
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee83ce18
  17. 15 Sep, 2018 2 commits
  18. 05 Sep, 2018 2 commits
  19. 24 Aug, 2018 1 commit
    • Dirk Gouders's avatar
      kconfig: fix line numbers for if-entries in menu tree · 2f9e98db
      Dirk Gouders authored
      [ Upstream commit b2d00d7c ]
      
      The line numers for if-entries in the menu tree are off by one or more
      lines which is confusing when debugging for correctness of unrelated changes.
      
      According to the git log, commit a02f0570 (kconfig: improve
      error handling in the parser) was the last one that changed that part
      of the parser and replaced
      
      	"if_entry: T_IF expr T_EOL"
      by
      	"if_entry: T_IF expr nl"
      
      but the commit message does not state why this has been done.
      
      When reverting that part of the commit, only the line numers are
      corrected (checked with cdebug = DEBUG_PARSE in zconf.y), otherwise
      the menu tree remains unchanged (checked with zconfdump() enabled in
      conf.c).
      
      An example for the corrected line numbers:
      
      drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig
      drivers/soc/tegra/Kconfig:4:if
      drivers/soc/tegra/Kconfig:6:if
      
      changes to:
      
      drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig
      drivers/soc/tegra/Kconfig:1:if
      drivers/soc/tegra/Kconfig:4:if
      Signed-off-by: default avatarDirk Gouders <dirk@gouders.net>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f9e98db
  20. 17 Aug, 2018 1 commit
  21. 11 Jul, 2018 1 commit
    • Rasmus Villemoes's avatar
      Kbuild: fix # escaping in .cmd files for future Make · e8288549
      Rasmus Villemoes authored
      commit 9564a8cf upstream.
      
      I tried building using a freshly built Make (4.2.1-69-g8a731d1), but
      already the objtool build broke with
      
      orc_dump.c: In function ‘orc_dump’:
      orc_dump.c:106:2: error: ‘elf_getshnum’ is deprecated [-Werror=deprecated-declarations]
        if (elf_getshdrnum(elf, &nr_sections)) {
      
      Turns out that with that new Make, the backslash was not removed, so cpp
      didn't see a #include directive, grep found nothing, and
      -DLIBELF_USE_DEPRECATED was wrongly put in CFLAGS.
      
      Now, that new Make behaviour is documented in their NEWS file:
      
        * WARNING: Backward-incompatibility!
          Number signs (#) appearing inside a macro reference or function invocation
          no longer introduce comments and should not be escaped with backslashes:
          thus a call such as:
            foo := $(shell echo '#')
          is legal.  Previously the number sign needed to be escaped, for example:
            foo := $(shell echo '\#')
          Now this latter will resolve to "\#".  If you want to write makefiles
          portable to both versions, assign the number sign to a variable:
            C := \#
            foo := $(shell echo '$C')
          This was claimed to be fixed in 3.81, but wasn't, for some reason.
          To detect this change search for 'nocomment' in the .FEATURES variable.
      
      This also fixes up the two make-cmd instances to replace # with $(pound)
      rather than with \#. There might very well be other places that need
      similar fixup in preparation for whatever future Make release contains
      the above change, but at least this builds an x86_64 defconfig with the
      new make.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      e8288549
  22. 11 Jun, 2018 1 commit
    • Nathan Chancellor's avatar
      kconfig: Avoid format overflow warning from GCC 8.1 · d58cf419
      Nathan Chancellor authored
      commit 2ae89c7a upstream.
      
      In file included from scripts/kconfig/zconf.tab.c:2485:
      scripts/kconfig/confdata.c: In function ‘conf_write’:
      scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
        sprintf(newname, "%s%s", dirname, basename);
                            ^~
      scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
        sprintf(newname, "%s%s", dirname, basename);
                         ^~~~~~
      scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
        sprintf(newname, "%s%s", dirname, basename);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
         sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
                             ^~~~~~~~~~~
      scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
         sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Increase the size of tmpname and newname to make GCC happy.
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d58cf419
  23. 30 May, 2018 2 commits
  24. 26 Apr, 2018 3 commits
  25. 24 Mar, 2018 1 commit
    • Nick Desaulniers's avatar
      kbuild: fix linker feature test macros when cross compiling with Clang · 957435b5
      Nick Desaulniers authored
      commit 86a9df59 upstream.
      
      I was not seeing my linker flags getting added when using ld-option when
      cross compiling with Clang. Upon investigation, this seems to be due to
      a difference in how GCC vs Clang handle cross compilation.
      
      GCC is configured at build time to support one backend, that is implicit
      when compiling.  Clang is explicit via the use of `-target <triple>` and
      ships with all supported backends by default.
      
      GNU Make feature test macros that compile then link will always fail
      when cross compiling with Clang unless Clang's triple is passed along to
      the compiler. For example:
      
      $ clang -x c /dev/null -c -o temp.o
      $ aarch64-linux-android/bin/ld -E temp.o
      aarch64-linux-android/bin/ld:
      unknown architecture of input file `temp.o' is incompatible with
      aarch64 output
      aarch64-linux-android/bin/ld:
      warning: cannot find entry symbol _start; defaulting to
      0000000000400078
      $ echo $?
      1
      
      $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
      $ aarch64-linux-android/bin/ld -E temp.o
      aarch64-linux-android/bin/ld:
      warning: cannot find entry symbol _start; defaulting to 00000000004002e4
      $ echo $?
      0
      
      This causes conditional checks that invoke $(CC) without the target
      triple, then $(LD) on the result, to always fail.
      Suggested-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Hackmann <ghackmann@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      957435b5
  26. 15 Mar, 2018 2 commits