* [PATCH 1/1] arm64: Correcting format specifier for printing 64 bit addresses
From: Robin Murphy @ 2016-12-06 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206161116.GD4816@cbox>
On 06/12/16 16:11, Christoffer Dall wrote:
> On Mon, Dec 05, 2016 at 01:39:53PM +0530, Maninder Singh wrote:
>> This patch corrects format specifier for printing 64 bit addresses.
>>
>> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
>> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
>> ---
>> arch/arm64/kernel/signal.c | 2 +-
>> arch/arm64/kvm/sys_regs.c | 8 ++++++--
>> arch/arm64/mm/fault.c | 15 ++++++++++-----
>> arch/arm64/mm/mmu.c | 4 ++--
>> 4 files changed, 19 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
>> index c7b6de6..c89d5fd 100644
>> --- a/arch/arm64/kernel/signal.c
>> +++ b/arch/arm64/kernel/signal.c
>> @@ -155,7 +155,7 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
>>
>> badframe:
>> if (show_unhandled_signals)
>> - pr_info_ratelimited("%s[%d]: bad frame in %s: pc=%08llx sp=%08llx\n",
>> + pr_info_ratelimited("%s[%d]: bad frame in %s: pc=%016llx sp=%016llx\n",
>> current->comm, task_pid_nr(current), __func__,
>> regs->pc, regs->sp);
>> force_sig(SIGSEGV, current);
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 87e7e66..89bf5c1 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -1554,8 +1554,12 @@ static void unhandled_cp_access(struct kvm_vcpu *vcpu,
>> WARN_ON(1);
>> }
>>
>> - kvm_err("Unsupported guest CP%d access at: %08lx\n",
>> - cp, *vcpu_pc(vcpu));
>> + if (params->is_32bit)
>> + kvm_err("Unsupported guest CP%d access at: %08lx\n",
>> + cp, *vcpu_pc(vcpu));
>> + else
>> + kvm_err("Unsupported guest CP%d access at: %016lx\n",
>> + cp, *vcpu_pc(vcpu));
>
> It feels a bit much to me to have an if-statement to differentiate the
> number of leading zeros, so if it's important to always have fixed
> widths then I would just use %016lx in both cases.
Actually, it looks like vsnprintf does support the '*' field width
specifier, so even if the format _is_ critical there's still no reason
to have such duplicated code.
Robin.
>> print_sys_reg_instr(params);
>> kvm_inject_undefined(vcpu);
>> }
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index a78a5c4..d96a42a 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -77,7 +77,7 @@ void show_pte(struct mm_struct *mm, unsigned long addr)
>>
>> pr_alert("pgd = %p\n", mm->pgd);
>> pgd = pgd_offset(mm, addr);
>> - pr_alert("[%08lx] *pgd=%016llx", addr, pgd_val(*pgd));
>> + pr_alert("[%016lx] *pgd=%016llx", addr, pgd_val(*pgd));
>>
>> do {
>> pud_t *pud;
>> @@ -177,7 +177,7 @@ static void __do_kernel_fault(struct mm_struct *mm, unsigned long addr,
>> * No handler, we'll have to terminate things with extreme prejudice.
>> */
>> bust_spinlocks(1);
>> - pr_alert("Unable to handle kernel %s at virtual address %08lx\n",
>> + pr_alert("Unable to handle kernel %s at virtual address %016lx\n",
>> (addr < PAGE_SIZE) ? "NULL pointer dereference" :
>> "paging request", addr);
>>
>> @@ -198,9 +198,14 @@ static void __do_user_fault(struct task_struct *tsk, unsigned long addr,
>> struct siginfo si;
>>
>> if (unhandled_signal(tsk, sig) && show_unhandled_signals_ratelimited()) {
>> - pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
>> - tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
>> - addr, esr);
>> + if (compat_user_mode(regs))
>> + pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
>> + tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
>> + addr, esr);
>> + else
>> + pr_info("%s[%d]: unhandled %s (%d) at 0x%016lx, esr 0x%03x\n",
>> + tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
>> + addr, esr);
>
> same here.
>
> Thanks,
> -Christoffer
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v2] arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the guest
From: Will Deacon @ 2016-12-06 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206162918.GE4816@cbox>
On Tue, Dec 06, 2016 at 05:29:18PM +0100, Christoffer Dall wrote:
> On Tue, Dec 06, 2016 at 02:56:50PM +0000, Marc Zyngier wrote:
> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> > index 83037cd..3b7cfbd 100644
> > --- a/arch/arm64/kvm/hyp/switch.c
> > +++ b/arch/arm64/kvm/hyp/switch.c
> > @@ -85,7 +85,13 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
> > write_sysreg(val, hcr_el2);
> > /* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
> > write_sysreg(1 << 15, hstr_el2);
> > - /* Make sure we trap PMU access from EL0 to EL2 */
> > + /*
> > + * Make sure we trap PMU access from EL0 to EL2. Also sanitize
> > + * PMSELR_EL0 to make sure it never contains the cycle
> > + * counter, which could make a PMXEVCNTR_EL0 access UNDEF.
> > + */
> > + if (vcpu->arch.mdcr_el2 & MDCR_EL2_HPMN_MASK)
> > + write_sysreg(0, pmselr_el0);
>
> I'm a bit confused about how we use the HPMN field. This value is
> always set to the full number of counters available on the system and
> never modified by the guest, right? So this is in essence a check that
> says 'do you have any performance counters, then make sure accesses
> don't undef to el1 instead of trapping to el2', but then my question is,
> why not just set pmselr_el0 to zero unconditionally, because in the case
> where (vcpu->arch.mdcr_el2 & MDCR_EL2_HPMN_MASK) == 0, it means we have
> no counters, which we'll have exposed to the guest anyhow, and we should
> undef at el1 in the guest, or did I get this completely wrong (like
> everything else today)?
I think Marc and I came to the same conclusion a few minutes ago. The check
you might want is "Have I instantiated a virtual PMU for this device?",
but that's probably a micro-optimisation.
Will
^ permalink raw reply
* [RFC PATCH] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Dave Martin @ 2016-12-06 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481038740-11633-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Dec 06, 2016 at 03:39:00PM +0000, Ard Biesheuvel wrote:
> Currently, we allow kernel mode NEON in softirq or hardirq context by
> stacking and unstacking a slice of the NEON register file for each call
> to kernel_neon_begin() and kernel_neon_end(), respectively.
>
> Given that
> a) a CPU typically spends most of its time in userland, during which time
> no kernel mode NEON in process context is in progress,
> b) a CPU spends most of its time in the kernel doing other things than
> kernel mode NEON when it gets interrupted to perform kernel mode NEON
> in softirq context
>
> the stacking and subsequent unstacking is only necessary if we are
> interrupting a thread while it is performing kernel mode NEON in process
> context, which means that in all other cases, we can simply preserve the
> userland FPSIMD state once, and only restore it upon return to userland,
> even if we are being invoked from softirq or hardirq context.
>
> So instead of checking whether we are running in interrupt context, keep
> track of the level of nested kernel mode NEON calls in progress, and only
> perform the eager stack/unstack of the level exceeds 1.
Looks reasonable, and this does avoid treating SVE as a special case.
Later on, we may want to enable SVE use in the kernel too, in which case
kernel_neon_{begin,end}_partial() and fpsimd_partial_state will need
more changes -- but we don't need to address that right now.
Minor comments below.
Cheers
---Dave
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/kernel/fpsimd.c | 40 +++++++++++++++++++++++++++-------------
> 1 file changed, 27 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 394c61db5566..2614a216ac5d 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -220,20 +220,31 @@ void fpsimd_flush_task_state(struct task_struct *t)
>
> #ifdef CONFIG_KERNEL_MODE_NEON
>
> -static DEFINE_PER_CPU(struct fpsimd_partial_state, hardirq_fpsimdstate);
> -static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
> +/*
> + * Although unlikely, it is possible for three kernel mode NEON contexts to
> + * be live at the same time: process context, softirq context and hardirq
> + * context. So while the userland context is stashed in the thread's fpsimd
> + * state structure, we need two additional levels of storage.
> + */
> +static DEFINE_PER_CPU(struct fpsimd_partial_state, nested_fpsimdstate[2]);
> +static DEFINE_PER_CPU(int, kernel_neon_nesting_level);
>
> /*
> * Kernel-side NEON support functions
> */
> void kernel_neon_begin_partial(u32 num_regs)
> {
> - if (in_interrupt()) {
> - struct fpsimd_partial_state *s = this_cpu_ptr(
> - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> + struct fpsimd_partial_state *s;
> + int level;
> +
> + preempt_disable();
> +
> + level = this_cpu_read(kernel_neon_nesting_level);
> + if (level > 0) {
> + s = this_cpu_ptr(nested_fpsimdstate);
>
> BUG_ON(num_regs > 32);
> - fpsimd_save_partial_state(s, roundup(num_regs, 2));
> + fpsimd_save_partial_state(&s[level - 1], roundup(num_regs, 2));
> } else {
> /*
> * Save the userland FPSIMD state if we have one and if we
> @@ -241,24 +252,27 @@ void kernel_neon_begin_partial(u32 num_regs)
> * that there is no longer userland FPSIMD state in the
> * registers.
> */
> - preempt_disable();
> if (current->mm &&
> !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> fpsimd_save_state(¤t->thread.fpsimd_state);
> this_cpu_write(fpsimd_last_state, NULL);
> }
> + this_cpu_write(kernel_neon_nesting_level, level + 1);
Should we BUG_ON overflow/underflow of the nesting level? That Should
Not Happen (tm), but we'll make a mess if it does.
For the underflow case, perhaps DEBUG_PREEMPT is adequate for detecting
this via preempt count underflow.
> }
> EXPORT_SYMBOL(kernel_neon_begin_partial);
>
> void kernel_neon_end(void)
> {
> - if (in_interrupt()) {
> - struct fpsimd_partial_state *s = this_cpu_ptr(
> - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> - fpsimd_load_partial_state(s);
> - } else {
> - preempt_enable();
> + struct fpsimd_partial_state *s;
> + int level;
> +
> + level = this_cpu_read(kernel_neon_nesting_level);
> + if (level > 1) {
> + s = this_cpu_ptr(nested_fpsimdstate);
> + fpsimd_load_partial_state(&s[level - 2]);
> }
> + this_cpu_write(kernel_neon_nesting_level, level - 1);
> + preempt_enable();
> }
> EXPORT_SYMBOL(kernel_neon_end);
>
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1] arm64: Correcting format specifier for printing 64 bit addresses
From: Robin Murphy @ 2016-12-06 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480925393-8386-1-git-send-email-maninder1.s@samsung.com>
On 05/12/16 08:09, Maninder Singh wrote:
> This patch corrects format specifier for printing 64 bit addresses.
>
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> ---
> arch/arm64/kernel/signal.c | 2 +-
> arch/arm64/kvm/sys_regs.c | 8 ++++++--
> arch/arm64/mm/fault.c | 15 ++++++++++-----
> arch/arm64/mm/mmu.c | 4 ++--
> 4 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index c7b6de6..c89d5fd 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -155,7 +155,7 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
>
> badframe:
> if (show_unhandled_signals)
> - pr_info_ratelimited("%s[%d]: bad frame in %s: pc=%08llx sp=%08llx\n",
> + pr_info_ratelimited("%s[%d]: bad frame in %s: pc=%016llx sp=%016llx\n",
> current->comm, task_pid_nr(current), __func__,
> regs->pc, regs->sp);
> force_sig(SIGSEGV, current);
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 87e7e66..89bf5c1 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1554,8 +1554,12 @@ static void unhandled_cp_access(struct kvm_vcpu *vcpu,
> WARN_ON(1);
> }
>
> - kvm_err("Unsupported guest CP%d access at: %08lx\n",
> - cp, *vcpu_pc(vcpu));
> + if (params->is_32bit)
> + kvm_err("Unsupported guest CP%d access at: %08lx\n",
> + cp, *vcpu_pc(vcpu));
> + else
> + kvm_err("Unsupported guest CP%d access at: %016lx\n",
> + cp, *vcpu_pc(vcpu));
As with the other patch - use '%0*lx' in these cases rather than
pointlessly duplicating everything.
Robin.
> print_sys_reg_instr(params);
> kvm_inject_undefined(vcpu);
> }
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index a78a5c4..d96a42a 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -77,7 +77,7 @@ void show_pte(struct mm_struct *mm, unsigned long addr)
>
> pr_alert("pgd = %p\n", mm->pgd);
> pgd = pgd_offset(mm, addr);
> - pr_alert("[%08lx] *pgd=%016llx", addr, pgd_val(*pgd));
> + pr_alert("[%016lx] *pgd=%016llx", addr, pgd_val(*pgd));
>
> do {
> pud_t *pud;
> @@ -177,7 +177,7 @@ static void __do_kernel_fault(struct mm_struct *mm, unsigned long addr,
> * No handler, we'll have to terminate things with extreme prejudice.
> */
> bust_spinlocks(1);
> - pr_alert("Unable to handle kernel %s at virtual address %08lx\n",
> + pr_alert("Unable to handle kernel %s at virtual address %016lx\n",
> (addr < PAGE_SIZE) ? "NULL pointer dereference" :
> "paging request", addr);
>
> @@ -198,9 +198,14 @@ static void __do_user_fault(struct task_struct *tsk, unsigned long addr,
> struct siginfo si;
>
> if (unhandled_signal(tsk, sig) && show_unhandled_signals_ratelimited()) {
> - pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
> - tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
> - addr, esr);
> + if (compat_user_mode(regs))
> + pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
> + tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
> + addr, esr);
> + else
> + pr_info("%s[%d]: unhandled %s (%d) at 0x%016lx, esr 0x%03x\n",
> + tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
> + addr, esr);
> show_pte(tsk->mm, addr);
> show_regs(regs);
> }
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 17243e4..cbf444c 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -683,9 +683,9 @@ void __init early_fixmap_init(void)
> pr_warn("pmd %p != %p, %p\n",
> pmd, fixmap_pmd(fix_to_virt(FIX_BTMAP_BEGIN)),
> fixmap_pmd(fix_to_virt(FIX_BTMAP_END)));
> - pr_warn("fix_to_virt(FIX_BTMAP_BEGIN): %08lx\n",
> + pr_warn("fix_to_virt(FIX_BTMAP_BEGIN): %016lx\n",
> fix_to_virt(FIX_BTMAP_BEGIN));
> - pr_warn("fix_to_virt(FIX_BTMAP_END): %08lx\n",
> + pr_warn("fix_to_virt(FIX_BTMAP_END): %016lx\n",
> fix_to_virt(FIX_BTMAP_END));
>
> pr_warn("FIX_BTMAP_END: %d\n", FIX_BTMAP_END);
>
^ permalink raw reply
* [RFC PATCH] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Ard Biesheuvel @ 2016-12-06 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206164317.GX1574@e103592.cambridge.arm.com>
On 6 December 2016 at 16:43, Dave Martin <Dave.Martin@arm.com> wrote:
> On Tue, Dec 06, 2016 at 03:39:00PM +0000, Ard Biesheuvel wrote:
>> Currently, we allow kernel mode NEON in softirq or hardirq context by
>> stacking and unstacking a slice of the NEON register file for each call
>> to kernel_neon_begin() and kernel_neon_end(), respectively.
>>
>> Given that
>> a) a CPU typically spends most of its time in userland, during which time
>> no kernel mode NEON in process context is in progress,
>> b) a CPU spends most of its time in the kernel doing other things than
>> kernel mode NEON when it gets interrupted to perform kernel mode NEON
>> in softirq context
>>
>> the stacking and subsequent unstacking is only necessary if we are
>> interrupting a thread while it is performing kernel mode NEON in process
>> context, which means that in all other cases, we can simply preserve the
>> userland FPSIMD state once, and only restore it upon return to userland,
>> even if we are being invoked from softirq or hardirq context.
>>
>> So instead of checking whether we are running in interrupt context, keep
>> track of the level of nested kernel mode NEON calls in progress, and only
>> perform the eager stack/unstack of the level exceeds 1.
>
> Looks reasonable, and this does avoid treating SVE as a special case.
>
> Later on, we may want to enable SVE use in the kernel too, in which case
> kernel_neon_{begin,end}_partial() and fpsimd_partial_state will need
> more changes -- but we don't need to address that right now.
>
> Minor comments below.
>
> Cheers
> ---Dave
>
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> arch/arm64/kernel/fpsimd.c | 40 +++++++++++++++++++++++++++-------------
>> 1 file changed, 27 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
>> index 394c61db5566..2614a216ac5d 100644
>> --- a/arch/arm64/kernel/fpsimd.c
>> +++ b/arch/arm64/kernel/fpsimd.c
>> @@ -220,20 +220,31 @@ void fpsimd_flush_task_state(struct task_struct *t)
>>
>> #ifdef CONFIG_KERNEL_MODE_NEON
>>
>> -static DEFINE_PER_CPU(struct fpsimd_partial_state, hardirq_fpsimdstate);
>> -static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
>> +/*
>> + * Although unlikely, it is possible for three kernel mode NEON contexts to
>> + * be live at the same time: process context, softirq context and hardirq
>> + * context. So while the userland context is stashed in the thread's fpsimd
>> + * state structure, we need two additional levels of storage.
>> + */
>> +static DEFINE_PER_CPU(struct fpsimd_partial_state, nested_fpsimdstate[2]);
>> +static DEFINE_PER_CPU(int, kernel_neon_nesting_level);
>>
>> /*
>> * Kernel-side NEON support functions
>> */
>> void kernel_neon_begin_partial(u32 num_regs)
>> {
>> - if (in_interrupt()) {
>> - struct fpsimd_partial_state *s = this_cpu_ptr(
>> - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
>> + struct fpsimd_partial_state *s;
>> + int level;
>> +
>> + preempt_disable();
>> +
>> + level = this_cpu_read(kernel_neon_nesting_level);
>> + if (level > 0) {
>> + s = this_cpu_ptr(nested_fpsimdstate);
>>
>> BUG_ON(num_regs > 32);
>> - fpsimd_save_partial_state(s, roundup(num_regs, 2));
>> + fpsimd_save_partial_state(&s[level - 1], roundup(num_regs, 2));
>> } else {
>> /*
>> * Save the userland FPSIMD state if we have one and if we
>> @@ -241,24 +252,27 @@ void kernel_neon_begin_partial(u32 num_regs)
>> * that there is no longer userland FPSIMD state in the
>> * registers.
>> */
>> - preempt_disable();
>> if (current->mm &&
>> !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
>> fpsimd_save_state(¤t->thread.fpsimd_state);
>> this_cpu_write(fpsimd_last_state, NULL);
>> }
>> + this_cpu_write(kernel_neon_nesting_level, level + 1);
>
> Should we BUG_ON overflow/underflow of the nesting level? That Should
> Not Happen (tm), but we'll make a mess if it does.
>
True.
> For the underflow case, perhaps DEBUG_PREEMPT is adequate for detecting
> this via preempt count underflow.
>
I think it makes sense for the increment to check for overflow and the
decrement to check for underflow, regardless of whether DEBUG_PREEMPT
(or just PREEMPT) is enabled or not.
>> }
>> EXPORT_SYMBOL(kernel_neon_begin_partial);
>>
>> void kernel_neon_end(void)
>> {
>> - if (in_interrupt()) {
>> - struct fpsimd_partial_state *s = this_cpu_ptr(
>> - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
>> - fpsimd_load_partial_state(s);
>> - } else {
>> - preempt_enable();
>> + struct fpsimd_partial_state *s;
>> + int level;
>> +
>> + level = this_cpu_read(kernel_neon_nesting_level);
>> + if (level > 1) {
>> + s = this_cpu_ptr(nested_fpsimdstate);
>> + fpsimd_load_partial_state(&s[level - 2]);
>> }
>> + this_cpu_write(kernel_neon_nesting_level, level - 1);
>> + preempt_enable();
>> }
>> EXPORT_SYMBOL(kernel_neon_end);
>>
>> --
>> 2.7.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Kevin Hilman @ 2016-12-06 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4747860.QGGHSuFRpz@avalon>
Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:
> Hi Kevin,
>
> Thank you for the patch.
>
> On Tuesday 29 Nov 2016 15:57:09 Kevin Hilman wrote:
>> Video capture subdevs may be over I2C and may sleep during xfer, so we
>> cannot do IRQ-disabled locking when calling the subdev.
>>
>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>> ---
>> drivers/media/platform/davinci/vpif_capture.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/media/platform/davinci/vpif_capture.c
>> b/drivers/media/platform/davinci/vpif_capture.c index
>> 5104cc0ee40e..9f8f41c0f251 100644
>> --- a/drivers/media/platform/davinci/vpif_capture.c
>> +++ b/drivers/media/platform/davinci/vpif_capture.c
>> @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue *vq,
>> unsigned int count) }
>> }
>>
>> + spin_unlock_irqrestore(&common->irqlock, flags);
>> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1);
>> + spin_lock_irqsave(&common->irqlock, flags);
>
> I always get anxious when I see a spinlock being released randomly with an
> operation in the middle of a protected section. Looking at the code it looks
> like the spinlock is abused here. irqlock should only protect the dma_queue
> and should thus only be taken around the following code:
>
> spin_lock_irqsave(&common->irqlock, flags);
> /* Get the next frame from the buffer queue */
> common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
> struct vpif_cap_buffer, list);
> /* Remove buffer from the buffer queue */
> list_del(&common->cur_frm->list);
> spin_unlock_irqrestore(&common->irqlock, flags);
Yes, that looks correct. Will update.
> The code that is currently protected by the lock in the start and stop
> streaming functions should be protected by a mutex instead.
I tried taking the mutex here, but lockdep pointed out a deadlock. I
may not be fully understanding the V4L2 internals here, but it seems
that the ioctl is already taking a mutex, so taking it again in
start/stop streaming is a deadlock. Unless you think the locking should
be nested here, it seems to me that the mutex isn't needed.
Kevin
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: One Thousand Gnomes @ 2016-12-06 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9225f2da-c6c4-73c8-829a-1033716b4c71@gmail.com>
> > If we have different UART drivers, only one of them provides ttyS*, no?
> > Other drivers will have to use another namespace.
>
> I remember this was a problem a couple of years ago last I tried, with
> the 8250 driver being actually preventing other drivers from using
> ttyS*, but if you don't have 8250 taking over the low ttyS numbers, you
> may run into a case where several drivers successfully register their
> character devices under a ttyS* numbering scheme.
>
> Whether this is hypothetical or not nowadays, it may be nicer to provide
> a more uniquely distinct name like what dev_name() returns, or
> ttyS*-driver-tx for instance?
It needs to be at the tty layer anyway or you will break low end
machines. On a low end system with a 16450A UART you've got something
like 160 microseconds at 57600 baud before you must have exited the
IRQ handler, re-entered it and be reading the data register again. The
current proposed patches touching the 8250 IRQ path are almost certainly
going to cause regressions on old machines.
So you need to hook receive at a point outside of the IRQ layer (eg when
the workqueue starts feeding it into the ldisc), but on the tx side you
need to hook the write method of the tty really, because tty_write sends
data to the ldisc and what happens then is up to the ldisc.
Even there though you have cases that are terribly latency dependant like
some of the dumb programming tools that don't window. If you halve
someones programming rate for microcontrollers you are going to get hate
mail 8) For RX that can mostly be avoided by queuing the data then doing
the LEDs, for TX I'm not clear you can easily hide the latency.
Alan
^ permalink raw reply
* [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols
From: Mark Rutland @ 2016-12-06 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-6-git-send-email-labbott@redhat.com>
Hi,
As a heads-up, it looks like this got mangled somewhere. In the hunk at
arch/arm64/mm/kasan_init.c:68, 'do' in the context became 'edo'.
Deleting the 'e' makes it apply.
I think this is almost there; other than James's hibernate bug I only
see one real issue, and everything else is a minor nit.
On Tue, Nov 29, 2016 at 10:55:24AM -0800, Laura Abbott wrote:
> __pa_symbol is technically the marco that should be used for kernel
> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL which
> will do bounds checking. As part of this, introduce lm_alias, a
> macro which wraps the __va(__pa(...)) idiom used a few places to
> get the alias.
I think the addition of the lm_alias() macro under include/mm should be
a separate preparatory patch. That way it's separate from the
arm64-specific parts, and more obvious to !arm64 people reviewing the
other parts.
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v4: Stop calling __va early, conversion of a few more sites. I decided against
> wrapping the __p*d_populate calls into new functions since the call sites
> should be limited.
> ---
> arch/arm64/include/asm/kvm_mmu.h | 4 ++--
> arch/arm64/include/asm/memory.h | 2 ++
> arch/arm64/include/asm/mmu_context.h | 6 +++---
> arch/arm64/include/asm/pgtable.h | 2 +-
> arch/arm64/kernel/acpi_parking_protocol.c | 2 +-
> arch/arm64/kernel/cpu-reset.h | 2 +-
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/kernel/hibernate.c | 13 +++++--------
> arch/arm64/kernel/insn.c | 2 +-
> arch/arm64/kernel/psci.c | 2 +-
> arch/arm64/kernel/setup.c | 8 ++++----
> arch/arm64/kernel/smp_spin_table.c | 2 +-
> arch/arm64/kernel/vdso.c | 4 ++--
> arch/arm64/mm/init.c | 11 ++++++-----
> arch/arm64/mm/kasan_init.c | 21 +++++++++++++-------
> arch/arm64/mm/mmu.c | 32 +++++++++++++++++++------------
> drivers/firmware/psci.c | 2 +-
> include/linux/mm.h | 4 ++++
> 18 files changed, 70 insertions(+), 51 deletions(-)
It looks like we need to make sure these (directly) include <linux/mm.h>
for __pa_symbol() and lm_alias(), or there's some fragility, e.g.
[mark at leverpostej:~/src/linux]% uselinaro 15.08 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j10 -s
arch/arm64/kernel/psci.c: In function 'cpu_psci_cpu_boot':
arch/arm64/kernel/psci.c:48:50: error: implicit declaration of function '__pa_symbol' [-Werror=implicit-function-declaration]
int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa_symbol(secondary_entry));
^
cc1: some warnings being treated as errors
make[1]: *** [arch/arm64/kernel/psci.o] Error 1
make: *** [arch/arm64/kernel] Error 2
make: *** Waiting for unfinished jobs....
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -205,6 +205,8 @@ static inline void *phys_to_virt(phys_addr_t x)
> #define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
> #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
> #define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
> +#define sym_to_pfn(x) __phys_to_pfn(__pa_symbol(x))
> +#define lm_alias(x) __va(__pa_symbol(x))
As Catalin mentioned, we should be able to drop this copy of lm_alias(),
given we have the same in the core headers.
> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> index a2c2478..79cd86b 100644
> --- a/arch/arm64/kernel/vdso.c
> +++ b/arch/arm64/kernel/vdso.c
> @@ -140,11 +140,11 @@ static int __init vdso_init(void)
> return -ENOMEM;
>
> /* Grab the vDSO data page. */
> - vdso_pagelist[0] = pfn_to_page(PHYS_PFN(__pa(vdso_data)));
> + vdso_pagelist[0] = phys_to_page(__pa_symbol(vdso_data));
>
> /* Grab the vDSO code pages. */
> for (i = 0; i < vdso_pages; i++)
> - vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa(&vdso_start)) + i);
> + vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa_symbol(&vdso_start)) + i);
I see you added sym_to_pfn(), which we can use here to keep this short
and legible. It might also be worth using a temporary pfn_t, e.g.
pfn = sym_to_pfn(&vdso_start);
for (i = 0; i < vdso_pages; i++)
vdso_pagelist[i + 1] = pfn_to_page(pfn + i);
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index 8263429..9defbe2 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -383,7 +383,7 @@ static int psci_suspend_finisher(unsigned long index)
> u32 *state = __this_cpu_read(psci_power_state);
>
> return psci_ops.cpu_suspend(state[index - 1],
> - virt_to_phys(cpu_resume));
> + __pa_symbol(cpu_resume));
> }
>
> int psci_cpu_suspend_enter(unsigned long index)
This should probably be its own patch since it's not under arch/arm64/.
I'm happy for this to go via the arm64 tree with the rest regardless
(assuming Lorenzo has no objections).
Thanks,
Mark.
^ permalink raw reply
* [RFC PATCH] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Dave Martin @ 2016-12-06 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8dAumcEV8Wk+8rXO3VnN0e9rAHac=3-FMhra=tZgeVxg@mail.gmail.com>
On Tue, Dec 06, 2016 at 04:48:54PM +0000, Ard Biesheuvel wrote:
> On 6 December 2016 at 16:43, Dave Martin <Dave.Martin@arm.com> wrote:
> > On Tue, Dec 06, 2016 at 03:39:00PM +0000, Ard Biesheuvel wrote:
> >> Currently, we allow kernel mode NEON in softirq or hardirq context by
> >> stacking and unstacking a slice of the NEON register file for each call
> >> to kernel_neon_begin() and kernel_neon_end(), respectively.
> >>
> >> Given that
> >> a) a CPU typically spends most of its time in userland, during which time
> >> no kernel mode NEON in process context is in progress,
> >> b) a CPU spends most of its time in the kernel doing other things than
> >> kernel mode NEON when it gets interrupted to perform kernel mode NEON
> >> in softirq context
> >>
> >> the stacking and subsequent unstacking is only necessary if we are
> >> interrupting a thread while it is performing kernel mode NEON in process
> >> context, which means that in all other cases, we can simply preserve the
> >> userland FPSIMD state once, and only restore it upon return to userland,
> >> even if we are being invoked from softirq or hardirq context.
> >>
> >> So instead of checking whether we are running in interrupt context, keep
> >> track of the level of nested kernel mode NEON calls in progress, and only
> >> perform the eager stack/unstack of the level exceeds 1.
[...]
> >> + this_cpu_write(kernel_neon_nesting_level, level + 1);
> >
> > Should we BUG_ON overflow/underflow of the nesting level? That Should
> > Not Happen (tm), but we'll make a mess if it does.
> >
>
> True.
>
> > For the underflow case, perhaps DEBUG_PREEMPT is adequate for detecting
> > this via preempt count underflow.
> >
>
> I think it makes sense for the increment to check for overflow and the
> decrement to check for underflow, regardless of whether DEBUG_PREEMPT
> (or just PREEMPT) is enabled or not.
Fair enough
Cheers
---Dave
[...]
^ permalink raw reply
* How do I define SRAM chip in GPMC device tree ?
From: Tony Lindgren @ 2016-12-06 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3f98534e-2176-e03e-ac53-b60b8d0ead7c@newflow.co.uk>
Hi,
* Mark Jackson <mpfj-list@newflow.co.uk> [161206 04:33]:
> Hi
>
> We have an existing board supported in Linux v4.1 (see am335x-nano.dts)
> and I was looking to update to a more recent kernel but have hit a stumbling
> block.
>
> Our unit has an SRAM device connected to CS1 and we currently rely on uboot
> to init the GPMC settings.
>
> From v4.2+ I now see that the GPMC code has been changed to reset all the
> GPMC settings when the kernel starts, so our SRAM is now inaccessible.
Yes we've changed to use device tree to describe what's on the GPMC and
refuse to probe it unless configured properly. This is because of the
problems trying to use unknown bootloader configuration, such as kernel
hangs if GPMC was accessed in some cases.
If you enable CONFIG_OMAP_GPMC_DEBUG you should see the bootloader
configured timings in mostly suitable format for adding to dts.
> I've tried the following to add an extra device to the GPMC, but no go:-
>
> sram at 1,0 {
> reg = <1 0x00000000 0x01000000>;
> /*compatible = "mmio-sram";*/
> bank-width = <2>;
>
> gpmc,mux-add-data = <2>;
>
> gpmc,sync-clk-ps = <0>;
> gpmc,cs-on-ns = <0>;
> gpmc,cs-rd-off-ns = <160>;
> gpmc,cs-wr-off-ns = <160>;
> gpmc,adv-on-ns = <10>;
> gpmc,adv-rd-off-ns = <30>;
> gpmc,adv-wr-off-ns = <30>;
> gpmc,oe-on-ns = <40>;
> gpmc,oe-off-ns = <160>;
> gpmc,we-on-ns = <40>;
> gpmc,we-off-ns = <160>;
> gpmc,rd-cycle-ns = <160>;
> gpmc,wr-cycle-ns = <160>;
> gpmc,access-ns = <150>;
> gpmc,page-burst-access-ns = <10>;
> gpmc,cycle2cycle-samecsen;
> gpmc,cycle2cycle-delay-ns = <20>;
> gpmc,wr-data-mux-bus-ns = <70>;
> gpmc,wr-access-ns = <80>;
> };
>
> Looking at drivers/memory/omap-gpmc.c, I can see that when the GPMC
> children are scanned, only the following are matched:-
>
> "nand","onenand","ethernet","nor","uart"
Those are to set up things for probing the device driver for the
connected device. Some have both sync and async accaess to configure,
so at least so far we have not been able to come up with a generic
init.
> So can anyone explain how to add a standard SRAM chip ?
Assuming you've verified that the dts configuration produces working
timings for you, pobably gpmc_probe_generic_child() is the way to
go for adding "sram" option. Note that we have similar interfaces
already for onenand and ethernet for their buffers so you may want
to take a look what the init does for those.
But yeah basically a little bit of new code is needed for that.
Regards,
Tony
^ permalink raw reply
* [PATCH 0/7] arm: Add livepatch support
From: Abel Vesa @ 2016-12-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
This is just an idea I've been trying out for a while now.
Just in case somebody wants to play with it, this applies to linux-arm/for-next.
Also please note that this was only tested in qemu, but I will do some testing
on some real hardware in the following days.
FWICT, on this arch the compiler always generates a function prologue somewhere
between these lines:
e1a0c00d mov ip, sp
e92ddff0 push {r4-r9, sl, fp, ip, lr, pc}
e24cb004 sub fp, ip, #4
e24dd064 sub sp, sp, #100 ; 0x64 <--- local variables
e52de004 push {lr} ; (str lr, [sp, #-4]!)
ebf9c2c9 bl 80110364 <__gnu_mcount_nc>
....
Every function that follows this pattern (the number of registers pushed and the
sp subtraction for the local variables being the only acceptable exception) can
be patched with this mechanism. IIRC, only the inline functions and notrace
functions do not follow this pattern.
Considering that the function is livepatchable, when the time comes to call
ftrace_call, the ftrace_regs_caller is called instead.
Because this arch didn't have a ftrace with regs implementation, the
ftrace_regs_caller was added.
This new function adds the regs saving/restoring part, plus the part necessary
for the livepatch mechanism to work. After the regs are saved and the r3 is set
to contain the sp's value, we're keeping the old pc into r10 in order to be
checked later against the new pc.
Next, the r1 and r0 are set for the ftrace_func, then, the ftrace_stub is called
and the klp_ftrace_handler overwrites the old pc with the new one.
Here comes the tricky part. We're checking if the pc is still the old one, if it
is we jump the whole livepatching and go ahead with restoring the saved regs.
If the pc is modified, it means we're livepatching current function and we need
to pop all regs from r1 through r12, jump over the next two regs saved on stack
(we're not interested in those since we're trying to get the same regs context
as it was at the point the function-to-be-patched was called) and put the new pc
into r11.
Since r12 contains the sp from when the function just got branched to, we need
to set the sp back to that.
Then we need to put the new pc on stack so that when we're popping r11 through
pc, we will actually jump to the first instruction from the new function.
We don't need to worry about the returning phase since the epilogue of the new
function will take care of that and from there on everything goes back to
normal.
The whole advantage of this over adding compiler support is that we're not
introducing nops at the beginning of the function. As a matter of fact, we're
not changing anything between an image with livepatch and an image without it
(except the ftrace_regs_call addition and the livepatch necessary code).
As for the implementation of the ftrace_regs_caller, I still think there might
be some unsafe stack handling since I'm getting some build warnings. Those are
due to pushing/popping of a list of regs in which the sp resides. I'll try to
get around those in a next iteration (if necessary), but first I would like to
hear some opinions about this work and if it's worth going forward.
Everything else should be pretty straightforward, so I'll skip explaining that.
Abel Vesa (7):
arm: Add livepatch arch specific code
arm: ftrace: Add call modify mechanism
arm: module: Add apply_relocate_add
arm: Add ftrace with regs support
arm: ftrace: Add ARCH_SUPPORTS_FTRACE_OPS for ftrace with regs
arm: Add livepatch to build if CONFIG_LIVEPATCH
arm: Add livepatch necessary arch selects into Kconfig
MAINTAINERS | 3 +++
arch/arm/Kconfig | 4 ++++
arch/arm/include/asm/ftrace.h | 4 ++++
arch/arm/include/asm/livepatch.h | 46 +++++++++++++++++++++++++++++++++++++
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/entry-ftrace.S | 49 ++++++++++++++++++++++++++++++++++++++++
arch/arm/kernel/ftrace.c | 21 +++++++++++++++++
arch/arm/kernel/livepatch.c | 43 +++++++++++++++++++++++++++++++++++
arch/arm/kernel/module.c | 9 ++++++++
9 files changed, 180 insertions(+)
create mode 100644 arch/arm/include/asm/livepatch.h
create mode 100644 arch/arm/kernel/livepatch.c
--
2.7.4
^ permalink raw reply
* [PATCH 1/7] arm: Add livepatch arch specific code
From: Abel Vesa @ 2016-12-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-1-git-send-email-abelvesa@linux.com>
klp_get_ftrace_location is used by ftrace to get the entry for a
specific function from the mcount list. klp_arch_set_pc is used
to set the pc from the regs passed as an argument to the
ftrace_ops_no_ops function to the starting address of the patched
function. klp_write_module_reloc is not doing anything at this
moment.
Signed-off-by: Abel Vesa <abelvesa@linux.com>
---
MAINTAINERS | 3 +++
arch/arm/include/asm/livepatch.h | 46 ++++++++++++++++++++++++++++++++++++++++
arch/arm/kernel/livepatch.c | 43 +++++++++++++++++++++++++++++++++++++
3 files changed, 92 insertions(+)
create mode 100644 arch/arm/include/asm/livepatch.h
create mode 100644 arch/arm/kernel/livepatch.c
diff --git a/MAINTAINERS b/MAINTAINERS
index bd182a1..d43b790 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7466,12 +7466,15 @@ M: Josh Poimboeuf <jpoimboe@redhat.com>
M: Jessica Yu <jeyu@redhat.com>
M: Jiri Kosina <jikos@kernel.org>
M: Miroslav Benes <mbenes@suse.cz>
+M: Abel Vesa <abelvesa@linux.com>
R: Petr Mladek <pmladek@suse.com>
S: Maintained
F: kernel/livepatch/
F: include/linux/livepatch.h
F: arch/x86/include/asm/livepatch.h
F: arch/x86/kernel/livepatch.c
+F: arch/arm/include/asm/livepatch.h
+F: arch/arm/kernel/livepatch.c
F: Documentation/livepatch/
F: Documentation/ABI/testing/sysfs-kernel-livepatch
F: samples/livepatch/
diff --git a/arch/arm/include/asm/livepatch.h b/arch/arm/include/asm/livepatch.h
new file mode 100644
index 0000000..d4e3ff0
--- /dev/null
+++ b/arch/arm/include/asm/livepatch.h
@@ -0,0 +1,46 @@
+/*
+ * livepatch.h - arm specific Kernel Live Patching Core
+ *
+ * Copyright (C) 2016 Abel Vesa <abelvesa@linux.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _ASM_ARM_LIVEPATCH_H
+#define _ASM_ARM_LIVEPATCH_H
+
+#include <asm/setup.h>
+#include <linux/module.h>
+#include <linux/ftrace.h>
+
+static inline int klp_check_compiler_support(void)
+{
+ return 0;
+}
+
+int klp_write_module_reloc(struct module *mod, unsigned long type,
+ unsigned long loc, unsigned long value);
+
+static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
+{
+ regs->uregs[15] = ip;
+}
+
+#define klp_get_ftrace_location klp_get_ftrace_location
+static inline unsigned long klp_get_ftrace_location(unsigned long faddr)
+{
+ return ftrace_location_range(faddr, faddr + 24);
+}
+
+#endif /* _ASM_ARM_LIVEPATCH_H */
diff --git a/arch/arm/kernel/livepatch.c b/arch/arm/kernel/livepatch.c
new file mode 100644
index 0000000..0656cd6
--- /dev/null
+++ b/arch/arm/kernel/livepatch.c
@@ -0,0 +1,43 @@
+/*
+ * livepatch.c - arm specific Kernel Live Patching Core
+ *
+ * Copyright (C) 2016 Abel Vesa <abelvesa@linux.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/module.h>
+#include <linux/uaccess.h>
+#include <linux/ftrace.h>
+#include <asm/elf.h>
+#include <asm/livepatch.h>
+#include <asm/insn.h>
+#include <asm/ftrace.h>
+
+/**
+ * klp_write_module_reloc() - write a relocation in a module
+ * @mod: module in which the section to be modified is found
+ * @type: ELF relocation type (see asm/elf.h)
+ * @loc: address that the relocation should be written to
+ * @value: relocation value (sym address + addend)
+ *
+ * This function writes a relocation to the specified location for
+ * a particular module.
+ */
+int klp_write_module_reloc(struct module *mod, unsigned long type,
+ unsigned long loc, unsigned long value)
+{
+ /* Not implemented yet */
+ return 0;
+}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/7] arm: ftrace: Add call modify mechanism
From: Abel Vesa @ 2016-12-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-1-git-send-email-abelvesa@linux.com>
Function ftrace_modify_call provides a way to replace ftrace_stub
with the ftrace function. This helps the klp_ftrace_handler to be
called via ftrace_ops_no_ops, which in turn will set the pc with
the patched function's starting address. This is used for
livepatching.
Signed-off-by: Abel Vesa <abelvesa@linux.com>
---
arch/arm/kernel/ftrace.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
index 3f17594..cb4543a 100644
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -139,6 +139,15 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
ret = ftrace_modify_code(pc, 0, new, false);
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+ if (!ret) {
+ pc = (unsigned long)&ftrace_regs_call;
+ new = ftrace_call_replace(pc, (unsigned long)func);
+
+ ret = ftrace_modify_code(pc, 0, new, false);
+ }
+#endif
+
#ifdef CONFIG_OLD_MCOUNT
if (!ret) {
pc = (unsigned long)&ftrace_call_old;
@@ -151,6 +160,18 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
return ret;
}
+int ftrace_modify_call(struct dyn_ftrace *rec, unsigned long old_addr,
+ unsigned long addr)
+{
+ unsigned long pc = rec->ip;
+ u32 old, new;
+
+ old = arm_gen_branch(pc, old_addr);
+ new = arm_gen_branch(pc, addr);
+
+ return ftrace_modify_code(pc, old, new, true);
+}
+
int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
unsigned long new, old;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/7] arm: module: Add apply_relocate_add
From: Abel Vesa @ 2016-12-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-1-git-send-email-abelvesa@linux.com>
It was only added to fix compiler error. It is not implemented
yet.
Signed-off-by: Abel Vesa <abelvesa@linux.com>
---
arch/arm/kernel/module.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 4f14b5c..bf94922 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -52,6 +52,15 @@ void *module_alloc(unsigned long size)
#endif
int
+apply_relocate_add(Elf32_Shdr *sechdrs, const char *strtab,
+ unsigned int symindex, unsigned int relindex,
+ struct module *module)
+{
+ /* Not implemented yet */
+ return 0;
+}
+
+int
apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
unsigned int relindex, struct module *module)
{
--
2.7.4
^ permalink raw reply related
* [PATCH 4/7] arm: Add ftrace with regs support
From: Abel Vesa @ 2016-12-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-1-git-send-email-abelvesa@linux.com>
This adds __ftrace_regs_caller which, unlike __ftrace_caller,
adds register saving/restoring and livepatch handling if
the pc register gets modified by klp_ftrace_handler.
Signed-off-by: Abel Vesa <abelvesa@linux.com>
---
arch/arm/kernel/entry-ftrace.S | 49 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/arm/kernel/entry-ftrace.S b/arch/arm/kernel/entry-ftrace.S
index c73c403..b6ada5c 100644
--- a/arch/arm/kernel/entry-ftrace.S
+++ b/arch/arm/kernel/entry-ftrace.S
@@ -92,6 +92,46 @@
2: mcount_exit
.endm
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+
+.macro __ftrace_regs_caller suffix
+
+ stmdb sp!, {r0-r15}
+ mov r3, sp
+
+ ldr r10, [sp, #60]
+
+ mcount_get_lr r1 @ lr of instrumented func
+ mcount_adjust_addr r0, lr @ instrumented function
+
+ .globl ftrace_regs_call\suffix
+ftrace_regs_call\suffix:
+ bl ftrace_stub
+
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+ .globl ftrace_regs_graph_call\suffix
+ftrace_regs_graph_call\suffix:
+ mov r0, r0
+#endif
+#ifdef CONFIG_LIVEPATCH
+ ldr r0, [sp, #60]
+ cmp r0, r10
+ beq ftrace_regs_caller_end
+ ldmia sp!, {r0-r12}
+ add sp, sp, #8
+ ldmia sp!, {r11}
+ sub sp, r12, #16
+ str r11, [sp, #12]
+ ldmia sp!, {r11, r12, lr, pc}
+#endif
+ftrace_regs_caller_end\suffix:
+ ldmia sp!, {r0-r14}
+ add sp, sp, #4
+ mov pc, lr
+.endm
+
+#endif
+
.macro __ftrace_caller suffix
mcount_enter
@@ -212,6 +252,15 @@ UNWIND(.fnstart)
__ftrace_caller
UNWIND(.fnend)
ENDPROC(ftrace_caller)
+
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+ENTRY(ftrace_regs_caller)
+UNWIND(.fnstart)
+ __ftrace_regs_caller
+UNWIND(.fnend)
+ENDPROC(ftrace_regs_caller)
+#endif
+
#endif
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
--
2.7.4
^ permalink raw reply related
* [PATCH 5/7] arm: ftrace: Add ARCH_SUPPORTS_FTRACE_OPS for ftrace with regs
From: Abel Vesa @ 2016-12-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-1-git-send-email-abelvesa@linux.com>
ARCH_SUPPORTS_FTRACE_OPS is needed for livepatch if
CONFIG_DYNAMIC_FTRACE_WITH_REGS is defined.
Signed-off-by: Abel Vesa <abelvesa@linux.com>
---
arch/arm/include/asm/ftrace.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index bfe2a2f..f434ce9 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -1,6 +1,10 @@
#ifndef _ASM_ARM_FTRACE
#define _ASM_ARM_FTRACE
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+#define ARCH_SUPPORTS_FTRACE_OPS 1
+#endif
+
#ifdef CONFIG_FUNCTION_TRACER
#define MCOUNT_ADDR ((unsigned long)(__gnu_mcount_nc))
#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
--
2.7.4
^ permalink raw reply related
* [PATCH 6/7] arm: Add livepatch to build if CONFIG_LIVEPATCH
From: Abel Vesa @ 2016-12-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-1-git-send-email-abelvesa@linux.com>
Necessary livepatch file added to makefile.
Signed-off-by: Abel Vesa <abelvesa@linux.com>
---
arch/arm/kernel/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index ad325a8..9e70220 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_HAVE_ARM_TWD) += smp_twd.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arch_timer.o
obj-$(CONFIG_FUNCTION_TRACER) += entry-ftrace.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o insn.o
+obj-$(CONFIG_LIVEPATCH) += livepatch.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o insn.o
obj-$(CONFIG_JUMP_LABEL) += jump_label.o insn.o patch.o
obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o
--
2.7.4
^ permalink raw reply related
* [PATCH 7/7] arm: Add livepatch necessary arch selects into Kconfig
From: Abel Vesa @ 2016-12-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-1-git-send-email-abelvesa@linux.com>
This adds HAVE_LIVEPATCH, MODULES_USE_ELF_RELA and HAVE_LIVEPATCH
to arm Kconfig.
Signed-off-by: Abel Vesa <abelvesa@linux.com>
---
arch/arm/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 186c4c2..f4e9ace 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -50,6 +50,7 @@ config ARM
select HAVE_DMA_API_DEBUG
select HAVE_DMA_CONTIGUOUS if MMU
select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) && !CPU_ENDIAN_BE32 && MMU
+ select HAVE_DYNAMIC_FTRACE_WITH_REGS
select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
select HAVE_EXIT_THREAD
select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
@@ -67,6 +68,7 @@ config ARM
select HAVE_KERNEL_XZ
select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && !CPU_V7M
select HAVE_KRETPROBES if (HAVE_KPROBES)
+ select HAVE_LIVEPATCH
select HAVE_MEMBLOCK
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI
@@ -82,6 +84,7 @@ config ARM
select HAVE_VIRT_CPU_ACCOUNTING_GEN
select IRQ_FORCED_THREADING
select MODULES_USE_ELF_REL
+ select MODULES_USE_ELF_RELA
select NO_BOOTMEM
select OF_EARLY_FLATTREE if OF
select OF_RESERVED_MEM if OF
@@ -1841,6 +1844,7 @@ config XEN
help
Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
+source "kernel/livepatch/Kconfig"
endmenu
menu "Boot options"
--
2.7.4
^ permalink raw reply related
* [PATCH v3] mach-omap2: fixing wrong strcat for Non-NULL terminated string
From: Tony Lindgren @ 2016-12-06 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480915633-16284-1-git-send-email-maninder1.s@samsung.com>
* Maninder Singh <maninder1.s@samsung.com> [161204 21:32]:
> Issue caught with static analysis tool:
> "Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)"
>
> Use strlcpy _includes_ the NUL terminator, and strlcat() which ensures
> that it won't overflow the buffer.
>
> Reported-by: Maninder Singh <maninder1.s@samsung.com>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> Signed-off-by: Russell King <linux@armlinux.org.uk>
I think the above should have been just:
Cc: Russell King <linux@armlinux.org.uk>
Can you please check and resend with Russell in Cc?
Regards,
Tony
> ---
> v1 -> v2: changed strncpy to strlcpy
> v2 -> v3: use of strlcat as suggested by Russell to
> make change clearer and simpler.
>
> arch/arm/mach-omap2/omap_hwmod.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 759e1d4..e8b9887 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -741,14 +741,14 @@ static int _init_main_clk(struct omap_hwmod *oh)
> int ret = 0;
> char name[MOD_CLK_MAX_NAME_LEN];
> struct clk *clk;
> + static const char modck[] = "_mod_ck";
>
> - /* +7 magic comes from '_mod_ck' suffix */
> - if (strlen(oh->name) + 7 > MOD_CLK_MAX_NAME_LEN)
> + if (strlen(oh->name) >= MOD_CLK_MAX_NAME_LEN - strlen(modck))
> pr_warn("%s: warning: cropping name for %s\n", __func__,
> oh->name);
>
> - strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
> - strcat(name, "_mod_ck");
> + strlcpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - strlen(modck));
> + strlcat(name, modck, MOD_CLK_MAX_NAME_LEN);
>
> clk = clk_get(NULL, name);
> if (!IS_ERR(clk)) {
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 1/5] ARM: BCM5301X: Fix LAN LED labels for Luxul XWR-3100
From: Rafał Miłecki @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Rafa? Mi?ecki <rafal@milecki.pl>
They were named incorrectly most likely due to copy & paste mistake.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
index 2f4a651..93cc91d 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
@@ -31,13 +31,13 @@
};
lan3 {
- label = "bcm53xx:green:lan1";
+ label = "bcm53xx:green:lan3";
gpios = <&chipcommon 1 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
lan4 {
- label = "bcm53xx:green:lan0";
+ label = "bcm53xx:green:lan4";
gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
@@ -49,7 +49,7 @@
};
lan1 {
- label = "bcm53xx:green:lan3";
+ label = "bcm53xx:green:lan1";
gpios = <&chipcommon 4 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
--
2.10.1
^ permalink raw reply related
* [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT
From: Rafał Miłecki @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
There are 3 separated controllers, one per USB /standard/. With PHY
drivers in place they can be simply supported with generic drivers.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm5301x.dtsi | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index f09a2bb..bfc98d19 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -248,8 +248,26 @@
#address-cells = <1>;
#size-cells = <1>;
+ ranges;
- phys = <&usb2_phy>;
+ interrupt-parent = <&gic>;
+
+ ohci: ohci at 21000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-ohci";
+ reg = <0x00022000 0x1000>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ ehci: ehci at 22000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-ehci";
+ reg = <0x00021000 0x1000>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb2_phy>;
+ };
};
usb3: usb3 at 23000 {
@@ -257,6 +275,19 @@
#address-cells = <1>;
#size-cells = <1>;
+ ranges;
+
+ interrupt-parent = <&gic>;
+
+ xhci: xhci at 23000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-xhci";
+ reg = <0x00023000 0x1000>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb3_phy>;
+ phy-names = "usb";
+ };
};
spi at 29000 {
--
2.10.1
^ permalink raw reply related
* [PATCH 3/5] ARM: BCM5301X: Set GPIO enabling USB power on Netgear R7000
From: Rafał Miłecki @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-1-zajec5@gmail.com>
There is one GPIO controlling power for both USB ports.
Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index 0225d82..7ab1176 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -100,3 +100,11 @@
};
};
};
+
+&usb2 {
+ vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
+};
+
+&usb3 {
+ vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
+};
--
2.10.1
^ permalink raw reply related
* [PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Rafał Miłecki @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
So far we were specifying only the first block which is always limited
up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts | 3 ++-
arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts | 3 ++-
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 3 ++-
arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 3 ++-
arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 3 ++-
arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts | 3 ++-
arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 3 ++-
arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 3 ++-
arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 3 ++-
arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 3 ++-
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 ++-
arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3 ++-
15 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
index 112a5a8..d241cee 100644
--- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
+++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
index 3600f56..b0e6204 100644
--- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
+++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
index d49afec0..c9ba6b9 100644
--- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
+++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
spi {
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
index 8519548..b9f66c0 100644
--- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
index 6229ef2..ae0199f 100644
--- a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
index 74cfcd3..36b628b1 100644
--- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
+++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
index 71b98cf..db8608b 100644
--- a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
+++ b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
index 2922536..d51586d 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
spi {
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
index 184fd92..de041b8 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
gpio-keys {
diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
index eac0f52..eaca687 100644
--- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
+++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
index aab39c9..b32957c 100644
--- a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
+++ b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index 7ab1176..f459a98 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
index 56d38a3..cd13534 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
index 7fb9270..64ded76 100644
--- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
+++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
nand: nand at 18028000 {
diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
index 7ecd57c..600795e 100644
--- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
+++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
@@ -18,7 +18,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
leds {
--
2.10.1
^ permalink raw reply related
* [PATCH 5/5] ARM: BCM53573: Specify USB ports of on-SoC controllers
From: Rafał Miłecki @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
Broadcom OHCI and EHCI controllers always have 2 ports each on the root
hub. Describe them in DT to allow specifying extra info or referencing
port nodes.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm53573.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/bcm53573.dtsi b/arch/arm/boot/dts/bcm53573.dtsi
index e2c496a..2da04d0 100644
--- a/arch/arm/boot/dts/bcm53573.dtsi
+++ b/arch/arm/boot/dts/bcm53573.dtsi
@@ -124,6 +124,17 @@
reg = <0x4000 0x1000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ehci_port1: port at 1 {
+ reg = <1>;
+ };
+
+ ehci_port2: port at 2 {
+ reg = <2>;
+ };
};
ohci: ohci at d000 {
@@ -133,6 +144,17 @@
reg = <0xd000 0x1000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ohci_port1: port at 1 {
+ reg = <1>;
+ };
+
+ ohci_port2: port at 2 {
+ reg = <2>;
+ };
};
};
--
2.10.1
^ permalink raw reply related
* [PATCH v2] arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the guest
From: Marc Zyngier @ 2016-12-06 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206162918.GE4816@cbox>
On 06/12/16 16:29, Christoffer Dall wrote:
> On Tue, Dec 06, 2016 at 02:56:50PM +0000, Marc Zyngier wrote:
>> The ARMv8 architecture allows the cycle counter to be configured
>> by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0,
>> hence accessing PMCCFILTR_EL0. But it disallows the use of
>> PMSELR_EL0.SEL==0x1f to access the cycle counter itself through
>> PMXEVCNTR_EL0.
>>
>> Linux itself doesn't violate this rule, but we may end up with
>> PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that
>> guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1,
>> despite the guest not having done anything wrong.
>>
>> In order to avoid this unfortunate course of events (haha!), let's
>
> I actually did find this funny.
>
>> sanitize PMSELR_EL0 on guest entry. This ensures that the guest
>> won't explode unexpectedly.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> This is another approach to fix this issue, this time nuking PMSELR_EL0
>> on guest entry instead of relying on perf not to clobber the register.
>>
>> Tested on v4.9-rc8 with a Rev A3 X-Gene.
>>
>> arch/arm64/kvm/hyp/switch.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>> index 83037cd..3b7cfbd 100644
>> --- a/arch/arm64/kvm/hyp/switch.c
>> +++ b/arch/arm64/kvm/hyp/switch.c
>> @@ -85,7 +85,13 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
>> write_sysreg(val, hcr_el2);
>> /* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
>> write_sysreg(1 << 15, hstr_el2);
>> - /* Make sure we trap PMU access from EL0 to EL2 */
>> + /*
>> + * Make sure we trap PMU access from EL0 to EL2. Also sanitize
>> + * PMSELR_EL0 to make sure it never contains the cycle
>> + * counter, which could make a PMXEVCNTR_EL0 access UNDEF.
>> + */
>> + if (vcpu->arch.mdcr_el2 & MDCR_EL2_HPMN_MASK)
>> + write_sysreg(0, pmselr_el0);
>
> I'm a bit confused about how we use the HPMN field. This value is
> always set to the full number of counters available on the system and
> never modified by the guest, right? So this is in essence a check that
> says 'do you have any performance counters, then make sure accesses
> don't undef to el1 instead of trapping to el2', but then my question is,
> why not just set pmselr_el0 to zero unconditionally, because in the case
> where (vcpu->arch.mdcr_el2 & MDCR_EL2_HPMN_MASK) == 0, it means we have
> no counters, which we'll have exposed to the guest anyhow, and we should
> undef at el1 in the guest, or did I get this completely wrong (like
> everything else today)?
Yeah, that's probably the best course of action. If the guest does
something silly, tough. I'll drop the test and repost the thing.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox