linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Long <dave.long@linaro.org>
To: Steve Capper <steve.capper@linaro.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"Jon Medhurst (Tixy)" <tixy@linaro.org>,
	Russell King <linux@arm.linux.org.uk>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Sandeepa Prabhu <sandeepa.prabhu@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
	William Cohen <wcohen@redhat.com>,
	David Miller <davem@davemloft.net>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 0/5] ARM64: Add kernel probes(Kprobes) support
Date: Fri, 12 Dec 2014 17:42:32 -0500	[thread overview]
Message-ID: <548B6F58.6010108@linaro.org> (raw)
In-Reply-To: <20141210163817.GA27500@linaro.org>

On 12/10/14 11:38, Steve Capper wrote:
> On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
>> On 12/09/14 08:33, Steve Capper wrote:
>>> On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
>
> [...]
>
>>>
>>> Not sure if this is helpful, but the following also caused a crash for
>>> me:
>>>
>>> echo "p:trace_event_buffer_lock_reserve trace_event_buffer_lock_reserve" > /sys/kernel/debug/tracing/kprobe_events
>>> echo "p:memcpy memcpy" >> /sys/kernel/debug/tracing/kprobe_events
>>> echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
>>>
>>> [immediate crash]
>>>
>>> The crash point for me is in the arm64 ASID allocator, it again looks
>>> like the interrupts are in an unexpected state.
>>> (check_and_switch_context goes down the irqs disabled code path, I
>>> think incorrectly).
>>>
>>> This occurred for me both with and without the proposed irq saving fix.
>>>
>>> I will do some more digging.
>>>
>>
>> Thanks, more information is good.
>>
>
> Hi,
>
> Some good news, I think I've fixed the problem I've been experiencing.
>
> Basically, I've torn out all the interrupt save/restore and have
> narrowed the scope to just sandwich the instruction single-step. This
> simplifies a lot of logic, and I've now been able to perf record a
> kprobe on memcpy (and the trace_event_buffer_lock_reserve + memcpy
> test) without any issues on a Juno platform.
>
> I may have been somewhat over-zealous with the chainsaw, so please do
> put this fix through its paces.
>
> Cheers,
> --
> Steve
>
>
>  From d3f4d80ce19bec71bd03209beb2fbfd8084d6543 Mon Sep 17 00:00:00 2001
> From: Steve Capper <steve.capper@linaro.org>
> Date: Mon, 1 Dec 2014 11:30:10 +0000
> Subject: [PATCH] Fix the interrupt handling for kprobes
>
> ---
>   arch/arm64/kernel/kprobes.c | 16 ++--------------
>   1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
> index be7c330..d39d826 100644
> --- a/arch/arm64/kernel/kprobes.c
> +++ b/arch/arm64/kernel/kprobes.c
> @@ -229,10 +229,6 @@ skip_singlestep_missed(struct kprobe_ctlblk *kcb, struct pt_regs *regs)
>   {
>   	/* set return addr to next pc to continue */
>   	instruction_pointer(regs) += sizeof(kprobe_opcode_t);
> -
> -	if (kcb->kprobe_status != KPROBE_REENTER)
> -		kprobes_restore_local_irqflag(regs);
> -
>   }
>
>   static void __kprobes setup_singlestep(struct kprobe *p,
> @@ -259,7 +255,7 @@ static void __kprobes setup_singlestep(struct kprobe *p,
>   			spsr_set_debug_flag(regs, 0);
>
>   		/* IRQs and single stepping do not mix well. */
> -		local_irq_disable();
> +		kprobes_save_local_irqflag(regs);
>   		kernel_enable_single_step(regs);
>   		instruction_pointer(regs) = slot;
>   	} else	{
> @@ -326,7 +322,6 @@ post_kprobe_handler(struct kprobe_ctlblk *kcb, struct pt_regs *regs)
>   	}
>
>   	reset_current_kprobe();
> -	kprobes_restore_local_irqflag(regs);
>   }
>
>   int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
> @@ -380,8 +375,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
>   			return 1;
>
>   		break;
> -	default:
> -		break;
>   	}
>   	return 0;
>   }
> @@ -446,7 +439,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
>   		 * handling of this interrupt is appropriate.
>   		 * Return back to original instruction, and continue.
>   		 */
> -		kprobes_restore_local_irqflag(regs);
>   		return;
>   	} else if (cur) {
>   		/* We probably hit a jprobe.  Call its break handler. */
> @@ -459,7 +451,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
>   		/* breakpoint is removed, now in a race
>   		 * Return back to original instruction & continue.
>   		 */
> -		kprobes_restore_local_irqflag(regs);
>   	}
>   }
>
> @@ -485,6 +476,7 @@ kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr)
>   	retval = kprobe_ss_hit(kcb, instruction_pointer(regs));
>
>   	if (retval == DBG_HOOK_HANDLED) {
> +		kprobes_restore_local_irqflag(regs);
>   		kernel_disable_single_step();
>
>   		if (kcb->kprobe_status == KPROBE_REENTER)
> @@ -499,7 +491,6 @@ kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr)
>   static int __kprobes
>   kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr)
>   {
> -	kprobes_save_local_irqflag(regs);
>   	kprobe_handler(regs);
>   	return DBG_HOOK_HANDLED;
>   }
> @@ -563,7 +554,6 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
>   		memcpy((void *)stack_addr, kcb->jprobes_stack,
>   		       MIN_STACK_SIZE(stack_addr));
>   		preempt_enable_no_resched();
> -		kprobes_restore_local_irqflag(regs);
>   		return 1;
>   	}
>   	return 0;
> @@ -655,8 +645,6 @@ trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
>   		kfree(ri);
>   	}
>
> -	kprobes_restore_local_irqflag(regs);
> -
>   	/* return 1 so that post handlers not called */
>   	return 1;
>   }
>

Sorry for the delay in responding.  The assumption with the existing 
code is that you can't enable single-stepping in MDSCR until you disable 
interrupts.  But since we get to that point (in this case) with debug 
exceptions masked in daif I suppose this is an unnecessary constraint, 
as you have demonstrated.  I do actually wonder if we need to set the 
bit in MDSCR_EL1 at all since we're also setting it in the spsr in the 
regs structure that will be restored when the eret is done, but it looks 
like kernel_enable_single_step() sets both.

-dl




  reply	other threads:[~2014-12-12 22:42 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-18  6:32 [PATCH v3 0/5] ARM64: Add kernel probes(Kprobes) support David Long
2014-11-18  6:32 ` [PATCH v3 1/5] arm64: Kprobes with single stepping support David Long
2014-11-18 13:28   ` Jon Medhurst (Tixy)
2014-11-21  4:28     ` David Long
2014-11-18 14:38   ` William Cohen
2014-11-18 14:39   ` William Cohen
2014-11-18 14:56   ` Will Deacon
2014-11-19 11:21     ` Sandeepa Prabhu
2014-11-19 11:25       ` Will Deacon
2014-11-19 14:55         ` David Long
2014-11-20  5:10           ` Sandeepa Prabhu
2014-11-26  6:46           ` David Long
2014-11-26 10:09             ` Will Deacon
2014-12-22 10:10   ` Pratyush Anand
2014-11-18  6:32 ` [PATCH v3 2/5] arm64: Kprobes instruction simulation support David Long
2014-11-18 14:43   ` William Cohen
2014-11-18  6:32 ` [PATCH v3 3/5] arm64: Add kernel return probes support(kretprobes) David Long
2014-11-18 14:50   ` William Cohen
2014-11-18  6:32 ` [PATCH v3 4/5] kprobes: Add arm64 case in kprobe example module David Long
2014-11-18  6:32 ` [PATCH v3 5/5] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature David Long
2014-11-18 14:52   ` Will Deacon
2014-11-20  7:20     ` Masami Hiramatsu
2014-11-21  6:16     ` David Long
2014-11-20 15:02 ` [PATCH v3 0/5] ARM64: Add kernel probes(Kprobes) support Steve Capper
2014-11-26  8:33   ` Masami Hiramatsu
2014-11-26 10:03     ` Steve Capper
2014-11-26 17:46       ` David Long
2014-11-26 18:59         ` Steve Capper
2014-11-27  6:07           ` Masami Hiramatsu
2014-11-28 16:01             ` Steve Capper
2014-12-01  9:37               ` Masami Hiramatsu
2014-12-02 19:27                 ` William Cohen
2014-12-02 20:00                   ` William Cohen
2014-12-03  3:36                   ` Masami Hiramatsu
2014-12-03 14:54                 ` William Cohen
2014-12-03 22:54                   ` David Long
2014-12-04  0:02                     ` David Long
2014-12-04  1:16                     ` William Cohen
2014-12-04  2:48                       ` David Long
2014-12-04 10:21                         ` Steve Capper
2014-12-04 10:43                           ` Masami Hiramatsu
2014-12-04 11:29                             ` Steve Capper
2014-12-04 11:53                               ` Masami Hiramatsu
2014-12-09 13:33                                 ` Steve Capper
2014-12-09 14:27                                   ` David Long
2014-12-10 16:38                                     ` Steve Capper
2014-12-12 22:42                                       ` David Long [this message]
2014-12-12 23:10                                         ` Steve Capper
2014-12-15  5:58                                           ` Masami Hiramatsu
2014-12-15  6:29                                           ` David Long
2014-12-05  5:08                       ` William Cohen
2014-11-27  5:13       ` Masami Hiramatsu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=548B6F58.6010108@linaro.org \
    --to=dave.long@linaro.org \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=sandeepa.prabhu@linaro.org \
    --cc=steve.capper@linaro.org \
    --cc=tixy@linaro.org \
    --cc=wcohen@redhat.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).