1. 19 2月, 2019 1 次提交
    • Y
      32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option · 942fa985
      Yury Norov 提交于
      All new 32-bit architectures should have 64-bit userspace off_t type, but
      existing architectures has 32-bit ones.
      
      To enforce the rule, new config option is added to arch/Kconfig that defaults
      ARCH_32BIT_OFF_T to be disabled for new 32-bit architectures. All existing
      32-bit architectures enable it explicitly.
      
      New option affects force_o_largefile() behaviour. Namely, if userspace
      off_t is 64-bits long, we have no reason to reject user to open big files.
      
      Note that even if architectures has only 64-bit off_t in the kernel
      (arc, c6x, h8300, hexagon, nios2, openrisc, and unicore32),
      a libc may use 32-bit off_t, and therefore want to limit the file size
      to 4GB unless specified differently in the open flags.
      Signed-off-by: NYury Norov <ynorov@caviumnetworks.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NYury Norov <ynorov@marvell.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      942fa985
  2. 06 1月, 2019 2 次提交
  3. 05 1月, 2019 3 次提交
  4. 04 1月, 2019 1 次提交
    • L
      Remove 'type' argument from access_ok() function · 96d4f267
      Linus Torvalds 提交于
      Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
      of the user address range verification function since we got rid of the
      old racy i386-only code to walk page tables by hand.
      
      It existed because the original 80386 would not honor the write protect
      bit when in kernel mode, so you had to do COW by hand before doing any
      user access.  But we haven't supported that in a long time, and these
      days the 'type' argument is a purely historical artifact.
      
      A discussion about extending 'user_access_begin()' to do the range
      checking resulted this patch, because there is no way we're going to
      move the old VERIFY_xyz interface to that model.  And it's best done at
      the end of the merge window when I've done most of my merges, so let's
      just get this done once and for all.
      
      This patch was mostly done with a sed-script, with manual fix-ups for
      the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
      
      There were a couple of notable cases:
      
       - csky still had the old "verify_area()" name as an alias.
      
       - the iter_iov code had magical hardcoded knowledge of the actual
         values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
         really used it)
      
       - microblaze used the type argument for a debug printout
      
      but other than those oddities this should be a total no-op patch.
      
      I tried to fix up all architectures, did fairly extensive grepping for
      access_ok() uses, and the changes are trivial, but I may have missed
      something.  Any missed conversion should be trivially fixable, though.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      96d4f267
  5. 30 12月, 2018 3 次提交
    • C
      kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops · cc028297
      Christophe Leroy 提交于
      checkpatch.pl reports the following:
      
        WARNING: struct kgdb_arch should normally be const
        #28: FILE: arch/mips/kernel/kgdb.c:397:
        +struct kgdb_arch arch_kgdb_ops = {
      
      This report makes sense, as all other ops struct, this
      one should also be const. This patch does the change.
      
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Rich Felker <dalias@libc.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: x86@kernel.org
      Acked-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Acked-by: NPaul Burton <paul.burton@mips.com>
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      cc028297
    • D
      kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function() · 3cd99ac3
      Douglas Anderson 提交于
      When I had lockdep turned on and dropped into kgdb I got a nice splat
      on my system.  Specifically it hit:
        DEBUG_LOCKS_WARN_ON(current->hardirq_context)
      
      Specifically it looked like this:
        sysrq: SysRq : DEBUG
        ------------[ cut here ]------------
        DEBUG_LOCKS_WARN_ON(current->hardirq_context)
        WARNING: CPU: 0 PID: 0 at .../kernel/locking/lockdep.c:2875 lockdep_hardirqs_on+0xf0/0x160
        CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0 #27
        pstate: 604003c9 (nZCv DAIF +PAN -UAO)
        pc : lockdep_hardirqs_on+0xf0/0x160
        ...
        Call trace:
         lockdep_hardirqs_on+0xf0/0x160
         trace_hardirqs_on+0x188/0x1ac
         kgdb_roundup_cpus+0x14/0x3c
         kgdb_cpu_enter+0x53c/0x5cc
         kgdb_handle_exception+0x180/0x1d4
         kgdb_compiled_brk_fn+0x30/0x3c
         brk_handler+0x134/0x178
         do_debug_exception+0xfc/0x178
         el1_dbg+0x18/0x78
         kgdb_breakpoint+0x34/0x58
         sysrq_handle_dbg+0x54/0x5c
         __handle_sysrq+0x114/0x21c
         handle_sysrq+0x30/0x3c
         qcom_geni_serial_isr+0x2dc/0x30c
        ...
        ...
        irq event stamp: ...45
        hardirqs last  enabled at (...44): [...] __do_softirq+0xd8/0x4e4
        hardirqs last disabled at (...45): [...] el1_irq+0x74/0x130
        softirqs last  enabled at (...42): [...] _local_bh_enable+0x2c/0x34
        softirqs last disabled at (...43): [...] irq_exit+0xa8/0x100
        ---[ end trace adf21f830c46e638 ]---
      
      Looking closely at it, it seems like a really bad idea to be calling
      local_irq_enable() in kgdb_roundup_cpus().  If nothing else that seems
      like it could violate spinlock semantics and cause a deadlock.
      
      Instead, let's use a private csd alongside
      smp_call_function_single_async() to round up the other CPUs.  Using
      smp_call_function_single_async() doesn't require interrupts to be
      enabled so we can remove the offending bit of code.
      
      In order to avoid duplicating this across all the architectures that
      use the default kgdb_roundup_cpus(), we'll add a "weak" implementation
      to debug_core.c.
      
      Looking at all the people who previously had copies of this code,
      there were a few variants.  I've attempted to keep the variants
      working like they used to.  Specifically:
      * For arch/arc we passed NULL to kgdb_nmicallback() instead of
        get_irq_regs().
      * For arch/mips there was a bit of extra code around
        kgdb_nmicallback()
      
      NOTE: In this patch we will still get into trouble if we try to round
      up a CPU that failed to round up before.  We'll try to round it up
      again and potentially hang when we try to grab the csd lock.  That's
      not new behavior but we'll still try to do better in a future patch.
      Suggested-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      3cd99ac3
    • D
      kgdb: Remove irq flags from roundup · 9ef7fa50
      Douglas Anderson 提交于
      The function kgdb_roundup_cpus() was passed a parameter that was
      documented as:
      
      > the flags that will be used when restoring the interrupts. There is
      > local_irq_save() call before kgdb_roundup_cpus().
      
      Nobody used those flags.  Anyone who wanted to temporarily turn on
      interrupts just did local_irq_enable() and local_irq_disable() without
      looking at them.  So we can definitely remove the flags.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      9ef7fa50
  6. 21 12月, 2018 1 次提交
  7. 20 12月, 2018 1 次提交
    • C
      dma-mapping: zero memory returned from dma_alloc_* · 518a2f19
      Christoph Hellwig 提交于
      If we want to map memory from the DMA allocator to userspace it must be
      zeroed at allocation time to prevent stale data leaks.   We already do
      this on most common architectures, but some architectures don't do this
      yet, fix them up, either by passing GFP_ZERO when we use the normal page
      allocator or doing a manual memset otherwise.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Sam Ravnborg <sam@ravnborg.org> [sparc]
      518a2f19
  8. 19 12月, 2018 1 次提交
    • A
      clocksource/drivers/arc_timer: Utilize generic sched_clock · bf287607
      Alexey Brodkin 提交于
      It turned out we used to use default implementation of sched_clock()
      from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
      by default we had 10 msec granularity of time measurement.
      
      Now given ARC built-in timers are clocked with the same frequency as
      CPU cores we may get much higher precision of time tracking.
      
      Thus we switch to generic sched_clock which really reads ARC hardware
      counters.
      
      This is especially helpful for measuring short events.
      That's what we used to have:
      ------------------------------>8------------------------
      $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
      
       Performance counter stats for '/bin/sh -c /root/lmbench-master/bin/arc/hello':
      
               10.000000      task-clock (msec)         #    2.832 CPUs utilized
                       1      context-switches          #    0.100 K/sec
                       1      cpu-migrations            #    0.100 K/sec
                      63      page-faults               #    0.006 M/sec
                 3049480      cycles                    #    0.305 GHz
                 1091259      instructions              #    0.36  insn per cycle
                  256828      branches                  #   25.683 M/sec
                   27026      branch-misses             #   10.52% of all branches
      
             0.003530687 seconds time elapsed
      
             0.000000000 seconds user
             0.010000000 seconds sys
      ------------------------------>8------------------------
      
      And now we'll see:
      ------------------------------>8------------------------
      $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
      
       Performance counter stats for '/bin/sh -c /root/lmbench-master/bin/arc/hello':
      
                3.004322      task-clock (msec)         #    0.865 CPUs utilized
                       1      context-switches          #    0.333 K/sec
                       1      cpu-migrations            #    0.333 K/sec
                      63      page-faults               #    0.021 M/sec
                 2986734      cycles                    #    0.994 GHz
                 1087466      instructions              #    0.36  insn per cycle
                  255209      branches                  #   84.947 M/sec
                   26002      branch-misses             #   10.19% of all branches
      
             0.003474829 seconds time elapsed
      
             0.003519000 seconds user
             0.000000000 seconds sys
      ------------------------------>8------------------------
      
      Note how much more meaningful is the second output - time spent for
      execution pretty much matches number of cycles spent (we're runnign
      @ 1GHz here).
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      bf287607
  9. 14 12月, 2018 2 次提交
  10. 06 12月, 2018 1 次提交
  11. 01 12月, 2018 2 次提交
    • J
      ARC: io.h: Implement reads{x}()/writes{x}() · 10d44343
      Jose Abreu 提交于
      Some ARC CPU's do not support unaligned loads/stores. Currently, generic
      implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC.
      This can lead to misfunction of some drivers as generic functions do a
      plain dereference of a pointer that can be unaligned.
      
      Let's use {get/put}_unaligned() helpers instead of plain dereference of
      pointer in order to fix. The helpers allow to get and store data from an
      unaligned address whilst preserving the CPU internal alignment.
      According to [1], the use of these helpers are costly in terms of
      performance so we added an initial check for a buffer already aligned so
      that the usage of the helpers can be avoided, when possible.
      
      [1] Documentation/unaligned-memory-access.txt
      
      Cc: Alexey Brodkin <abrodkin@synopsys.com>
      Cc: Joao Pinto <jpinto@synopsys.com>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Tested-by: NVitor Soares <soares@synopsys.com>
      Signed-off-by: NJose Abreu <joabreu@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      10d44343
    • K
      ARC: change defconfig defaults to ARCv2 · b7cc40c3
      Kevin Hilman 提交于
      Change the default defconfig (used with 'make defconfig') to the ARCv2
      nsim_hs_defconfig, and also switch the default Kconfig ISA selection to
      ARCv2.
      
      This allows several default defconfigs (e.g. make defconfig, make
      allnoconfig, make tinyconfig) to all work with ARCv2 by default.
      
      Note since we change default architecture from ARCompact to ARCv2
      it's required to explicitly mention architecture type in ARCompact
      defconfigs otherwise ARCv2 will be implied and binaries will be
      generated for ARCv2.
      
      Cc: <stable@vger.kernel.org> # 4.4.x
      Signed-off-by: NKevin Hilman <khilman@baylibre.com>
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      b7cc40c3
  12. 27 11月, 2018 1 次提交
  13. 23 11月, 2018 2 次提交
  14. 22 11月, 2018 1 次提交
  15. 13 11月, 2018 5 次提交
  16. 31 10月, 2018 7 次提交
  17. 11 10月, 2018 1 次提交
  18. 06 10月, 2018 1 次提交
  19. 02 10月, 2018 1 次提交
    • R
      kbuild: consolidate Devicetree dtb build rules · 37c8a5fa
      Rob Herring 提交于
      There is nothing arch specific about building dtb files other than their
      location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
      The dependencies and supported targets are all slightly different.
      Also, a cross-compiler for each arch is needed, but really the host
      compiler preprocessor is perfectly fine for building dtbs. Move the
      build rules to a common location and remove the arch specific ones. This
      is done in a single step to avoid warnings about overriding rules.
      
      The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
      These pull in several dependencies some of which need a target compiler
      (specifically devicetable-offsets.h) and aren't needed to build dtbs.
      All that is really needed is dtc, so adjust the dependencies to only be
      dtc.
      
      This change enables support 'dtbs_install' on some arches which were
      missing the target.
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Acked-by: NPaul Burton <paul.burton@mips.com>
      Acked-by: NLey Foon Tan <ley.foon.tan@intel.com>
      Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: linux-kbuild@vger.kernel.org
      Cc: linux-snps-arc@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: uclinux-h8-devel@lists.sourceforge.jp
      Cc: linux-mips@linux-mips.org
      Cc: nios2-dev@lists.rocketboards.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-xtensa@linux-xtensa.org
      Signed-off-by: NRob Herring <robh@kernel.org>
      37c8a5fa
  20. 28 9月, 2018 2 次提交
  21. 20 9月, 2018 1 次提交
    • C
      dma-mapping: consolidate the dma mmap implementations · 58b04406
      Christoph Hellwig 提交于
      The only functional differences (modulo a few missing fixes in the arch
      code) is that architectures without coherent caches need a hook to
      convert a virtual or dma address into a pfn, given that we don't have
      the kernel linear mapping available for the otherwise easy virt_to_page
      call.  As a side effect we can support mmap of the per-device coherent
      area even on architectures not providing the callback, and we make
      previous dangerous default methods dma_common_mmap actually save for
      non-coherent architectures by rejecting it without the right helper.
      
      In addition to that we need a hook so that some architectures can
      override the protection bits when mmaping a dma coherent allocations.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: Paul Burton <paul.burton@mips.com> # MIPS parts
      58b04406
新手
引导
客服 返回
顶部