1. 14 6月, 2018 1 次提交
    • L
      Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables · 050e9baa
      Linus Torvalds 提交于
      The changes to automatically test for working stack protector compiler
      support in the Kconfig files removed the special STACKPROTECTOR_AUTO
      option that picked the strongest stack protector that the compiler
      supported.
      
      That was all a nice cleanup - it makes no sense to have the AUTO case
      now that the Kconfig phase can just determine the compiler support
      directly.
      
      HOWEVER.
      
      It also meant that doing "make oldconfig" would now _disable_ the strong
      stackprotector if you had AUTO enabled, because in a legacy config file,
      the sane stack protector configuration would look like
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        # CONFIG_CC_STACKPROTECTOR_NONE is not set
        # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
        # CONFIG_CC_STACKPROTECTOR_STRONG is not set
        CONFIG_CC_STACKPROTECTOR_AUTO=y
      
      and when you ran this through "make oldconfig" with the Kbuild changes,
      it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
      been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
      CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
      used to be disabled (because it was really enabled by AUTO), and would
      disable it in the new config, resulting in:
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
        CONFIG_CC_STACKPROTECTOR=y
        # CONFIG_CC_STACKPROTECTOR_STRONG is not set
        CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
      
      That's dangerously subtle - people could suddenly find themselves with
      the weaker stack protector setup without even realizing.
      
      The solution here is to just rename not just the old RECULAR stack
      protector option, but also the strong one.  This does that by just
      removing the CC_ prefix entirely for the user choices, because it really
      is not about the compiler support (the compiler support now instead
      automatially impacts _visibility_ of the options to users).
      
      This results in "make oldconfig" actually asking the user for their
      choice, so that we don't have any silent subtle security model changes.
      The end result would generally look like this:
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
        CONFIG_STACKPROTECTOR=y
        CONFIG_STACKPROTECTOR_STRONG=y
        CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
      
      where the "CC_" versions really are about internal compiler
      infrastructure, not the user selections.
      Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      050e9baa
  2. 18 12月, 2017 1 次提交
  3. 14 8月, 2017 1 次提交
    • R
      ARM: align .data section · 1abd3502
      Russell King 提交于
      Robert Jarzmik reports that his PXA25x system fails to boot with 4.12,
      failing at __flush_whole_cache in arch/arm/mm/proc-xscale.S:215:
      
         0xc0019e20 <+0>:     ldr     r1, [pc, #788]
         0xc0019e24 <+4>:     ldr     r0, [r1]	<== here
      
      with r1 containing 0xc06f82cd, which is the address of "clean_addr".
      Examination of the System.map shows:
      
      c06f22c8 D user_pmd_table
      c06f22cc d __warned.19178
      c06f22cd d clean_addr
      
      indicating that a .data.unlikely section has appeared just before the
      .data section from proc-xscale.S.  According to objdump -h, it appears
      that our assembly files default their .data alignment to 2**0, which
      is bad news if the preceding .data section size is not power-of-2
      aligned at link time.
      
      Add the appropriate .align directives to all assembly files in arch/arm
      that are missing them where we require an appropriate alignment.
      Reported-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      1abd3502
  4. 01 7月, 2017 1 次提交
    • A
      ARM: Prepare for randomized task_struct · ffa47aa6
      Arnd Bergmann 提交于
      With the new task struct randomization, we can run into a build
      failure for certain random seeds, which will place fields beyond
      the allow immediate size in the assembly:
      
      arch/arm/kernel/entry-armv.S: Assembler messages:
      arch/arm/kernel/entry-armv.S:803: Error: bad immediate value for offset (4096)
      
      Only two constants in asm-offset.h are affected, and I'm changing
      both of them here to work correctly in all configurations.
      
      One more macro has the problem, but is currently unused, so this
      removes it instead of adding complexity.
      Suggested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      [kees: Adjust commit log slightly]
      Signed-off-by: NKees Cook <keescook@chromium.org>
      ffa47aa6
  5. 10 8月, 2016 1 次提交
  6. 07 7月, 2016 1 次提交
  7. 23 6月, 2016 2 次提交
  8. 11 2月, 2016 2 次提交
    • A
      ARM: 8515/2: move .vectors and .stubs sections back into the kernel VMA · 31b96cae
      Ard Biesheuvel 提交于
      Commit b9b32bf7 ("ARM: use linker magic for vectors and vector stubs")
      updated the linker script to emit the .vectors and .stubs sections into a
      VMA range that is zero based and disjoint from the normal static kernel
      region. The reason for that was that this way, the sections can be placed
      exactly 4 KB apart, while the payload of the .vectors section is only 32
      bytes.
      
      Since the symbols that are part of the .stubs section are emitted into the
      kallsyms table, they appear with zero based addresses as well, e.g.,
      
        00001004 t vector_rst
        00001020 t vector_irq
        000010a0 t vector_dabt
        00001120 t vector_pabt
        000011a0 t vector_und
        00001220 t vector_addrexcptn
        00001240 t vector_fiq
        00001240 T vector_fiq_offset
      
      As this confuses perf when it accesses the kallsyms tables, commit
      7122c3e9 ("scripts/link-vmlinux.sh: only filter kernel symbols for
      arm") implemented a somewhat ugly special case for ARM, where the value
      of CONFIG_PAGE_OFFSET is passed to scripts/kallsyms, and symbols whose
      addresses are below it are filtered out. Note that this special case only
      applies to CONFIG_XIP_KERNEL=n, not because the issue the patch addresses
      exists only in that case, but because finding a limit below which to apply
      the filtering is not entirely straightforward.
      
      Since the .vectors and .stubs sections contain position independent code
      that is never executed in place, we can emit it at its most likely runtime
      VMA (for more recent CPUs), which is 0xffff0000 for the vector table and
      0xffff1000 for the stubs. Not only does this fix the perf issue with
      kallsyms, allowing us to drop the special case in scripts/kallsyms
      entirely, it also gives debuggers a more realistic view of the address
      space, and setting breakpoints or single stepping through code in the
      vector table or the stubs is more likely to work as expected on CPUs that
      use a high vector address. E.g.,
      
        00001240 A vector_fiq_offset
        ...
        c0c35000 T __init_begin
        c0c35000 T __vectors_start
        c0c35020 T __stubs_start
        c0c35020 T __vectors_end
        c0c352e0 T _sinittext
        c0c352e0 T __stubs_end
        ...
        ffff1004 t vector_rst
        ffff1020 t vector_irq
        ffff10a0 t vector_dabt
        ffff1120 t vector_pabt
        ffff11a0 t vector_und
        ffff1220 t vector_addrexcptn
        ffff1240 T vector_fiq
      
      (Note that vector_fiq_offset is now an absolute symbol, which kallsyms
      already ignores by default)
      
      The LMA footprint is identical with or without this change, only the VMAs
      are different:
      
        Before:
        Idx Name          Size      VMA       LMA       File off  Algn
         ...
         14 .notes        00000024  c0c34020  c0c34020  00a34020  2**2
                          CONTENTS, ALLOC, LOAD, READONLY, CODE
         15 .vectors      00000020  00000000  c0c35000  00a40000  2**1
                          CONTENTS, ALLOC, LOAD, READONLY, CODE
         16 .stubs        000002c0  00001000  c0c35020  00a41000  2**5
                          CONTENTS, ALLOC, LOAD, READONLY, CODE
         17 .init.text    0006b1b8  c0c352e0  c0c352e0  00a452e0  2**5
                          CONTENTS, ALLOC, LOAD, READONLY, CODE
         ...
      
        After:
        Idx Name          Size      VMA       LMA       File off  Algn
         ...
         14 .notes        00000024  c0c34020  c0c34020  00a34020  2**2
                          CONTENTS, ALLOC, LOAD, READONLY, CODE
         15 .vectors      00000020  ffff0000  c0c35000  00a40000  2**1
                          CONTENTS, ALLOC, LOAD, READONLY, CODE
         16 .stubs        000002c0  ffff1000  c0c35020  00a41000  2**5
                          CONTENTS, ALLOC, LOAD, READONLY, CODE
         17 .init.text    0006b1b8  c0c352e0  c0c352e0  00a452e0  2**5
                          CONTENTS, ALLOC, LOAD, READONLY, CODE
         ...
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Acked-by: NChris Brandt <chris.brandt@renesas.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      31b96cae
    • A
      ARM: 8514/1: remove duplicate definitions of __vectors_start and __stubs_start · b48da558
      Ard Biesheuvel 提交于
      Commit b9b32bf7 ("ARM: use linker magic for vectors and vector stubs")
      introduced new global definitions of __vectors_start and __stubs_start,
      and changed the existing ones to have internal linkage only. However, these
      symbols are still visible to kallsyms, and due to the way the .vectors and
      .stubs sections are emitted at the base of the VMA space, these duplicate
      definitions have conflicting values.
      
        $ nm -n vmlinux |grep -E __vectors|__stubs
        00000000 t __vectors_start
        00001000 t __stubs_start
        c0e77000 T __vectors_start
        c0e77020 T __stubs_start
      
      This is completely harmless by itself, since the wrong values are local
      symbols that cannot be referenced by other object files directly. However,
      since these symbols are also listed in the kallsyms symbol table in some
      cases (i.e., CONFIG_KALLSYMS_ALL=y and CONFIG_XIP_KERNEL=y), having these
      conflicting values can be confusing. So either remove them, or make them
      strictly local.
      Acked-by: NChris Brandt <chris.brandt@renesas.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b48da558
  9. 03 10月, 2015 1 次提交
    • R
      ARM: remove user cmpxchg syscall · db695c05
      Russell King 提交于
      Mark Brand reports that a NEEDS_SYSCALL_FOR_CMPXCHG enabled kernel would
      open a security hole in the ghost syscall used to implement cmpxchg, as
      it fails to validate the user pointer.
      
      However, in order for this option to be enabled, you'd need to be
      building a pre-ARMv6 kernel with SMP support.  There is only one system
      known which fits that, which is an early ARM SMP FPGA implementation
      based on the ARM926T.
      
      In any case, the Kconfig does not allow SMP to be enabled for pre-ARMv6
      systems.
      
      Moreover, even if NEEDS_SYSCALL_FOR_CMPXCHG were to be enabled, the
      kernel would not build as __ARM_NR_cmpxchg64 is not defined.
      
      The simple answer is to remove the buggy code.
      Reported-by: NMark Brand <markbrand@google.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      db695c05
  10. 27 8月, 2015 1 次提交
    • R
      ARM: entry: provide uaccess assembly macro hooks · 2190fed6
      Russell King 提交于
      Provide hooks into the kernel entry and exit paths to permit control
      of userspace visibility to the kernel.  The intended use is:
      
      - on entry to kernel from user, uaccess_disable will be called to
        disable userspace visibility
      - on exit from kernel to user, uaccess_enable will be called to
        enable userspace visibility
      - on entry from a kernel exception, uaccess_save_and_disable will be
        called to save the current userspace visibility setting, and disable
        access
      - on exit from a kernel exception, uaccess_restore will be called to
        restore the userspace visibility as it was before the exception
        occurred.
      
      These hooks allows us to keep userspace visibility disabled for the
      vast majority of the kernel, except for localised regions where we
      want to explicitly access userspace.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2190fed6
  11. 21 8月, 2015 1 次提交
    • R
      ARM: domains: switch to keeping domain value in register · 1eef5d2f
      Russell King 提交于
      Rather than modifying both the domain access control register and our
      per-thread copy, modify only the domain access control register, and
      use the per-thread copy to save and restore the register over context
      switches.  We can also avoid the explicit initialisation of the
      init thread_info structure.
      
      This allows us to avoid needing to gain access to the thread information
      at the uaccess control sites.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1eef5d2f
  12. 03 7月, 2015 1 次提交
    • R
      ARM: fix lockdep unannotated irqs-off warning · 11b8b25c
      Russell King 提交于
      Wolfram Sang reported an unannotated irqs-off warning from lockdep:
      
      WARNING: CPU: 0 PID: 282 at kernel/locking/lockdep.c:3557 check_flags+0x84/0x1f4()
      DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
      CPU: 0 PID: 282 Comm: rcS Tainted: G        W 4.1.0-00002-g5b076054611833 #179
      Hardware name: Generic Emma Mobile EV2 (Flattened Device Tree)
      Backtrace:
      [<c0012c94>] (dump_backtrace) from [<c0012e3c>] (show_stack+0x18/0x1c)
       r6:c02dcc67 r5:00000009 r4:00000000 r3:00400000
      [<c0012e24>] (show_stack) from [<c02510c8>] (dump_stack+0x20/0x28)
      [<c02510a8>] (dump_stack) from [<c0022c44>] (warn_slowpath_common+0x8c/0xb4)
      [<c0022bb8>] (warn_slowpath_common) from [<c0022cd8>] (warn_slowpath_fmt+0x38/0x40)
       r8:c780f470 r7:00000000 r6:00000000 r5:c03b0570 r4:c0b7ec04
      [<c0022ca4>] (warn_slowpath_fmt) from [<c004cd38>] (check_flags+0x84/0x1f4)
       r3:c02e13d8 r2:c02dceaa
      [<c004ccb4>] (check_flags) from [<c0050e50>] (lock_acquire+0x4c/0xbc)
       r5:00000000 r4:60000193
      [<c0050e04>] (lock_acquire) from [<c0256000>] (_raw_spin_lock+0x34/0x44)
       r9:000a8d5c r8:00000001 r7:c7806000 r6:c780f460 r5:c03b06a0 r4:c780f460
      [<c0255fcc>] (_raw_spin_lock) from [<c005a8cc>] (handle_fasteoi_irq+0x20/0x11c)
       r4:c780f400
      [<c005a8ac>] (handle_fasteoi_irq) from [<c0057a4c>] (generic_handle_irq+0x28/0x38)
       r6:00000000 r5:c03b038c r4:00000012 r3:c005a8ac
      [<c0057a24>] (generic_handle_irq) from [<c0057ae4>] (__handle_domain_irq+0x88/0xa8)
       r4:00000000 r3:00000026
      [<c0057a5c>] (__handle_domain_irq) from [<c000a3cc>] (gic_handle_irq+0x40/0x58)
       r8:10c5347d r7:10c5347d r6:c35b1fb0 r5:c03a6304 r4:c8802000 r3:c35b1fb0
      [<c000a38c>] (gic_handle_irq) from [<c0013bc8>] (__irq_usr+0x48/0x60)
      Exception stack(0xc35b1fb0 to 0xc35b1ff8)
      1fa0:                                     00000061 00000000 000ab736 00000066
      1fc0: 00000061 000aa1f0 000a8d54 000a8d54 000a8d88 000a8d5c 000a8cc8 000a8d68
      1fe0: 72727272 bef8a528 000398c0 00031334 20000010 ffffffff
       r6:ffffffff r5:20000010 r4:00031334 r3:00000061
      ---[ end trace cb88537fdc8fa202 ]---
      possible reason: unannotated irqs-off.
      irq event stamp: 769
      hardirqs last  enabled at (769): [<c000f82c>] ret_fast_syscall+0x2c/0x54
      hardirqs last disabled at (768): [<c000f80c>] ret_fast_syscall+0xc/0x54
      softirqs last  enabled at (0): [<c0020ec4>] copy_process.part.65+0x2e8/0x11dc
      softirqs last disabled at (0): [<  (null)>]   (null)
      
      His kernel configuration had:
      CONFIG_PROVE_LOCKING=y
      CONFIG_TRACE_IRQFLAGS=y
      but no IRQSOFF_TRACER, which means entry from userspace can result in the
      kernel seeing IRQs off without being notified of that change of state.
      Change the IRQSOFF ifdef in the usr_entry macro to TRACE_IRQFLAGS instead.
      Tested-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      11b8b25c
  13. 17 6月, 2015 1 次提交
  14. 09 5月, 2015 1 次提交
  15. 30 3月, 2015 1 次提交
  16. 14 1月, 2015 1 次提交
  17. 26 9月, 2014 1 次提交
  18. 18 9月, 2014 1 次提交
    • D
      ARM: 8150/3: fiq: Replace default FIQ handler · c0e7f7ee
      Daniel Thompson 提交于
      This patch introduces a new default FIQ handler that is structured in a
      similar way to the existing ARM exception handler and result in the FIQ
      being handled by C code running on the SVC stack (despite this code run
      in the FIQ handler is subject to severe limitations with respect to
      locking making normal interaction with the kernel impossible).
      
      This default handler allows concepts that on x86 would be handled using
      NMIs to be realized on ARM.
      
      Credit:
      
          This patch is a near complete re-write of a patch originally
          provided by Anton Vorontsov. Today only a couple of small fragments
          survive, however without Anton's work to build from this patch would
          not exist. Thanks also to Russell King for spoonfeeding me a variety
          of fixes during the review cycle.
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c0e7f7ee
  19. 18 7月, 2014 1 次提交
    • R
      ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+ · 6ebbf2ce
      Russell King 提交于
      ARMv6 and greater introduced a new instruction ("bx") which can be used
      to return from function calls.  Recent CPUs perform better when the
      "bx lr" instruction is used rather than the "mov pc, lr" instruction,
      and this sequence is strongly recommended to be used by the ARM
      architecture manual (section A.4.1.1).
      
      We provide a new macro "ret" with all its variants for the condition
      code which will resolve to the appropriate instruction.
      
      Rather than doing this piecemeal, and miss some instances, change all
      the "mov pc" instances to use the new macro, with the exception of
      the "movs" instruction and the kprobes code.  This allows us to detect
      the "mov pc, lr" case and fix it up - and also gives us the possibility
      of deploying this for other registers depending on the CPU selection.
      Reported-by: NWill Deacon <will.deacon@arm.com>
      Tested-by: Stephen Warren <swarren@nvidia.com> # Tegra Jetson TK1
      Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> # mioa701_bootresume.S
      Tested-by: Andrew Lunn <andrew@lunn.ch> # Kirkwood
      Tested-by: NShawn Guo <shawn.guo@freescale.com>
      Tested-by: Tony Lindgren <tony@atomide.com> # OMAPs
      Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> # Armada XP, 375, 385
      Acked-by: Sekhar Nori <nsekhar@ti.com> # DaVinci
      Acked-by: Christoffer Dall <christoffer.dall@linaro.org> # kvm/hyp
      Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> # PXA3xx
      Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> # Xen
      Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> # ARMv7M
      Tested-by: Simon Horman <horms+renesas@verge.net.au> # Shmobile
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6ebbf2ce
  20. 02 6月, 2014 2 次提交
  21. 30 5月, 2014 1 次提交
    • A
      ARM: 8062/1: Modify ldrt fixup handler to re-execute the userspace instruction · 3780f7ab
      Arun K S 提交于
      We will reach fixup handler when one thread(say cpu0) caused an undefined exception, while another thread(say cpu1) is unmmaping the page.
      
      Fixup handler returns to the next userspace instruction which has caused the undef execption, rather than going to the same instruction.
      
      ARM ARM says that after undefined exception, the PC will be pointing
      to the next instruction. ie +4 offset in case of ARM and +2 in case of Thumb
      
      And there is no correction offset passed to vector_stub in case of
      undef exception.
      
      File: arch/arm/kernel/entry-armv.S +1085
      vector_stub     und, UND_MODE
      
      During an undefined exception, in normal scenario(ie when ldrt
      instruction does not cause an abort) after resorting the context in
      VFP hardware, the PC is modified as show below before jumping to
      ret_from_exception which is in r9.
      
      File: arch/arm/vfp/vfphw.S +169
      @ The context stored in the VFP hardware is up to date with this thread
      vfp_hw_state_valid:
         tst     r1, #FPEXC_EX
         bne     process_exception     @ might as well handle the pending
                                       @ exception before retrying branch
                                       @ out before setting an FPEXC that
                                       @ stops us reading stuff
              VFPFMXR FPEXC, r1        @ Restore FPEXC last
              sub     r2, r2, #4       @ Retry current instruction - if Thumb
              str     r2, [sp, #S_PC]  @ mode it's two 16-bit instructions,
                                       @ else it's one 32-bit instruction, so
                                       @ always subtract 4 from the following
                                       @ instruction address.
      
      But if ldrt results in an abort, we reach the fixup handler and return
      to ret_from_execption without correcting the pc.
      
      This patch modifes the fixup handler to re-execute the same instruction which caused undefined execption.
      Signed-off-by: NVinayak Menon <vinayakm.list@gmail.com>
      Signed-off-by: NArun KS <getarunks@gmail.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3780f7ab
  22. 25 4月, 2014 1 次提交
  23. 28 1月, 2014 1 次提交
  24. 07 11月, 2013 1 次提交
  25. 20 10月, 2013 1 次提交
  26. 07 8月, 2013 1 次提交
    • R
      ARM: Fix !kuser helpers case · 1b16c4bc
      Russell King 提交于
      Fix yet another build failure caused by a weird set of configuration
      settings:
      
        LD      init/built-in.o
      arch/arm/kernel/built-in.o: In function `__dabt_usr':
      /home/tom3q/kernel/arch/arm/kernel/entry-armv.S:377: undefined reference to `kuser_cmpxchg64_fixup'
      arch/arm/kernel/built-in.o: In function `__irq_usr':
      /home/tom3q/kernel/arch/arm/kernel/entry-armv.S:387: undefined reference to `kuser_cmpxchg64_fixup'
      
      caused by:
      CONFIG_KUSER_HELPERS=n
      CONFIG_CPU_32v6K=n
      CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG=n
      Reported-by: NTomasz Figa <tomasz.figa@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1b16c4bc
  27. 01 8月, 2013 5 次提交
  28. 24 6月, 2013 1 次提交
  29. 04 4月, 2013 1 次提交
    • K
      ARM: 7688/1: add support for context tracking subsystem · b0088480
      Kevin Hilman 提交于
      commit 91d1aa43 (context_tracking: New context tracking susbsystem)
      generalized parts of the RCU userspace extended quiescent state into
      the context tracking subsystem.  Context tracking is then used
      to implement adaptive tickless (a.k.a extended nohz)
      
      To support the new context tracking subsystem on ARM, the user/kernel
      boundary transtions need to be instrumented.
      
      For exceptions and IRQs in usermode, the existing usr_entry macro is
      used to instrument the user->kernel transition.  For the return to
      usermode path, the ret_to_user* path is instrumented.  Using the
      usr_entry macro, this covers interrupts in userspace, data abort and
      prefetch abort exceptions in userspace as well as undefined exceptions
      in userspace (which is where FP emulation and VFP are handled.)
      
      For syscalls, the slow return path is covered by instrumenting the
      ret_to_user path.  In addition, the syscall entry point is
      instrumented which covers the user->kernel transition for both fast
      and slow syscalls, and an additional instrumentation point is added
      for the fast syscall return path (ret_fast_syscall).
      
      Cc: Mats Liljegren <mats.liljegren@enea.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b0088480
  30. 03 4月, 2013 2 次提交
  31. 24 2月, 2013 1 次提交
  32. 31 7月, 2012 1 次提交
    • R
      ARM: Fix undefined instruction exception handling · 15ac49b6
      Russell King 提交于
      While trying to get a v3.5 kernel booted on the cubox, I noticed that
      VFP does not work correctly with VFP bounce handling.  This is because
      of the confusion over 16-bit vs 32-bit instructions, and where PC is
      supposed to point to.
      
      The rule is that FP handlers are entered with regs->ARM_pc pointing at
      the _next_ instruction to be executed.  However, if the exception is
      not handled, regs->ARM_pc points at the faulting instruction.
      
      This is easy for ARM mode, because we know that the next instruction and
      previous instructions are separated by four bytes.  This is not true of
      Thumb2 though.
      
      Since all FP instructions are 32-bit in Thumb2, it makes things easy.
      We just need to select the appropriate adjustment.  Do this by moving
      the adjustment out of do_undefinstr() into the assembly code, as only
      the assembly code knows whether it's dealing with a 32-bit or 16-bit
      instruction.
      
      Cc: <stable@vger.kernel.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      15ac49b6