Jason,
Could you please review my patch below?
See also arm64 maintainer's comment:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313712.h…
Thanks,
-Takahiro AKASHI
I tried to verify kgdb in vanilla kernel on fast model, but it seems that
the single stepping with kgdb doesn't work correctly since its first
appearance at v3.15.
On v3.15, 'stepi' command after breaking the kernel at some breakpoint
steps forward to the next instruction, but the succeeding 'stepi' never
goes beyond that.
On v3.16, 'stepi' moves forward and stops at the next instruction just
after enable_dbg in el1_dbg, and never goes beyond that. This variance of
behavior seems to come in with the following patch in v3.16:
commit 2a2830703a23 ("arm64: debug: avoid accessing mdscr_el1 on fault
paths where possible")
This patch
(1) moves kgdb_disable_single_step() from 'c' command handling to single
step handler.
This makes sure that single stepping gets effective at every 's' command.
Please note that, under the current implementation, single step bit in
spsr, which is cleared by the first single stepping, will not be set
again for the consecutive 's' commands because single step bit in mdscr
is still kept on (that is, kernel_active_single_step() in
kgdb_arch_handle_exception() is true).
(2) re-implements kgdb_roundup_cpus() because the current implementation
enabled interrupts naively. See below.
(3) removes 'enable_dbg' in el1_dbg.
Single step bit in mdscr is turned on in do_handle_exception()->
kgdb_handle_expection() before returning to debugged context, and if
debug exception is enabled in el1_dbg, we will see unexpected single-
stepping in el1_dbg.
Since v3.18, the following patch does the same:
commit 1059c6bf8534 ("arm64: debug: don't re-enable debug exceptions
on return from el1_dbg)
(4) masks interrupts while single-stepping one instruction.
If an interrupt is caught during processing a single-stepping, debug
exception is unintentionally enabled by el1_irq's 'enable_dbg' before
returning to debugged context.
Thus, like in (2), we will see unexpected single-stepping in el1_irq.
Basically (1) and (2) are for v3.15, (3) and (4) for v3.1[67].
* issue fixed by (2):
Without (2), we would see another problem if a breakpoint is set at
interrupt-sensible places, like gic_handle_irq():
KGDB: re-enter error: breakpoint removed ffffffc000081258
------------[ cut here ]------------
WARNING: CPU: 0 PID: 650 at kernel/debug/debug_core.c:435
kgdb_handle_exception+0x1dc/0x1f4()
Modules linked in:
CPU: 0 PID: 650 Comm: sh Not tainted 3.17.0-rc2+ #177
Call trace:
[<ffffffc000087fac>] dump_backtrace+0x0/0x130
[<ffffffc0000880ec>] show_stack+0x10/0x1c
[<ffffffc0004d683c>] dump_stack+0x74/0xb8
[<ffffffc0000ab824>] warn_slowpath_common+0x8c/0xb4
[<ffffffc0000ab90c>] warn_slowpath_null+0x14/0x20
[<ffffffc000121bfc>] kgdb_handle_exception+0x1d8/0x1f4
[<ffffffc000092ffc>] kgdb_brk_fn+0x18/0x28
[<ffffffc0000821c8>] brk_handler+0x9c/0xe8
[<ffffffc0000811e8>] do_debug_exception+0x3c/0xac
Exception stack(0xffffffc07e027650 to 0xffffffc07e027770)
...
[<ffffffc000083cac>] el1_dbg+0x14/0x68
[<ffffffc00012178c>] kgdb_cpu_enter+0x464/0x5c0
[<ffffffc000121bb4>] kgdb_handle_exception+0x190/0x1f4
[<ffffffc000092ffc>] kgdb_brk_fn+0x18/0x28
[<ffffffc0000821c8>] brk_handler+0x9c/0xe8
[<ffffffc0000811e8>] do_debug_exception+0x3c/0xac
Exception stack(0xffffffc07e027ac0 to 0xffffffc07e027be0)
...
[<ffffffc000083cac>] el1_dbg+0x14/0x68
[<ffffffc00032e4b4>] __handle_sysrq+0x11c/0x190
[<ffffffc00032e93c>] write_sysrq_trigger+0x4c/0x60
[<ffffffc0001e7d58>] proc_reg_write+0x54/0x84
[<ffffffc000192fa4>] vfs_write+0x98/0x1c8
[<ffffffc0001939b0>] SyS_write+0x40/0xa0
Once some interrupt occurs, a breakpoint at gic_handle_irq() triggers kgdb.
Kgdb then calls kgdb_roundup_cpus() to sync with other cpus.
Current kgdb_roundup_cpus() unmasks interrupts temporarily to
use smp_call_function().
This eventually allows another interrupt to occur and likely results in
hitting a breakpoint at gic_handle_irq() again since debug exception is
always enabled in el1_irq.
We can avoid this issue by specifying "nokgdbroundup" in kernel parameter,
but this will also leave other cpus be in unknown state in terms of kgdb,
and may result in interfering with kgdb activity.
Signed-off-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org>
---
arch/arm64/kernel/kgdb.c | 60 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 46 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index a0d10c5..81b5910 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -19,9 +19,13 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/cpumask.h>
#include <linux/irq.h>
+#include <linux/irq_work.h>
#include <linux/kdebug.h>
#include <linux/kgdb.h>
+#include <linux/percpu.h>
+#include <asm/ptrace.h>
#include <asm/traps.h>
struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
@@ -95,6 +99,9 @@ struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
{ "fpcr", 4, -1 },
};
+static DEFINE_PER_CPU(unsigned int, kgdb_pstate);
+static DEFINE_PER_CPU(struct irq_work, kgdb_irq_work);
+
char *dbg_get_reg(int regno, void *mem, struct pt_regs *regs)
{
if (regno >= DBG_MAX_REG_NUM || regno < 0)
@@ -176,18 +183,14 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
* over and over again.
*/
kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
- atomic_set(&kgdb_cpu_doing_single_step, -1);
- kgdb_single_step = 0;
-
- /*
- * Received continue command, disable single step
- */
- if (kernel_active_single_step())
- kernel_disable_single_step();
err = 0;
break;
case 's':
+ /* mask interrupts while single stepping */
+ __this_cpu_write(kgdb_pstate, linux_regs->pstate);
+ linux_regs->pstate |= PSR_I_BIT;
+
/*
* Update step address value with address passed
* with step packet.
@@ -198,8 +201,6 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
*/
kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
atomic_set(&kgdb_cpu_doing_single_step, raw_smp_processor_id());
- kgdb_single_step = 1;
-
/*
* Enable single step handling
*/
@@ -229,6 +230,18 @@ static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int esr)
static int kgdb_step_brk_fn(struct pt_regs *regs, unsigned int esr)
{
+ unsigned int pstate;
+
+ kernel_disable_single_step();
+ atomic_set(&kgdb_cpu_doing_single_step, -1);
+
+ /* restore interrupt mask status */
+ pstate = __this_cpu_read(kgdb_pstate);
+ if (pstate & PSR_I_BIT)
+ regs->pstate |= PSR_I_BIT;
+ else
+ regs->pstate &= ~PSR_I_BIT;
+
kgdb_handle_exception(1, SIGTRAP, 0, regs);
return 0;
}
@@ -249,16 +262,27 @@ static struct step_hook kgdb_step_hook = {
.fn = kgdb_step_brk_fn
};
-static void kgdb_call_nmi_hook(void *ignored)
+static void kgdb_roundup_hook(struct irq_work *work)
{
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
void kgdb_roundup_cpus(unsigned long flags)
{
- local_irq_enable();
- smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
+ int cpu;
+ struct cpumask mask;
+ struct irq_work *work;
+
+ mask = *cpu_online_mask;
+ cpumask_clear_cpu(smp_processor_id(), &mask);
+ cpu = cpumask_first(&mask);
+ if (cpu >= nr_cpu_ids)
+ return;
+
+ for_each_cpu(cpu, &mask) {
+ work = per_cpu_ptr(&kgdb_irq_work, cpu);
+ irq_work_queue_on(work, cpu);
+ }
}
static int __kgdb_notify(struct die_args *args, unsigned long cmd)
@@ -299,6 +323,8 @@ static struct notifier_block kgdb_notifier = {
int kgdb_arch_init(void)
{
int ret = register_die_notifier(&kgdb_notifier);
+ int cpu;
+ struct irq_work *work;
if (ret != 0)
return ret;
@@ -306,6 +332,12 @@ int kgdb_arch_init(void)
register_break_hook(&kgdb_brkpt_hook);
register_break_hook(&kgdb_compiled_brkpt_hook);
register_step_hook(&kgdb_step_hook);
+
+ for_each_possible_cpu(cpu) {
+ work = per_cpu_ptr(&kgdb_irq_work, cpu);
+ init_irq_work(work, kgdb_roundup_hook);
+ }
+
return 0;
}
--
1.7.9.5
This patchset modifies the GIC driver to allow it, on supported
platforms, to route IPI interrupts to FIQ. It then uses this
feature to implement arch_trigger_all_cpu_backtrace for arm.
In order to neatly deliver the changes for the arm we also
rearrange some of the existing x86 NMI code to make it architecture
neutral.
The patches have been runtime tested on both a system capable of
supporting FIQ (Freescale i.MX6) and one that cannot (Qualcomm
Snapdragon 600). In addition older versions of this patchset
have been tested on STiH416 and vexpress-a9. The changes to the x86
logic were tested using qemu.
v21:
* Change the way SGIs are raised to try to increase robustness starting
secondary cores. This is a theoretic fix for a regression reported
by Mark Rutland on vexpress-tc2 but it also allows us to remove
igroup0_shadow entirely since it is no longer needed.
* Fix a couple of variable names and add comments to describe the
hardware behavior better (Mark Rutland).
* Improved MULTI_IRQ_HANDLER support by clearing FIQs using
handle_arch_irq (Marc Zygnier).
* Fix gic_cpu_if_down() to ensure group 1 interrupts are disabled
then the interface is brought down.
For changes in v20 and earlier see:
http://thread.gmane.org/gmane.linux.kernel/1928465
Daniel Thompson (6):
irqchip: gic: Optimize locking in gic_raise_softirq
irqchip: gic: Make gic_raise_softirq FIQ-safe
irqchip: gic: Introduce plumbing for IPI FIQ
printk: Simple implementation for NMI backtracing
x86/nmi: Use common printk functions
ARM: Add support for on-demand backtrace of other CPUs
arch/arm/Kconfig | 1 +
arch/arm/include/asm/hardirq.h | 2 +-
arch/arm/include/asm/irq.h | 5 +
arch/arm/include/asm/smp.h | 3 +
arch/arm/kernel/smp.c | 82 +++++++++++++++
arch/arm/kernel/traps.c | 13 ++-
arch/x86/Kconfig | 1 +
arch/x86/kernel/apic/hw_nmi.c | 104 ++-----------------
drivers/irqchip/irq-gic.c | 220 +++++++++++++++++++++++++++++++++++++---
include/linux/irqchip/arm-gic.h | 6 ++
include/linux/printk.h | 20 ++++
init/Kconfig | 3 +
kernel/printk/Makefile | 1 +
kernel/printk/nmi_backtrace.c | 147 +++++++++++++++++++++++++++
14 files changed, 495 insertions(+), 113 deletions(-)
create mode 100644 kernel/printk/nmi_backtrace.c
--
2.4.3
Hi Rafael/Preeti,
This is another attempt to fix the crashes reported by Preeti. They work
quite well for me now, and I hope they would work well for Preeti as
well :)
So, patches [1-7,9] are already Reviewed by Preeti.
The first 5 patches are minor cleanups, 6th & 7th try to optimize few
things to make code less complex.
Patches 8-10 actually solve (or try to solve :)) the synchronization
problems, or the crashes I was getting.
V1->V2:
- 7/11 is dropped and only 8/11 is updated, which is 8/10 now.
- Avoid taking the same mutex in both cpufreq_governor_dbs() and
work-handler as that has given us some locdeps, classic ABBA stuff.
- And so timer_mutex, responsible for synchronizing governor
work-handlers is kept as is.
- Later patches are almost same with minor updates.
- Invalid state-transitions are sensed better now with improved checks.
- I have run enough tests on my exynos dual core board and failed to
crash at all. Not that I wanted to crash :)
Rebased over pm/bleeeding-edge.
Viresh Kumar (10):
cpufreq: governor: Name delayed-work as dwork
cpufreq: governor: Drop unused field 'cpu'
cpufreq: governor: Rename 'cpu_dbs_common_info' to 'cpu_dbs_info'
cpufreq: governor: name pointer to cpu_dbs_info as 'cdbs'
cpufreq: governor: rename cur_policy as policy
cpufreq: governor: Keep single copy of information common to
policy->cpus
cpufreq: governor: split out common part of {cs|od}_dbs_timer()
cpufreq: governor: Avoid invalid states with additional checks
cpufreq: governor: Don't WARN on invalid states
cpufreq: propagate errors returned from __cpufreq_governor()
drivers/cpufreq/cpufreq.c | 22 ++--
drivers/cpufreq/cpufreq_conservative.c | 25 ++---
drivers/cpufreq/cpufreq_governor.c | 196 ++++++++++++++++++++++++---------
drivers/cpufreq/cpufreq_governor.h | 40 ++++---
drivers/cpufreq/cpufreq_ondemand.c | 67 ++++++-----
5 files changed, 220 insertions(+), 130 deletions(-)
--
2.4.0
This patch was initially intended to address a KVM issue described in
Geoff's kexec patch set[1]. But now the title of patch#1 would be more
suitable for the entire code as it was overhauled and, since the 4th
version, the fix is implemented as kvm cpu hotplug after Mark's comment.
I confirmed that it works with kexec under the following scenarios:
- boot 1st kernel
- run a guest OS
- (stop a guest OS)
- reboot 2nd kernel by kexec
- run a guest OS
test target: MediaTek MT8173-EVB
version: kernel v4.0-rc1 + Geoff's kexec v8 + Ard's patch[2]
But I didn't test other complicated scenarios with cpu hotplug.
On arm, Frediano[3] is no longer working on this issue as he left his
company. So patch#1 also has a stub definition for arm.
Changes from v4:
* restructured the patchset as cpu_init_hyp_mode() and kvm_cpu_reset() were
renamed to kvm_arch_hardware_{enable,disable}() respectively
* omitted some obvious arguments from __cpu_reset_hyp_mode().
Changes from v3:
* modified to use kvm cpu hotplug framework directly instead of reboot
notifier hook
Changes from v2:
* modified kvm_virt_to_trampoline() macro to fix a page-alignment issue[4]
Changes from v1:
* modified kvm_cpu_reset() implementation:
- define a macro to translate va to addr in trampoline
- use __hyp_default_vectors instead of kvm_get_hyp_stub_vectors()
- shuffle the arguments in __cpu_reset_hyp_mode()
- optimize TLB flush operations
* changed a patch#2's name
* added a patch#5 to add stub code for arm
[1] http://lists.infradead.org/pipermail/kexec/2015-April/335533.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/334002.html
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/322231.…
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/334910.html
AKASHI Takahiro (2):
arm64: kvm: allows kvm cpu hotplug
arm64: kvm: remove !KEXEC dependency
arch/arm/include/asm/kvm_host.h | 10 ++++++-
arch/arm/include/asm/kvm_mmu.h | 1 +
arch/arm/kvm/arm.c | 58 ++++++++++++-------------------------
arch/arm/kvm/mmu.c | 5 ++++
arch/arm64/include/asm/kvm_host.h | 11 ++++++-
arch/arm64/include/asm/kvm_mmu.h | 1 +
arch/arm64/include/asm/virt.h | 9 ++++++
arch/arm64/kvm/Kconfig | 1 -
arch/arm64/kvm/hyp-init.S | 33 +++++++++++++++++++++
arch/arm64/kvm/hyp.S | 32 +++++++++++++++++---
10 files changed, 114 insertions(+), 47 deletions(-)
--
1.7.9.5
Hi Rafael,
This series fixes few more possible race conditions. Over that there is
some non-trivial cleanup, in order to simplify code.
Preeti did review some of them before she left and shared concerns on
others, all that is sorted out now.
V1->V2:
- Dropped 2/10 from V1 as it wasn't required
- 3/10 saw some changes due to above patch being dropped
- 7/10 changed a bit as we check for pending work items by looking at
shared->policy, rather than calling delayed_work_pending. We wanted to
check if governor is operational or not and the new check is enough
for that.
Viresh Kumar (9):
cpufreq: Use __func__ to print function's name
cpufreq: conservative: remove 'enable' field
cpufreq: ondemand: only queue canceled works from
update_sampling_rate()
cpufreq: governor: Drop __gov_queue_work()
cpufreq: ondemand: Drop unnecessary locks from update_sampling_rate()
cpufreq: ondemand: queue work for policy->cpus together
cpufreq: ondemand: update sampling rate immidiately
cpufreq: governor: Quit work-handlers early if governor is stopped
cpufreq: Get rid of ->governor_enabled and its lock
drivers/cpufreq/cpufreq.c | 27 +----------
drivers/cpufreq/cpufreq_conservative.c | 38 +++++++++------
drivers/cpufreq/cpufreq_governor.c | 86 +++++++++++++++-------------------
drivers/cpufreq/cpufreq_governor.h | 5 +-
drivers/cpufreq/cpufreq_ondemand.c | 54 +++++++--------------
include/linux/cpufreq.h | 1 -
6 files changed, 81 insertions(+), 130 deletions(-)
--
2.4.0
When the context tracking feature was backported to 3.14 LSK,
setting of the LR was moved out of the main body of el0_sync
and into the applicable sub handlers (i.e. el0_da, el0_sp_pc,
etc). The el0_dbg handler was overlooked. The implication
is that do_debug_exception() will attempt to return directly
to userspace without going through the ret_from_exception
path. This ultimately results in another sync exception due
to a protection fault on the target PC.
This was introduced by:
commit 333625b7586d2753a77f32e1f898ab7cc6cf7655
Author: Larry Bassel <larry.bassel(a)linaro.org>
Date: Wed Oct 15 15:15:56 2014 -0700
arm64: adjust el0_sync so that a function can be called
Backport of the following patch to 3.14 LSK:
commit 6ab6463aeb5fbc75fa3227befb508fc33b34dbf1
Author: Larry Bassel <larry.bassel(a)linaro.org>
Date: Fri May 30 20:34:14 2014 +0100
Change-Id: Idadbecffb34326ff197e223abba90c6e50e0bf8d
---
arch/arm64/kernel/entry.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index a010e3a..2175d7b 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -526,6 +526,7 @@ el0_dbg:
disable_step x1
mov x1, x25
mov x2, sp
+ adr lr, ret_from_exception
b do_debug_exception
el0_inv:
ct_user_exit
--
2.1.0
Eduardo,
Radivoje and Punit asked me to look into a patch Radivoje has posted
recently and that got me to fix few things. It doesn't do anything
related to what Radivoje had in his patch though.
Viresh Kumar (6):
thermal/cpu_cooling: No need to initialize max_freq to 0
thermal/cpu_cooling: quit early after updating policy
thermal/cpu_cooling: convert 'switch' block to 'if' block in notifier
thermal/cpu_cooling: rename cpufreq_val as clipped_freq
thermal/cpu_cooling: rename max_freq as clipped_freq in notifier
thermal/cpu_cooling: update policy limits if clipped_freq <
policy->max
drivers/thermal/cpu_cooling.c | 46 ++++++++++++++++++++++++-------------------
1 file changed, 26 insertions(+), 20 deletions(-)
--
2.4.0