1. 06 Jan, 2019 10 commits
    • Linus Torvalds's avatar
      Fix 'acccess_ok()' on alpha and SH · 94bd8a05
      Linus Torvalds authored
      Commit 594cc251 ("make 'user_access_begin()' do 'access_ok()'")
      broke both alpha and SH booting in qemu, as noticed by Guenter Roeck.
      
      It turns out that the bug wasn't actually in that commit itself (which
      would have been surprising: it was mostly a no-op), but in how the
      addition of access_ok() to the strncpy_from_user() and strnlen_user()
      functions now triggered the case where those functions would test the
      access of the very last byte of the user address space.
      
      The string functions actually did that user range test before too, but
      they did it manually by just comparing against user_addr_max().  But
      with user_access_begin() doing the check (using "access_ok()"), it now
      exposed problems in the architecture implementations of that function.
      
      For example, on alpha, the access_ok() helper macro looked like this:
      
        #define __access_ok(addr, size) \
              ((get_fs().seg & (addr | size | (addr+size))) == 0)
      
      and what it basically tests is of any of the high bits get set (the
      USER_DS masking value is 0xfffffc0000000000).
      
      And that's completely wrong for the "addr+size" check.  Because it's
      off-by-one for the case where we check to the very end of the user
      address space, which is exactly what the strn*_user() functions do.
      
      Why? Because "addr+size" will be exactly the size of the address space,
      so trying to access the last byte of the user address space will fail
      the __access_ok() check, even though it shouldn't.  As a result, the
      user string accessor functions failed consistently - because they
      literally don't know how long the string is going to be, and the max
      access is going to be that last byte of the user address space.
      
      Side note: that alpha macro is buggy for another reason too - it re-uses
      the arguments twice.
      
      And SH has another version of almost the exact same bug:
      
        #define __addr_ok(addr) \
              ((unsigned long __force)(addr) < current_thread_info()->addr_limit.seg)
      
      so far so good: yes, a user address must be below the limit.  But then:
      
        #define __access_ok(addr, size)         \
              (__addr_ok((addr) + (size)))
      
      is wrong with the exact same off-by-one case: the case when "addr+size"
      is exactly _equal_ to the limit is actually perfectly fine (think "one
      byte access at the last address of the user address space")
      
      The SH version is actually seriously buggy in another way: it doesn't
      actually check for overflow, even though it did copy the _comment_ that
      talks about overflow.
      
      So it turns out that both SH and alpha actually have completely buggy
      implementations of access_ok(), but they happened to work in practice
      (although the SH overflow one is a serious serious security bug, not
      that anybody likely cares about SH security).
      
      This fixes the problems by using a similar macro on both alpha and SH.
      It isn't trying to be clever, the end address is based on this logic:
      
              unsigned long __ao_end = __ao_a + __ao_b - !!__ao_b;
      
      which basically says "add start and length, and then subtract one unless
      the length was zero".  We can't subtract one for a zero length, or we'd
      just hit an underflow instead.
      
      For a lot of access_ok() users the length is a constant, so this isn't
      actually as expensive as it initially looks.
      Reported-and-tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      94bd8a05
    • Masahiro Yamada's avatar
      kbuild: use assignment instead of define ... endef for filechk_* rules · ba97df45
      Masahiro Yamada authored
      You do not have to use define ... endef for filechk_* rules.
      
      For simple cases, the use of assignment looks cleaner, IMHO.
      
      I updated the usage for scripts/Kbuild.include in case somebody
      misunderstands the 'define ... endif' is the requirement.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      ba97df45
    • Masahiro Yamada's avatar
      arch: remove redundant UAPI generic-y defines · d6e4b3e3
      Masahiro Yamada authored
      Now that Kbuild automatically creates asm-generic wrappers for missing
      mandatory headers, it is redundant to list the same headers in
      generic-y and mandatory-y.
      Suggested-by: Sam Ravnborg's avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: Sam Ravnborg's avatarSam Ravnborg <sam@ravnborg.org>
      d6e4b3e3
    • Masahiro Yamada's avatar
      arch: remove stale comments "UAPI Header export list" · d4ce5458
      Masahiro Yamada authored
      These comments are leftovers of commit fcc8487d ("uapi: export all
      headers under uapi directories").
      
      Prior to that commit, exported headers must be explicitly added to
      header-y. Now, all headers under the uapi/ directories are exported.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      d4ce5458
    • Masahiro Yamada's avatar
      riscv: remove redundant kernel-space generic-y · 8c4fa8b8
      Masahiro Yamada authored
      This commit removes redundant generic-y defines in
      arch/riscv/include/asm/Kbuild.
      
      [1] It is redundant to define the same generic-y in both
          arch/$(ARCH)/include/asm/Kbuild and
          arch/$(ARCH)/include/uapi/asm/Kbuild.
      
          Remove the following generic-y:
      
            errno.h
            fcntl.h
            ioctl.h
            ioctls.h
            ipcbuf.h
            mman.h
            msgbuf.h
            param.h
            poll.h
            posix_types.h
            resource.h
            sembuf.h
            setup.h
            shmbuf.h
            signal.h
            socket.h
            sockios.h
            stat.h
            statfs.h
            swab.h
            termbits.h
            termios.h
            types.h
      
      [2] It is redundant to define generic-y when arch-specific
          implementation exists in arch/$(ARCH)/include/asm/*.h
      
          Remove the following generic-y:
      
            cacheflush.h
            module.h
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      8c4fa8b8
    • Masahiro Yamada's avatar
      kbuild: change filechk to surround the given command with { } · ad774086
      Masahiro Yamada authored
      filechk_* rules often consist of multiple 'echo' lines. They must be
      surrounded with { } or ( ) to work correctly. Otherwise, only the
      string from the last 'echo' would be written into the target.
      
      Let's take care of that in the 'filechk' in scripts/Kbuild.include
      to clean up filechk_* rules.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      ad774086
    • Masahiro Yamada's avatar
      kbuild: remove redundant target cleaning on failure · 172caf19
      Masahiro Yamada authored
      Since commit 9c2af1c7 ("kbuild: add .DELETE_ON_ERROR special
      target"), the target file is automatically deleted on failure.
      
      The boilerplate code
      
        ... || { rm -f $@; false; }
      
      is unneeded.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      172caf19
    • Masahiro Yamada's avatar
      jump_label: move 'asm goto' support test to Kconfig · e9666d10
      Masahiro Yamada authored
      Currently, CONFIG_JUMP_LABEL just means "I _want_ to use jump label".
      
      The jump label is controlled by HAVE_JUMP_LABEL, which is defined
      like this:
      
        #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
        # define HAVE_JUMP_LABEL
        #endif
      
      We can improve this by testing 'asm goto' support in Kconfig, then
      make JUMP_LABEL depend on CC_HAS_ASM_GOTO.
      
      Ugly #ifdef HAVE_JUMP_LABEL will go away, and CONFIG_JUMP_LABEL will
      match to the real kernel capability.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      e9666d10
    • Masahiro Yamada's avatar
      nds32: remove redundant kernel-space generic-y · 5c0ab286
      Masahiro Yamada authored
      This commit removes redundant generic-y defines in
      arch/nds32/include/asm/Kbuild.
      
      [1] It is redundant to define the same generic-y in both
          arch/$(ARCH)/include/asm/Kbuild and
          arch/$(ARCH)/include/uapi/asm/Kbuild.
      
          Remove the following generic-y:
      
            bitsperlong.h
            bpf_perf_event.h
            errno.h
            fcntl.h
            ioctl.h
            ioctls.h
            mman.h
            shmbuf.h
            stat.h
      
      [2] It is redundant to define generic-y when arch-specific
          implementation exists in arch/$(ARCH)/include/asm/*.h
      
          Remove the following generic-y:
      
            ftrace.h
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      5c0ab286
    • Masahiro Yamada's avatar
      nios2: remove unneeded HAS_DMA define · fd8658b5
      Masahiro Yamada authored
      kernel/dma/Kconfig globally defines HAS_DMA as follows:
      
        config HAS_DMA
                bool
                depends on !NO_DMA
                default y
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      fd8658b5
  2. 05 Jan, 2019 5 commits
    • Christoph Hellwig's avatar
      x86/amd_gart: fix unmapping of non-GART mappings · 06f55fd2
      Christoph Hellwig authored
      In many cases we don't have to create a GART mapping at all, which
      also means there is nothing to unmap.  Fix the range check that was
      incorrectly modified when removing the mapping_error method.
      
      Fixes: 9e8aa6b5 ("x86/amd_gart: remove the mapping_error dma_map_ops method")
      Reported-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Tested-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      06f55fd2
    • Christoph Hellwig's avatar
      ia64: fix compile without swiotlb · 3fed6ae4
      Christoph Hellwig authored
      Some non-generic ia64 configs don't build swiotlb, and thus should not
      pull in the generic non-coherent DMA infrastructure.
      
      Fixes: 68c60834 ("swiotlb: remove dma_mark_clean")
      Reported-by: default avatarTony Luck <tony.luck@gmail.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3fed6ae4
    • Linus Torvalds's avatar
      x86: re-introduce non-generic memcpy_{to,from}io · 170d13ca
      Linus Torvalds authored
      This has been broken forever, and nobody ever really noticed because
      it's purely a performance issue.
      
      Long long ago, in commit 6175ddf0 ("x86: Clean up mem*io functions")
      Brian Gerst simplified the memory copies to and from iomem, since on
      x86, the instructions to access iomem are exactly the same as the
      regular instructions.
      
      That is technically true, and things worked, and nobody said anything.
      Besides, back then the regular memcpy was pretty simple and worked fine.
      
      Nobody noticed except for David Laight, that is.  David has a testing a
      TLP monitor he was writing for an FPGA, and has been occasionally
      complaining about how memcpy_toio() writes things one byte at a time.
      
      Which is completely unacceptable from a performance standpoint, even if
      it happens to technically work.
      
      The reason it's writing one byte at a time is because while it's
      technically true that accesses to iomem are the same as accesses to
      regular memory on x86, the _granularity_ (and ordering) of accesses
      matter to iomem in ways that they don't matter to regular cached memory.
      
      In particular, when ERMS is set, we default to using "rep movsb" for
      larger memory copies.  That is indeed perfectly fine for real memory,
      since the whole point is that the CPU is going to do cacheline
      optimizations and executes the memory copy efficiently for cached
      memory.
      
      With iomem? Not so much.  With iomem, "rep movsb" will indeed work, but
      it will copy things one byte at a time. Slowly and ponderously.
      
      Now, originally, back in 2010 when commit 6175ddf0 was done, we
      didn't use ERMS, and this was much less noticeable.
      
      Our normal memcpy() was simpler in other ways too.
      
      Because in fact, it's not just about using the string instructions.  Our
      memcpy() these days does things like "read and write overlapping values"
      to handle the last bytes of the copy.  Again, for normal memory,
      overlapping accesses isn't an issue.  For iomem? It can be.
      
      So this re-introduces the specialized memcpy_toio(), memcpy_fromio() and
      memset_io() functions.  It doesn't particularly optimize them, but it
      tries to at least not be horrid, or do overlapping accesses.  In fact,
      this uses the existing __inline_memcpy() function that we still had
      lying around that uses our very traditional "rep movsl" loop followed by
      movsw/movsb for the final bytes.
      
      Somebody may decide to try to improve on it, but if we've gone almost a
      decade with only one person really ever noticing and complaining, maybe
      it's not worth worrying about further, once it's not _completely_ broken?
      Reported-by: default avatarDavid Laight <David.Laight@aculab.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      170d13ca
    • Linus Torvalds's avatar
      Use __put_user_goto in __put_user_size() and unsafe_put_user() · a959dc88
      Linus Torvalds authored
      This actually enables the __put_user_goto() functionality in
      unsafe_put_user().
      
      For an example of the effect of this, this is the code generated for the
      
              unsafe_put_user(signo, &infop->si_signo, Efault);
      
      in the waitid() system call:
      
      	movl %ecx,(%rbx)        # signo, MEM[(struct __large_struct *)_2]
      
      It's just one single store instruction, along with generating an
      exception table entry pointing to the Efault label case in case that
      instruction faults.
      
      Before, we would generate this:
      
      	xorl    %edx, %edx
      	movl %ecx,(%rbx)        # signo, MEM[(struct __large_struct *)_3]
              testl   %edx, %edx
              jne     .L309
      
      with the exception table generated for that 'mov' instruction causing us
      to jump to a stub that set %edx to -EFAULT and then jumped back to the
      'testl' instruction.
      
      So not only do we now get rid of the extra code in the normal sequence,
      we also avoid unnecessarily keeping that extra error register live
      across it all.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a959dc88
    • Linus Torvalds's avatar
      x86 uaccess: Introduce __put_user_goto · 4a789213
      Linus Torvalds authored
      This is finally the actual reason for the odd error handling in the
      "unsafe_get/put_user()" functions, introduced over three years ago.
      
      Using a "jump to error label" interface is somewhat odd, but very
      convenient as a programming interface, and more importantly, it fits
      very well with simply making the target be the exception handler address
      directly from the inline asm.
      
      The reason it took over three years to actually do this? We need "asm
      goto" support for it, which only became the default on x86 last year.
      It's now been a year that we've forced asm goto support (see commit
      e501ce95 "x86: Force asm-goto"), and so let's just do it here too.
      
      [ Side note: this commit was originally done back in 2016. The above
        commentary about timing is obviously about it only now getting merged
        into my real upstream tree     - Linus ]
      
      Sadly, gcc still only supports "asm goto" with asms that do not have any
      outputs, so we are limited to only the put_user case for this.  Maybe in
      several more years we can do the get_user case too.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4a789213
  3. 04 Jan, 2019 18 commits
  4. 03 Jan, 2019 3 commits
    • Yueyi Li's avatar
      arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region · c8a43c18
      Yueyi Li authored
      When KASLR is enabled (CONFIG_RANDOMIZE_BASE=y), the top 4K of kernel
      virtual address space may be mapped to physical addresses despite being
      reserved for ERR_PTR values.
      
      Fix the randomization of the linear region so that we avoid mapping the
      last page of the virtual address space.
      
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarliyueyi <liyueyi@live.com>
      [will: rewrote commit message; merged in suggestion from Ard]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c8a43c18
    • Mark Rutland's avatar
      arm64: entry: remove unused register aliases · 8c2c596f
      Mark Rutland authored
      In commit:
      
        3b714275 ("arm64: convert native/compat syscall entry to C")
      
      ... we moved the syscall invocation code from assembly to C, but left
      behind a number of register aliases which are now unused.
      
      Let's remove them before they confuse someone.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8c2c596f
    • Shaokun Zhang's avatar
      arm64: smp: Fix compilation error · 1236cd2b
      Shaokun Zhang authored
      For arm64: updates for 4.21, there is a compilation error:
      arch/arm64/kernel/head.S: Assembler messages:
      arch/arm64/kernel/head.S:824: Error: missing ')'
      arch/arm64/kernel/head.S:824: Error: missing ')'
      arch/arm64/kernel/head.S:824: Error: missing ')'
      arch/arm64/kernel/head.S:824: Error: unexpected characters following instruction at operand 2 -- `mov x2,#(2)|(2U<<(8))'
      scripts/Makefile.build:391: recipe for target 'arch/arm64/kernel/head.o' failed
      make[1]: *** [arch/arm64/kernel/head.o] Error 1
      GCC version is gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
      
      Let's fix it using the UL() macro.
      
      Fixes: 66f16a24 ("arm64: smp: Rework early feature mismatched detection")
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Tested-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarShaokun Zhang <zhangshaokun@hisilicon.com>
      [will: consistent use of UL() for all shifts in asm constants]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1236cd2b
  5. 02 Jan, 2019 3 commits
  6. 31 Dec, 2018 1 commit