1. 11 Jun, 2019 1 commit
    • Kirill Smelkov's avatar
      fs: stream_open - opener for stream-like files so that read and write can run... · 3bf0c459
      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>
      [ backport to 4.4: actually fixed deadlock on /proc/xen/xenbus as 581d21a2 was not backported to 4.4 ]
      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>
      
      3bf0c459
  2. 29 May, 2019 1 commit
  3. 16 May, 2019 2 commits
    • Changbin Du's avatar
      kconfig/[mn]conf: handle backspace (^H) key · e0d9031f
      Changbin Du authored
      [ Upstream commit 9c38f1f044080392603c497ecca4d7d09876ff99 ]
      
      Backspace is not working on some terminal emulators which do not send the
      key code defined by terminfo. Terminals either send '^H' (8) or '^?' (127).
      But currently only '^?' is handled. Let's also handle '^H' for those
      terminals.
      Signed-off-by: default avatarChangbin Du <changbin.du@gmail.com>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin (Microsoft) <sashal@kernel.org>
      e0d9031f
    • Masahiro Yamada's avatar
      kbuild: simplify ld-option implementation · 485d15db
      Masahiro Yamada authored
      commit 0294e6f4a0006856e1f36b8cd8fa088d9e499e98 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>
      485d15db
  4. 27 Apr, 2019 2 commits
  5. 03 Apr, 2019 1 commit
  6. 20 Feb, 2019 2 commits
  7. 26 Jan, 2019 2 commits
    • Masahiro Yamada's avatar
      kconfig: fix memory leak when EOF is encountered in quotation · 0e817654
      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>
      0e817654
    • Masahiro Yamada's avatar
      kconfig: fix file name and line number of warn_ignored_character() · 6b25c8de
      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>
      6b25c8de
  8. 13 Jan, 2019 1 commit
  9. 13 Dec, 2018 2 commits
  10. 06 Dec, 2018 1 commit
  11. 27 Nov, 2018 8 commits
  12. 26 Sep, 2018 1 commit
    • Masahiro Yamada's avatar
      kbuild: add .DELETE_ON_ERROR special target · d6ac46c7
      Masahiro Yamada authored
      [ Upstream commit 9c2af1c7377a8a6ef86e5cabf80978f3dbbb25c0 ]
      
      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>
      d6ac46c7
  13. 15 Sep, 2018 2 commits
  14. 17 Aug, 2018 2 commits
  15. 19 Jul, 2018 1 commit
    • Rasmus Villemoes's avatar
      Kbuild: fix # escaping in .cmd files for future Make · 40ecc0af
      Rasmus Villemoes authored
      commit 9564a8cf422d7b58f6e857e3546d346fa970191e 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>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40ecc0af
  16. 13 Jun, 2018 1 commit
    • Nathan Chancellor's avatar
      kconfig: Avoid format overflow warning from GCC 8.1 · 31658909
      Nathan Chancellor authored
      commit 2ae89c7a82ea9d81a19b4fc2df23bef4b112f24e 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>
      31658909
  17. 30 May, 2018 3 commits
  18. 13 Apr, 2018 1 commit
  19. 18 Mar, 2018 1 commit
    • James Hogan's avatar
      kbuild: Handle builtin dtb file names containing hyphens · edcb6157
      James Hogan authored
      commit 55fe6da9 upstream.
      
      cmd_dt_S_dtb constructs the assembly source to incorporate a devicetree
      FDT (that is, the .dtb file) as binary data in the kernel image. This
      assembly source contains labels before and after the binary data. The
      label names incorporate the file name of the corresponding .dtb file.
      Hyphens are not legal characters in labels, so .dtb files built into the
      kernel with hyphens in the file name result in errors like the
      following:
      
      bcm3368-netgear-cvg834g.dtb.S: Assembler messages:
      bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section
      bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-'
      bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:'
      bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:'
      bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section
      bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-'
      
      Fix this by updating cmd_dt_S_dtb to transform all hyphens from the file
      name to underscores when constructing the labels.
      
      As of v4.16-rc2, 1139 .dts files across ARM64, ARM, MIPS and PowerPC
      contain hyphens in their names, but the issue only currently manifests
      on Broadcom MIPS platforms, as that is the only place where such files
      are built into the kernel. For example when CONFIG_DT_NETGEAR_CVG834G=y,
      or on BMIPS kernels when the dtbs target is used (in the latter case it
      admittedly shouldn't really build all the dtb.o files, but thats a
      separate issue).
      
      Fixes: 69583551 ("MIPS: BMIPS: rename bcm96358nb4ser to bcm6358-neufbox4-sercom")
      Signed-off-by: default avatarJames Hogan <jhogan@kernel.org>
      Reviewed-by: default avatarFrank Rowand <frowand.list@gmail.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: <stable@vger.kernel.org> # 4.9+
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edcb6157
  20. 25 Feb, 2018 3 commits
  21. 16 Feb, 2018 1 commit
    • Alan Modra's avatar
      powerpc: Simplify module TOC handling · fa343035
      Alan Modra authored
      commit c153693d upstream.
      
      PowerPC64 uses the symbol .TOC. much as other targets use
      _GLOBAL_OFFSET_TABLE_. It identifies the value of the GOT pointer (or in
      powerpc parlance, the TOC pointer). Global offset tables are generally
      local to an executable or shared library, or in the kernel, module. Thus
      it does not make sense for a module to resolve a relocation against
      .TOC. to the kernel's .TOC. value. A module has its own .TOC., and
      indeed the powerpc64 module relocation processing ignores the kernel
      value of .TOC. and instead calculates a module-local value.
      
      This patch removes code involved in exporting the kernel .TOC., tweaks
      modpost to ignore an undefined .TOC., and the module loader to twiddle
      the section symbol so that .TOC. isn't seen as undefined.
      
      Note that if the kernel was compiled with -msingle-pic-base then ELFv2
      would not have function global entry code setting up r2. In that case
      the module call stubs would need to be modified to set up r2 using the
      kernel .TOC. value, requiring some of this code to be reinstated.
      
      mpe: Furthermore a change in binutils master (not yet released) causes
      the current way we handle the TOC to no longer work when building with
      MODVERSIONS=y and RELOCATABLE=n. The symptom is that modules can not be
      loaded due to there being no version found for TOC.
      Signed-off-by: default avatarAlan Modra <amodra@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa343035
  22. 23 Jan, 2018 1 commit