commit 45939ce292 upstream.
It is possible for a system with an ARMv8 timer to run a 32-bit kernel.
When this happens we will unconditionally have the vDSO code remove the
__vdso_gettimeofday and __vdso_clock_gettime symbols because
cntvct_functional() returns false since it does not match that
compatibility string.
Fixes: ecf99a4391 ("ARM: 8331/1: VDSO initialization, mapping, and synchronization")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 9db043d36b ]
arm64 has got relaxation on GIC version check at early boot stage due
to update of the GIC architecture let's align ARM with that.
To help backports (even though the code was correct at the time of writing)
Fixes: e59941b9b3 ("ARM: 8527/1: virt: enable GICv3 system registers")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ca70ea43f8 ]
MCPM does a soft reset of the CPUs and uses common cpu_resume() routine to
perform low-level platform initialization. This results in a try to install
HYP stubs for the second time for each CPU and results in false HYP/SVC
mode mismatch detection. The HYP stubs are already installed at the
beginning of the kernel initialization on the boot CPU (head.S) or in the
secondary_startup() for other CPUs. To fix this issue MCPM code should use
a cpu_resume() routine without HYP stubs installation.
This change fixes HYP/SVC mode mismatch on Samsung Exynos5422-based Odroid
XU3/XU4/HC1 boards.
Fixes: 3721924c81 ("ARM: 8081/1: MCPM: provide infrastructure to allow for MCPM loopback")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f18aef742c ]
On at least x86 and ARM64, and as documented in the ptrace man page
a skipped system call will still cause a syscall exit ptrace stop.
Previous to this commit 32-bit ARM did not, resulting in strace
being confused when seccomp skips system calls.
This change also impacts programs that use ptrace to skip system calls.
Fixes: ad75b51459 ("ARM: 7579/1: arch/allow a scno of -1 to not cause a SIGILL")
Signed-off-by: Timothy E Baldwin <T.E.Baldwin99@members.leeds.ac.uk>
Signed-off-by: Eugene Syromyatnikov <evgsyr@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Kees Cook <keescook@chromium.org>
Tested-by: Eugene Syromyatnikov <evgsyr@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PD#SWPL-12145
Problem:
When switch IRQ stack, there is a 16 bytes miss match of irq
stack. This may cause context not match some times;
Solution:
Save sp to right place
Verify:
X301
Change-Id: I75dfa5208cb3cec050c1568ac78ae2e783ca106b
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
PD#TV-9668
Problem:
After cpu idle enabled, watch point event register will be cleared
if cpu exit pm(idle). This will cause watch point can't work.
Solution:
re-enable watch point after cpu exit pm(idle)
Verify:
TL1
Change-Id: I4fc2002eaabecd4c5e60a5916bc29e0107882bec
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
PD#SWPL-13243
Problem:
pmu event is not accurate or not complete in A53/A55/A73.
Solution:
1, modify event config for A53/A55/A73.
2, perf executable file must compiled from latest kernel(5.1+)
3, A55 events are most complete, A73 are least complete(eg: less ld_retired/st_retired/stall/prefetch events)
4, A55/A53 same event meanings simlar, but A73 is more different(eg: L1/L2 dcache/icache loads meanings)
sample commands:
a55 arm64:
perf stat -e task-clock,context-switches,cpu-migrations,page-faults,instructions,armv8_pmuv3/ld_retired/,armv8_pmuv3/st_retired/,cycles,branch-loads,branch-load-misses,armv8_pmuv3/a55_l1d_cache_rd/,armv8_pmuv3/a55_l1d_cache_refill_rd/,armv8_pmuv3/a55_l1d_cache_wr/,armv8_pmuv3/a55_l1d_cache_refill_wr/,L1-icache-loads,L1-icache-load-misses,armv8_pmuv3/a55_l2d_cache_rd/,armv8_pmuv3/a55_l2d_cache_refill_rd/,armv8_pmuv3/a55_l1d_cache_refill_inner/,armv8_pmuv3/a55_l1d_cache_refill_outer/,armv8_pmuv3/a55_l1d_cache_refill_prefetch/,armv8_pmuv3/a55_l2d_cache_refill_prefetch/,armv8_pmuv3/a5x_stall_frontend_cache/,armv8_pmuv3/a5x_stall_frontend_tlb/,armv8_pmuv3/a5x_stall_backend_ld/,armv8_pmuv3/a55_stall_backend_ld_cache/,armv8_pmuv3/a55_stall_backend_ld_tlb/,armv8_pmuv3/a5x_stall_backend_st/,armv8_pmuv3/a5x_stall_backend_ilock_agu/,armv8_pmuv3/a5x_stall_backend_ilock_fpu/ ls
a53 arm64:
perf stat -e task-clock,context-switches,cpu-migrations,page-faults,instructions,armv8_pmuv3/ld_retired/,armv8_pmuv3/st_retired/,cycles,branch-loads,branch-load-misses,armv8_pmuv3/l1d_cache/,armv8_pmuv3/l1d_cache_refill/,L1-icache-loads,L1-icache-load-misses,armv8_pmuv3/a5x_l2d_cache/,armv8_pmuv3/a5x_l2d_cache_refill/,armv8_pmuv3/a53_cache_refill_prefetch/,armv8_pmuv3/a53_scu_snooped/,armv8_pmuv3/a5x_stall_frontend_cache/,armv8_pmuv3/a5x_stall_frontend_tlb/,armv8_pmuv3/a5x_stall_backend_ld/,,armv8_pmuv3/a5x_stall_backend_st/,armv8_pmuv3/a5x_stall_backend_ilock_agu/,armv8_pmuv3/a5x_stall_backend_ilock_fpu/ ls
a73 arm64: (w400 bind to a73 cpu2)
perf stat -e task-clock,context-switches,cpu-migrations,page-faults,instructions,cycles,branch-loads,branch-load-misses,armv8_pmuv3/l1d_cache/,armv8_pmuv3/l1d_cache_refill/,armv8_pmuv3/a55_l1d_cache_rd/,armv8_pmuv3/a55_l1d_cache_wr/,armv8_pmuv3/a5x_l2d_cache/,armv8_pmuv3/a5x_l2d_cache_refill/,armv8_pmuv3/a55_l2d_cache_rd/,armv8_pmuv3/a55_l2d_cache_wr/ busybox taskset 4 ls
a55 arm:
perf stat -e task-clock,context-switches,cpu-migrations,page-faults,instructions,armv7_cortex_a15/ld_retired/,armv7_cortex_a15/st_retired/,cycles,branch-loads,branch-load-misses,armv7_cortex_a15/a55_l1d_cache_rd/,armv7_cortex_a15/a55_l1d_cache_refill_rd/,armv7_cortex_a15/a55_l1d_cache_wr/,armv7_cortex_a15/a55_l1d_cache_refill_wr/,L1-icache-loads,L1-icache-load-misses,armv7_cortex_a15/a55_l2d_cache_rd/,armv7_cortex_a15/a55_l2d_cache_refill_rd/,armv7_cortex_a15/a55_l1d_cache_refill_inner/,armv7_cortex_a15/a55_l1d_cache_refill_outer/,armv7_cortex_a15/a55_l1d_cache_refill_prefetch/,armv7_cortex_a15/a55_l2d_cache_refill_prefetch/,armv7_cortex_a15/a5x_stall_frontend_cache/,armv7_cortex_a15/a5x_stall_frontend_tlb/,armv7_cortex_a15/a5x_stall_backend_ld/,armv7_cortex_a15/a55_stall_backend_ld_cache/,armv7_cortex_a15/a55_stall_backend_ld_tlb/,armv7_cortex_a15/a5x_stall_backend_st/,armv7_cortex_a15/a5x_stall_backend_ilock_agu/,armv7_cortex_a15/a5x_stall_backend_ilock_fpu/ ls
a53 arm:
perf stat -e task-clock,context-switches,cpu-migrations,page-faults,instructions,armv7_cortex_a15/ld_retired/,armv7_cortex_a15/st_retired/,cycles,branch-loads,branch-load-misses,armv7_cortex_a15/l1d_cache/,armv7_cortex_a15/l1d_cache_refill/,L1-icache-loads,L1-icache-load-misses,armv7_cortex_a15/a5x_l2d_cache/,armv7_cortex_a15/a5x_l2d_cache_refill/,armv7_cortex_a15/a53_cache_refill_prefetch/,armv7_cortex_a15/a53_scu_snooped/,armv7_cortex_a15/a5x_stall_frontend_cache/,armv7_cortex_a15/a5x_stall_frontend_tlb/,armv7_cortex_a15/a5x_stall_backend_ld/,armv7_cortex_a15/a5x_stall_backend_st/,armv7_cortex_a15/a5x_stall_backend_ilock_agu/,armv7_cortex_a15/a5x_stall_backend_ilock_fpu/ ls
a73 arm: (w400 bind to a73 cpu2)
perf stat -e task-clock,context-switches,cpu-migrations,page-faults,instructions,cycles,branch-loads,branch-load-misses,armv7_cortex_a15/l1d_cache/,armv7_cortex_a15/l1d_cache_refill/,armv7_cortex_a15/a55_l1d_cache_rd/,armv7_cortex_a15/a55_l1d_cache_wr/,armv7_cortex_a15/a5x_l2d_cache/,armv7_cortex_a15/a5x_l2d_cache_refill/,armv7_cortex_a15/a55_l2d_cache_rd/,armv7_cortex_a15/a55_l2d_cache_wr/ busybox taskset 4 ls
Verify:
ac200/u200/w400
Change-Id: I7f11e1480c3c27d016b011d2a84c33e824f69b08
Signed-off-by: Hanjie Lin <hanjie.lin@amlogic.com>
PD#SWPL-10141
Problem:
When open kasan with vmap stack on ARM32 platform, there
will be a panic issue which pc is running out of range:
[ 56.726530@2] PC is at 0x50
[ 56.729301@2] LR is at 0x0
Solution:
Close kasan when open vmap stack on ARM32
Verify:
TL1
Change-Id: Id82eb27543e8eade86b281cde9e160b8bf4e7878
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
PD#SWPL-7711
Problem:
Executing echo l > /proc/sysrq-trigger each 5 seconds for about
15 minius will trigger hardlockup
Solution:
Add more strict checking for show_regs to filter out addresses
in secure monitor region and ioremap region, deferencing which
triggers external abort on none-linefetch, and finally leading
to hardlockup
Verify:
Locally pass on U200
Change-Id: I6bd219e7dc3ad29904e6bd1b7d2f4cfb3928d8ed
Signed-off-by: Jiamin Ma <jiamin.ma@amlogic.com>
PD#SWPL-8132
Problem:
In Jira TV-5143, final fix change have increased 128MB address space
for vmalloc. Because binder wasted too many vmalloc space but it's
hard to fix it in kernel side.
Due to incease of vmalloc address space, old design of address space
layout for KASAN32 is not suitable after this change. So we need to
change memory layout to fix this problem and let KASAN can running OK
again.
Solution:
1, rebuild address space layout for kasan
2, make kasan compatible with vmap stack config
Verify:
p212
Change-Id: I2ce8a840df0ce1fcda61ebeb14a64b1d609719ca
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
PD#SWPL-7676
Problem:
If we open kasan on 32bit kernel, after resume we usually will
get a stack-out-of-bounds KASAN error report. But infact that's
a fake report. Because On arm architecture, cpu suspend/resume
routine is done in function call path:
cpu_suspend -> psci_cpu_suspend -> __invoke_psci_fn_smc
during this call path, some parts of stack will be marked as
shadow memory. But when cpu resume from smc call, it directly
return to point which saved in cpu_suspend and call resume
procedure. Which do not comeback as a reverse return path:
__invoke_psci_fn_smc -> psci_cpu_suspend -> cpu_suspend
So some residual shadow memory may affect KASAN report when
cpu is calling resume hooks.
Solution:
We just need to clear all shadow in stack for this case.
Verify:
p212
Change-Id: Ic6c877212240d03902b11184e54ac363455e0094
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
[ Upstream commit 143c2a89e0 ]
When running kprobe on -rt kernel, the below bug is caught:
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 128, pid: 14, name: migration/0
|Preemption disabled at:[<802f2b98>] cpu_stopper_thread+0xc0/0x140
|CPU: 0 PID: 14 Comm: migration/0 Tainted: G O 4.8.3-rt2 #1
|Hardware name: Freescale LS1021A
|[<8025a43c>] (___might_sleep)
|[<80b5b324>] (rt_spin_lock)
|[<80b5c31c>] (__patch_text_real)
|[<80b5c3ac>] (patch_text_stop_machine)
|[<802f2920>] (multi_cpu_stop)
Since patch_text_stop_machine() is called in stop_machine() which
disables IRQ, sleepable lock should be not used in this atomic context,
so replace patch_lock to raw lock.
Signed-off-by: Yang Shi <yang.shi@linaro.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PD#SWPL-7085
Problem:
Currently kasan can't be used on 32bit kernel, it's difficult to debug
memory problems;
Solution:
Bring up KASAN on 32bit kernel
Verify:
p212
Change-Id: I4d80568f023315994e969c79b786eba856177c9c
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
PD#SWPL-6837
Problem:
The return value of arch_counter_get_cntvct is always abnormal
when it is in irq stack. In this case, arch_counter_get_cntvct
trys to access a variable in 8Bytes via a 4Bytes aligned addr-
ess, which vialates the rule: The address that is accessed
should be aligned to the size of the data element being
accessed
Solution:
after switching to irq stack, force the base sp value to be
16Bytes aligned. Since the address of variable in irq stack is
based on the base sp and arranged automatically, all the data
accessing in irq stack will be aligned.
Verify:
Ampere
Change-Id: I3b30a56491dd0720d1c885bfaf2ca98d1b103fdd
Signed-off-by: Jiamin Ma <jiamin.ma@amlogic.com>
[ Upstream commit 5388a5b821 ]
machine_crash_nonpanic_core() does this:
while (1)
cpu_relax();
because the kernel has crashed, and we have no known safe way to deal
with the CPU. So, we place the CPU into an infinite loop which we
expect it to never exit - at least not until the system as a whole is
reset by some method.
In the absence of erratum 754327, this code assembles to:
b .
In other words, an infinite loop. When erratum 754327 is enabled,
this becomes:
1: dmb
b 1b
It has been observed that on some systems (eg, OMAP4) where, if a
crash is triggered, the system tries to kexec into the panic kernel,
but fails after taking the secondary CPU down - placing it into one
of these loops. This causes the system to livelock, and the most
noticable effect is the system stops after issuing:
Loading crashdump kernel...
to the system console.
The tested as working solution I came up with was to add wfe() to
these infinite loops thusly:
while (1) {
cpu_relax();
wfe();
}
which, without 754327 builds to:
1: wfe
b 1b
or with 754327 is enabled:
1: dmb
wfe
b 1b
Adding "wfe" does two things depending on the environment we're running
under:
- where we're running on bare metal, and the processor implements
"wfe", it stops us spinning endlessly in a loop where we're never
going to do any useful work.
- if we're running in a VM, it allows the CPU to be given back to the
hypervisor and rescheduled for other purposes (maybe a different VM)
rather than wasting CPU cycles inside a crashed VM.
However, in light of erratum 794072, Will Deacon wanted to see 10 nops
as well - which is reasonable to cover the case where we have erratum
754327 enabled _and_ we have a processor that doesn't implement the
wfe hint.
So, we now end up with:
1: wfe
b 1b
when erratum 754327 is disabled, or:
1: dmb
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
wfe
b 1b
when erratum 754327 is enabled. We also get the dmb + 10 nop
sequence elsewhere in the kernel, in terminating loops.
This is reasonable - it means we get the workaround for erratum
794072 when erratum 754327 is enabled, but still relinquish the dead
processor - either by placing it in a lower power mode when wfe is
implemented as such or by returning it to the hypervisior, or in the
case where wfe is a no-op, we use the workaround specified in erratum
794072 to avoid the problem.
These as two entirely orthogonal problems - the 10 nops addresses
erratum 794072, and the wfe is an optimisation that makes the system
more efficient when crashed either in terms of power consumption or
by allowing the host/other VMs to make use of the CPU.
I don't see any reason not to use kexec() inside a VM - it has the
potential to provide automated recovery from a failure of the VMs
kernel with the opportunity for saving a crashdump of the failure.
A panic() with a reboot timeout won't do that, and reading the
libvirt documentation, setting on_reboot to "preserve" won't either
(the documentation states "The preserve action for an on_reboot event
is treated as a destroy".) Surely it has to be a good thing to
avoiding having CPUs spinning inside a VM that is doing no useful
work.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 74ffe79ae5 ]
Mostly unwind is done with irqs enabled however SLUB may call it with
irqs disabled while creating a new SLUB cache.
I had system freeze while loading a module which called
kmem_cache_create() on init. That means SLUB's __slab_alloc() disabled
interrupts and then
->new_slab_objects()
->new_slab()
->setup_object()
->setup_object_debug()
->init_tracking()
->set_track()
->save_stack_trace()
->save_stack_trace_tsk()
->walk_stackframe()
->unwind_frame()
->unwind_find_idx()
=>spin_lock_irqsave(&unwind_lock);
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1b5ba35078 ]
Arm TC2 fails cpu hotplug stress test.
This issue was tracked down to a missing copy of the new affinity
cpumask for the vexpress-spc interrupt into struct
irq_common_data.affinity when the interrupt is migrated in
migrate_one_irq().
Fix it by replacing the arm specific hotplug cpu migration with the
generic irq code.
This is the counterpart implementation to commit 217d453d47 ("arm64:
fix a migrating irq bug when hotplug cpu").
Tested with cpu hotplug stress test on Arm TC2 (multi_v7_defconfig plus
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y and CONFIG_ARM_VEXPRESS_SPC_CPUFREQ=y).
The vexpress-spc interrupt (irq=22) on this board is affine to CPU0.
Its affinity cpumask now changes correctly e.g. from 0 to 1-4 when
CPU0 is hotplugged out.
Suggested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PD#SWPL-5564
Problem:
When open VMAP for kernel stack, if we meet kernel panic log, we
can't know physical address of stack and hard to debug.
Solution:
Print pfn for register in vmalloc range
Verify:
p212
Change-Id: Iee120df1feab88e412ef63e87c2e2bb4ad0645fb
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
[ Upstream commit afc9f65e01 ]
When building the kernel as Thumb-2 with binutils 2.29 or newer, if the
assembler has seen the .type directive (via ENDPROC()) for a symbol, it
automatically handles the setting of the lowest bit when the symbol is
used with ADR. The badr macro on the other hand handles this lowest bit
manually. This leads to a jump to a wrong address in the wrong state
in the syscall return path:
Internal error: Oops - undefined instruction: 0 [#2] SMP THUMB2
Modules linked in:
CPU: 0 PID: 652 Comm: modprobe Tainted: G D 4.18.0-rc3+ #8
PC is at ret_fast_syscall+0x4/0x62
LR is at sys_brk+0x109/0x128
pc : [<80101004>] lr : [<801c8a35>] psr: 60000013
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 50c5387d Table: 9e82006a DAC: 00000051
Process modprobe (pid: 652, stack limit = 0x(ptrval))
80101000 <ret_fast_syscall>:
80101000: b672 cpsid i
80101002: f8d9 2008 ldr.w r2, [r9, #8]
80101006: f1b2 4ffe cmp.w r2, #2130706432 ; 0x7f000000
80101184 <local_restart>:
80101184: f8d9 a000 ldr.w sl, [r9]
80101188: e92d 0030 stmdb sp!, {r4, r5}
8010118c: f01a 0ff0 tst.w sl, #240 ; 0xf0
80101190: d117 bne.n 801011c2 <__sys_trace>
80101192: 46ba mov sl, r7
80101194: f5ba 7fc8 cmp.w sl, #400 ; 0x190
80101198: bf28 it cs
8010119a: f04f 0a00 movcs.w sl, #0
8010119e: f3af 8014 nop.w {20}
801011a2: f2af 1ea2 subw lr, pc, #418 ; 0x1a2
To fix this, add a new symbol name which doesn't have ENDPROC used on it
and use that with badr. We can't remove the badr usage since that would
would cause breakage with older binutils.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PD#SWPL-4718
Problem:
Will have "PC=0, LR=0" issue when try to
show active cpu stacks via sysrq
Solution:
Save the addr of current interrupted task's context to the
interrupt stack first, so that we can easily obtain pt_regs
later
Verify:
Locally on Ampere
Change-Id: I1cc5095e0ec356bed90f76cdf9af1b2617ce7834
Signed-off-by: Jiamin Ma <jiamin.ma@amlogic.com>
PD#SWPL-4673
Problem:
userspace can't access perf monitor cnt with "mrc ... c9,c13,0"
Solution:
actually userspace should check perf monitor cnt access permissions first
before use, so this is a workround.
enable pmuserenr with "mcr ... c9,c14,0" in several places:
1, perf probe
2, cpu idle (state>0) exit
3, cpu online
4, system resume after suspend
Verify:
u212
Change-Id: Ib09682d1d47545dfef8b088283ddbbf390630d3e
Signed-off-by: Hanjie Lin <hanjie.lin@amlogic.com>
Commit 383fb3ee80 upstream.
In big.Little systems, some CPUs require the Spectre workarounds in
paths such as the context switch, but other CPUs do not. In order
to handle these differences, we need per-CPU vtables.
We are unable to use the kernel's per-CPU variables to support this
as per-CPU is not initialised at times when we need access to the
vtables, so we have to use an array indexed by logical CPU number.
We use an array-of-pointers to avoid having function pointers in
the kernel's read/write .data section.
Note: Added include of linux/slab.h in arch/arm/smp.c.
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David A. Long <dave.long@linaro.org>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Commit e209950fdd upstream.
Allow the way we access members of the processor vtable to be changed
at compile time. We will need to move to per-CPU vtables to fix the
Spectre variant 2 issues on big.Little systems.
However, we have a couple of calls that do not need the vtable
treatment, and indeed cause a kernel warning due to the (later) use
of smp_processor_id(), so also introduce the PROC_TABLE macro for
these which always use CPU 0's function pointers.
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David A. Long <dave.long@linaro.org>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Commit 65987a8553 upstream.
Split out the lookup of the processor type and associated error handling
from the rest of setup_processor() - we will need to use this in the
secondary CPU bringup path for big.Little Spectre variant 2 mitigation.
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David A. Long <dave.long@linaro.org>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Commit 3195089026 upstream.
Copy events to user using __copy_to_user() rather than copy members of
individually with __put_user_error().
This has the benefit of disabling/enabling PAN once per event intead of
once per event member.
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David A. Long <dave.long@linaro.org>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Commit 3aa2df6ec2 upstream.
Use __copy_to_user() rather than __put_user_error() for individual
members when saving VFP state.
This has the benefit of disabling/enabling PAN once per copied struct
intead of once per write.
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David A. Long <dave.long@linaro.org>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Commit 5ca451cf6e upstream.
When saving the ARM integer registers, use __copy_to_user() to
copy them into user signal frame, rather than __put_user_error().
This has the benefit of disabling/enabling PAN once for the whole copy
intead of once per write.
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David A. Long <dave.long@linaro.org>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 82c08c3e7f ]
In case panic() and panic() called at the same time on different CPUS.
For example:
CPU 0:
panic()
__crash_kexec
machine_crash_shutdown
crash_smp_send_stop
machine_kexec
BUG_ON(num_online_cpus() > 1);
CPU 1:
panic()
local_irq_disable
panic_smp_self_stop
If CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop(), kdump
fails. CPU1 can't receive the ipi irq, CPU1 will be always online.
To fix this problem, this patch split out the panic_smp_self_stop()
and add set_cpu_online(smp_processor_id(), false).
Signed-off-by: Yufen Wang <wangyufen@huawei.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PD#SWPL-4351
Problem:
Our cpu has 4 watch point on each cpu. It can be used for debug
purpose. But currently there is no driver support it.
Solution:
Bring up driver for it.
Verify:
p212
Change-Id: Ifbcb7f9b77e10fcb03b3c1a5e18f06b1a56ec2f0
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
PD#SWPL-2681
Problem:
Kernel stack usage is large when running many tasks.
Solution:
Map kernel stack to module space and handle page-fault
for stack fault. This can save about 50% memory of stack
usage
Verify:
p212
Change-Id: Ie894bc8f00cb525ddf8ac63c6d99d9c6e937fdc0
Signed-off-by: tao zeng <tao.zeng@amlogic.com>
PD#SWPL-3088
Problem:
g12b big-little cluster is different from other SoC with pmu
interrupts and registers.
software modifications must adapt to the difference.
Solution:
modify
Verify:
u200 w400
Change-Id: If9217c1025dff5c17d51790f8c216e31b7d6532b
Signed-off-by: Hanjie Lin <hanjie.lin@amlogic.com>
PD#SWPL-3316
Problem:
g12b/w400 has not sched-energy config in arm for EAS.
Solution:
port from arm64
Verify:
w400
Change-Id: I4f3ddd9d5f2abb9787ab95d6652db6cea1c54b24
Signed-off-by: Hanjie Lin <hanjie.lin@amlogic.com>
