- 20 10月, 2013 8 次提交
-
-
由 Ben Dooks 提交于
Currently BUG() uses .word or .hword to create the necessary illegal instructions. However if we are building BE8 then these get swapped by the linker into different illegal instructions in the text. This means that the BUG() macro does not get trapped properly. Change to using <asm/opcodes.h> to provide the necessary ARM instruction building as we cannot rely on gcc/gas having the `.inst` instructions which where added to try and resolve this issue (reported by Dave Martin <Dave.Martin@arm.com>). Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Reviewed-by: NDave Martin <Dave.Martin@arm.com>
-
由 Ben Dooks 提交于
When in BE8 mode, our instructions are not in the same ordering as the data, so use <asm/opcodes.h> to take this into account. Note, also requires modules to be built --be8 Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Reviewed-by: NDave Martin <Dave.Martin@arm.com>
-
由 Ben Dooks 提交于
The trap handler needs to take into account the endian configuration of the system when loading instructions. Use <asm/opcodes.h> to provide the necessary conversion functions. Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Ben Dooks 提交于
The smp_scu driver needs to use the relaxed readl/write accessors to avoid any issues with the endian mode the processor core is in. Reviewed-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
-
由 Ben Dooks 提交于
Ensure the twd driver uses the correct calls to access the hardware to ensure that we do not end up with data in the wrong endian format. Reviewed-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
-
由 Ben Dooks 提交于
If we are booting in LE and compiled for BE8, then add code to set the state to bE8. Since the instruction stream is always LE, we do not need to do anything special to the instruction. Also ensure that the secondary processors are started in the same mode. Note, we do add about 20 bytes to the kernel image, but it seems easier to do this than adding another configuration to change. Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Reviewed-by: NDave Martin <Dave.Martin@arm.com> Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Ben Dooks 提交于
The fixup_pv_table assumes that the instructions are in the same endian configuration as the data, but when the CPU is running in BE8 the instructions stay in little-endian format. Make sure if CONFIG_CPU_ENDIAN_BE8 is set that we do all the alterations to the instructions taking in to account the LDR/STR will be swapping the data endian-ness. Since the code is only modifying a byte, we avoid dual-swapping the data, and just change the bits we clear and ORR in (in the case where the code is not thumb2). For thumb2, we add the necessary rev16 instructions to ensure that the instructions are processed in the correct format, as it was easier than re-writing the code to contain a mask and shift. Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Reviewed-by: NDave Martin <Dave.Martin@arm.com> Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Ben Dooks 提交于
Add ARM_BE8() helper to wrap any code conditional on being compile when CONFIG_ARM_ENDIAN_BE8 is selected and convert existing places where this is to use it. Acked-by: NNicolas Pitre <nico@linaro.org> Reviewed-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
-
- 27 9月, 2013 1 次提交
-
-
由 Frederic Weisbecker 提交于
ad65782f (context_tracking: Optimize main APIs off case with static key) converted context tracking main APIs to inline function and left ARM asm callers behind. This can be easily fixed by making ARM calling the post static keys context tracking function. We just need to replicate the static key checks there. We'll remove these later when ARM will support the context tracking static keys. Reported-by: NGuenter Roeck <linux@roeck-us.net> Reported-by: NRussell King <linux@arm.linux.org.uk> Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com> Tested-by: NKevin Hilman <khilman@linaro.org> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: Anil Kumar <anilk4.v@gmail.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Russell King <linux@arm.linux.org.uk> Cc: Kevin Hilman <khilman@linaro.org>
-
- 22 9月, 2013 1 次提交
-
-
由 Will Deacon 提交于
Commit 377747c4 ("ARM: entry: allow ARM-private syscalls to be restarted") reworked the low-level syscall dispatcher to allow restarting of ARM-private syscalls. Unfortunately, this relocated the label used to dispatch a private syscall from the trace path, so that the invocation would be bypassed altogether! This causes applications to fail under strace as soon as they rely on a private syscall (e.g. set_tls): set_tls(0xb6fad4c0, 0xb6fadb98, 0xb6fb1050, 0xb6fad4c0, 0xb6fb1050) = -1 ENOSYS (Function not implemented) This patch fixes the label so that we correctly dispatch private syscalls from the trace path. Reported-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com> Tested-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 02 9月, 2013 3 次提交
-
-
由 Will Deacon 提交于
Now that we support a timer-backed delay loop, I'm quickly getting sick and tired of people complaining that their beloved bogomips value has decreased. You know who you are! This patch removes the bogomips line from /proc/cpuinfo, based on the reasoning that any program parsing this is already broken and, as such, won't be further broken if the field is removed. Acked-by: NNicolas Pitre <nico@linaro.org> Acked-by: NMarc Zyngier <marc.zyngier@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Douglas Anderson 提交于
It appears that gcc may put some code in ".text.unlikely" or ".text.hot" sections. Right now those aren't accounted for in unwind tables. Add them. I found some docs about this at: http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc.pdf Without this, if you have slub_debug turned on, you can get messages that look like this: unwind: Index not found 7f008c50 Signed-off-by: NDoug Anderson <dianders@chromium.org> Acked-by: NMike Frysinger <vapier@gentoo.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Uwe Kleine-König 提交于
The newly introduced function is to be used as .restart callback for ARMv7-M machines. The used register is architecturally defined, so it should work for all M-class machines. Acked-by: NJonathan Austin <jonathan.austin@arm.com> Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 21 8月, 2013 2 次提交
-
-
由 Sudeep KarkadaNagesha 提交于
Currently the topology code computes cpu capacity and stores it in the list along with hwid(which is MPIDR) as it parses the CPU nodes in the device tree. This is required as it needs to be mapped to the logical CPU later. Since the CPU device nodes can be retrieved in the logical ordering using DT/OF helpers, its possible to store cpu_capacity also in logical ordering and avoid storing hwid for each entry. This patch removes hwid by making use of of_get_cpu_node. Cc: Russell King <linux@arm.linux.org.uk> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: NRob Herring <rob.herring@calxeda.com> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
-
由 Sudeep KarkadaNagesha 提交于
OF/DT core library now provides architecture specific hook to match the logical cpu index with the corresponding physical identifier. Most of the cpu DT node parsing and initialisation is contained in devtree.c. So it's better to define ARM specific arch_match_cpu_phys_id there. This mainly helps to avoid replication of the code doing CPU node parsing and physical(MPIDR) to logical mapping. Cc: Russell King <linux@arm.linux.org.uk> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: NRob Herring <rob.herring@calxeda.com> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
-
- 20 8月, 2013 5 次提交
-
-
由 Will Deacon 提交于
do_cache_op finds the lowest VMA contained in the specified address range and rounds the range to cover only the mapped addresses. Since commit 4542b6a0 ("ARM: 7365/1: drop unused parameter from flush_cache_user_range") the VMA is not used for anything else in this code and seeing as the low-level cache flushing routines return -EFAULT if the address is not valid, there is no need for this range truncation. This patch removes the VMA handling code from the cacheflushing syscall. Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Will Deacon 提交于
Flushing a large, non-faulting VMA from userspace can potentially result in a long time spent flushing the cache line-by-line without preemption occurring (in the case of CONFIG_PREEMPT=n). Whilst this doesn't affect the stability of the system, it can certainly affect the responsiveness and CPU availability for other tasks. This patch splits up the user cacheflush code so that it flushes in chunks of a page. After each chunk has been flushed, we may reschedule if appropriate and, before processing the next chunk, we allow any pending signals to be handled before resuming from where we left off. Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Vijaya Kumar K 提交于
In case of normal kexec kernel load, all cpu's are offlined before calling machine_kexec().But in case crash panic cpus are relaxed in machine_crash_nonpanic_core() SMP function but not offlined. When crash kernel is loaded with kexec and on panic trigger machine_kexec() checks for number of cpus online. If more than one cpu is online machine_kexec() fails to load with below error kexec: error: multiple CPUs still online In machine_crash_nonpanic_core() SMP function, offline CPU before cpu_relax Signed-off-by: NVijaya Kumar K <Vijaya.Kumar@caviumnetworks.com> Acked-by: NStephen Warren <swarren@wwwdotorg.org> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Thomas Gleixner 提交于
PMU interrupts must not be threaded. Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Fabio Estevam 提交于
Commit 2ba85e7a (ARM: Fix FIQ code on VIVT CPUs) causes the following build warning: arch/arm/kernel/fiq.c:92:3: warning: passing argument 1 of 'cpu_cache.coherent_kern_range' makes integer from pointer without a cast [enabled by default] Cast it as '(unsigned long)base' to avoid the warning. Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 14 8月, 2013 4 次提交
-
-
由 Stephen Boyd 提交于
Fix constraint check in armpmu_map_hw_event(). Reported-and-tested-by: NVince Weaver <vincent.weaver@maine.edu> Cc: <stable@kernel.org> Signed-off-by: NIngo Molnar <mingo@kernel.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Stephen Warren 提交于
Architectures should fully validate whether kexec is possible as part of machine_kexec_prepare(), so that user-space's kexec_load() operation can report any problems. Performing validation in machine_kexec() itself is too late, since it is not allowed to return. Prior to this patch, ARM's machine_kexec() was testing after-the-fact whether machine_kexec_prepare() was able to disable all but one CPU. Instead, modify machine_kexec_prepare() to validate all conditions necessary for machine_kexec_prepare()'s to succeed. BUG if the validation succeeded, yet disabling the CPUs didn't actually work. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Stephen Boyd 提交于
Vince Weaver reports an oops in the ARM perf event code while running his perf_fuzzer tool on a pandaboard running v3.11-rc4. Unable to handle kernel paging request at virtual address 73fd14cc pgd = eca6c000 [73fd14cc] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: snd_soc_omap_hdmi omapdss snd_soc_omap_abe_twl6040 snd_soc_twl6040 snd_soc_omap snd_soc_omap_hdmi_card snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi snd_pcm snd_page_alloc snd_timer snd soundcore CPU: 1 PID: 2790 Comm: perf_fuzzer Not tainted 3.11.0-rc4 #6 task: eddcab80 ti: ed892000 task.ti: ed892000 PC is at armpmu_map_event+0x20/0x88 LR is at armpmu_event_init+0x38/0x280 pc : [<c001c3e4>] lr : [<c001c17c>] psr: 60000013 sp : ed893e40 ip : ecececec fp : edfaec00 r10: 00000000 r9 : 00000000 r8 : ed8c3ac0 r7 : ed8c3b5c r6 : edfaec00 r5 : 00000000 r4 : 00000000 r3 : 000000ff r2 : c0496144 r1 : c049611c r0 : edfaec00 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: aca6c04a DAC: 00000015 Process perf_fuzzer (pid: 2790, stack limit = 0xed892240) Stack: (0xed893e40 to 0xed894000) 3e40: 00000800 c001c17c 00000002 c008a748 00000001 00000000 00000000 c00bf078 3e60: 00000000 edfaee50 00000000 00000000 00000000 edfaec00 ed8c3ac0 edfaec00 3e80: 00000000 c073ffac ed893f20 c00bf180 00000001 00000000 c00bf078 ed893f20 3ea0: 00000000 ed8c3ac0 00000000 00000000 00000000 c0cb0818 eddcab80 c00bf440 3ec0: ed893f20 00000000 eddcab80 eca76800 00000000 eca76800 00000000 00000000 3ee0: 00000000 ec984c80 eddcab80 c00bfe68 00000000 00000000 00000000 00000080 3f00: 00000000 ed892000 00000000 ed892030 00000004 ecc7e3c8 ecc7e3c8 00000000 3f20: 00000000 00000048 ecececec 00000000 00000000 00000000 00000000 00000000 3f40: 00000000 00000000 00297810 00000000 00000000 00000000 00000000 00000000 3f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3f80: 00000002 00000002 000103a4 00000002 0000016c c00128e8 ed892000 00000000 3fa0: 00090998 c0012700 00000002 000103a4 00090ab8 00000000 00000000 0000000f 3fc0: 00000002 000103a4 00000002 0000016c 00090ab0 00090ab8 000107a0 00090998 3fe0: bed92be0 bed92bd0 0000b785 b6e8f6d0 40000010 00090ab8 00000000 00000000 [<c001c3e4>] (armpmu_map_event+0x20/0x88) from [<c001c17c>] (armpmu_event_init+0x38/0x280) [<c001c17c>] (armpmu_event_init+0x38/0x280) from [<c00bf180>] (perf_init_event+0x108/0x180) [<c00bf180>] (perf_init_event+0x108/0x180) from [<c00bf440>] (perf_event_alloc+0x248/0x40c) [<c00bf440>] (perf_event_alloc+0x248/0x40c) from [<c00bfe68>] (SyS_perf_event_open+0x4f4/0x8fc) [<c00bfe68>] (SyS_perf_event_open+0x4f4/0x8fc) from [<c0012700>] (ret_fast_syscall+0x0/0x48) Code: 0a000005 e3540004 0a000016 e3540000 (0791010c) This is because event->attr.config in armpmu_event_init() contains a very large number copied directly from userspace and is never checked against the size of the array indexed in armpmu_map_hw_event(). Fix the problem by checking the value of config before indexing the array and rejecting invalid config values. Reported-by: NVince Weaver <vincent.weaver@maine.edu> Tested-by: NVince Weaver <vincent.weaver@maine.edu> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Will Deacon 提交于
It is possible to construct an event group with a software event as a group leader and then subsequently add a hardware event to the group. This results in the event group being validated by adding all members of the group to a fake PMU and attempting to allocate each event on their respective PMU. Unfortunately, for software events wthout a corresponding arm_pmu, this results in a kernel crash attempting to dereference the ->get_event_idx function pointer. This patch fixes the problem by checking explicitly for software events and ignoring those in event validation (since they can always be scheduled). We will probably want to revisit this for 3.12, since the validation checks don't appear to work correctly when dealing with multiple hardware PMUs anyway. Cc: <stable@vger.kernel.org> Reported-by: NVince Weaver <vincent.weaver@maine.edu> Tested-by: NVince Weaver <vincent.weaver@maine.edu> Tested-by: NMark Rutland <mark.rutland@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 12 8月, 2013 3 次提交
-
-
由 Thomas Petazzoni 提交于
Some PCI drivers may need to adjust the pci_bus structure after it has been allocated by the Linux PCI core. The PCI core allows architectures to implement the pcibios_add_bus() and pcibios_remove_bus() for this purpose. This commit therefore extends the hw_pci and pci_sys_data structures of the ARM PCI core to allow PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci, which will get called when a bus is added or removed from the system. This will be used for example by the Marvell PCIe driver to connect a particular PCI bus with its corresponding MSI chip to handle Message Signaled Interrupts. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: NThierry Reding <thierry.reding@gmail.com> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NDaniel Price <daniel.price@gmail.com> Tested-by: NThierry Reding <thierry.reding@gmail.com> Signed-off-by: NJason Cooper <jason@lakedaemon.net>
-
由 Will Deacon 提交于
Now that the ASID allocator doesn't require inner-shareable maintenance, we can convert the local_bp_flush_all function to perform only non-shareable flushing, in a similar manner to the TLB invalidation routines. Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Will Deacon 提交于
Inner-shareable TLB invalidation is typically more expensive than local (non-shareable) invalidation, so performing the broadcasting for local_flush_tlb_* operations is a waste of cycles and needlessly clobbers entries in the TLBs of other CPUs. This patch introduces __flush_tlb_* versions for many of the TLB invalidation functions, which only respect inner-shareable variants of the invalidation instructions when presented with the TLB_V7_UIS_FULL flag. The local version is also inlined to prevent SMP_ON_UP kernels from missing flushes, where the __flush variant would be called with the UP flags. This gains us around 0.5% in hackbench scores for a dual-core A15, but I would expect this to improve as more cores (and clusters) are added to the equation. Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com> Reported-by: NAlbin Tonnerre <Albin.Tonnerre@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
- 08 8月, 2013 1 次提交
-
-
由 Russell King 提交于
Aaro Koskinen reports the following oops: Installing fiq handler from c001b110, length 0x164 Unable to handle kernel paging request at virtual address ffff1224 pgd = c0004000 [ffff1224] *pgd=00000000, *pte=11fff0cb, *ppte=11fff00a ... [<c0013154>] (set_fiq_handler+0x0/0x6c) from [<c0365d38>] (ams_delta_init_fiq+0xa8/0x160) r6:00000164 r5:c001b110 r4:00000000 r3:fefecb4c [<c0365c90>] (ams_delta_init_fiq+0x0/0x160) from [<c0365b14>] (ams_delta_init+0xd4/0x114) r6:00000000 r5:fffece10 r4:c037a9e0 [<c0365a40>] (ams_delta_init+0x0/0x114) from [<c03613b4>] (customize_machine+0x24/0x30) This is because the vectors page is now write-protected, and to change code in there we must write to its original alias. Make that change, and adjust the cache flushing such that the code will become visible to the instruction stream on VIVT CPUs. Reported-by: NAaro Koskinen <aaro.koskinen@iki.fi> Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 07 8月, 2013 2 次提交
-
-
由 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>
-
由 Russell King 提交于
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 03 8月, 2013 2 次提交
-
-
由 Russell King 提交于
Olof reports that noMMU builds error out with: arch/arm/kernel/signal.c: In function 'setup_return': arch/arm/kernel/signal.c:413:25: error: 'mm_context_t' has no member named 'sigpage' This shows one of the evilnesses of IS_ENABLED(). Get rid of it here and replace it with #ifdef's - and as no noMMU platform can make use of sigpage, depend on CONIFG_MMU not CONFIG_ARM_MPU. Reported-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Unfortunately, I never committed the fix to a nasty oops which can occur as a result of that commit: ------------[ cut here ]------------ kernel BUG at /home/olof/work/batch/include/linux/mm.h:414! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 490 Comm: killall5 Not tainted 3.11.0-rc3-00288-gabe03080 #53 task: e90acac0 ti: e9be8000 task.ti: e9be8000 PC is at special_mapping_fault+0xa4/0xc4 LR is at __do_fault+0x68/0x48c This doesn't show up unless you do quite a bit of testing; a simple boot test does not do this, so all my nightly tests were passing fine. The reason for this is that install_special_mapping() expects the page array to stick around, and as this was only inserting one page which was stored on the kernel stack, that's why this was blowing up. Reported-by: NOlof Johansson <olof@lixom.net> Tested-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 8月, 2013 8 次提交
-
-
由 Russell King 提交于
Commit 8bd26e3a (arm: delete __cpuinit/__CPUINIT usage from all ARM users) caused some code to leak into sections which are discarded through the removal of __CPUINIT annotations. Add appropriate .text annotations to bring these back into the kernel text. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Stephen Boyd 提交于
If one process calls sys_reboot and that process then stops other CPUs while those CPUs are within a spin_lock() region we can potentially encounter a deadlock scenario like below. CPU 0 CPU 1 ----- ----- spin_lock(my_lock) smp_send_stop() <send IPI> handle_IPI() disable_preemption/irqs while(1); <PREEMPT> spin_lock(my_lock) <--- Waits forever We shouldn't attempt to run any other tasks after we send a stop IPI to a CPU so disable preemption so that this task runs to completion. We use local_irq_disable() here for cross-arch consistency with x86. Reported-by: NSundarajan Srinivasan <sundaraj@codeaurora.com> Signed-off-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
If kuser helpers are not provided by the kernel, disable user access to the vectors page. With the kuser helpers gone, there is no reason for this page to be visible to userspace. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Move the signal handlers into a VDSO page rather than keeping them in the vectors page. This allows us to place them randomly within this page, and also map the page at a random location within userspace further protecting these code fragments from ROP attacks. The new VDSO page is also poisoned in the same way as the vector page. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Provide a kernel configuration option to allow the kernel user helpers to be removed from the vector page, thereby preventing their use with ROP (return orientated programming) attacks. This option is only visible for CPU architectures which natively support all the operations which kernel user helpers would normally provide, and must be enabled with caution. Cc: <stable@vger.kernel.org> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
FIQ should no longer copy the FIQ code into the user visible vector page. Instead, it should use the hidden page. This change makes that happen. Cc: <stable@vger.kernel.org> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Use linker magic to create the vectors and vector stubs: we can tell the linker to place them at an appropriate VMA, but keep the LMA within the kernel. This gets rid of some unnecessary symbol manipulation, and have the linker calculate the relocations appropriately. Cc: <stable@vger.kernel.org> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Move the machine vector stubs into the page above the vector page, which we can prevent from being visible to userspace. Also move the reset stub, and place the swi vector at a location that the 'ldr' can get to it. This hides pointers into the kernel which could give valuable information to attackers, and reduces the number of exploitable instructions at a fixed address. Cc: <stable@vger.kernel.org> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-