Hi Will,
Thanks for the reply.
On 21/03/2016:02:52:43 PM, Will Deacon wrote:
> On Fri, Mar 18, 2016 at 06:59:02PM +0530, Pratyush Anand wrote:
> > On 17/03/2016:01:27:26 PM, Pratyush Anand wrote:
> > > @David: This patch was added in v9 and fixup_exception() had been dropped
> > > in v9.
> > >
Hi Will,
Thanks for the reply.
On 21/03/2016:02:52:43 PM, Will Deacon wrote:
> On Fri, Mar 18, 2016 at 06:59:02PM +0530, Pratyush Anand wrote:
> > On 17/03/2016:01:27:26 PM, Pratyush Anand wrote:
> > > @David: This patch was added in v9 and fixup_exception() had been dropped
> > > in v9.
> > >
On Fri, Mar 18, 2016 at 06:59:02PM +0530, Pratyush Anand wrote:
> On 17/03/2016:01:27:26 PM, Pratyush Anand wrote:
> > @David: This patch was added in v9 and fixup_exception() had been dropped
> > in v9.
> > Since, dropping of fixup_exception() also caused to fail some systemtap test
> > cases,
On Fri, Mar 18, 2016 at 06:59:02PM +0530, Pratyush Anand wrote:
> On 17/03/2016:01:27:26 PM, Pratyush Anand wrote:
> > @David: This patch was added in v9 and fixup_exception() had been dropped
> > in v9.
> > Since, dropping of fixup_exception() also caused to fail some systemtap test
> > cases,
Hi James,
On 18/03/2016:06:12:20 PM, James Morse wrote:
> Hi Pratyush,
>
> On 18/03/16 14:43, Pratyush Anand wrote:
> > On 18/03/2016:02:02:49 PM, James Morse wrote:
> >> In kernel/entry.S when entered from EL0 we test for TIF_SINGLESTEP in the
> >> thread_info flags, and use
Hi James,
On 18/03/2016:06:12:20 PM, James Morse wrote:
> Hi Pratyush,
>
> On 18/03/16 14:43, Pratyush Anand wrote:
> > On 18/03/2016:02:02:49 PM, James Morse wrote:
> >> In kernel/entry.S when entered from EL0 we test for TIF_SINGLESTEP in the
> >> thread_info flags, and use
Hi Pratyush,
On 18/03/16 13:29, Pratyush Anand wrote:
> Probably, I can see why does not it work. So, when we are single stepping an
> instruction and page fault occurs, we will come to el1_da in entry.S. Here, we
> do enable_dbg. As soon as we will do this, we will start receiving single step
>
Hi Pratyush,
On 18/03/16 13:29, Pratyush Anand wrote:
> Probably, I can see why does not it work. So, when we are single stepping an
> instruction and page fault occurs, we will come to el1_da in entry.S. Here, we
> do enable_dbg. As soon as we will do this, we will start receiving single step
>
Hi James,
On 16/03/2016:10:27:22 AM, James Morse wrote:
> Hi Pratyush,
>
> On 16/03/16 05:43, Pratyush Anand wrote:
> > On 15/03/2016:06:47:52 PM, James Morse wrote:
> >> If I understand this correctly - you can't kprobe these ldr/str
> >> instructions
> >> as the fault handler wouldn't find
Hi James,
On 16/03/2016:10:27:22 AM, James Morse wrote:
> Hi Pratyush,
>
> On 16/03/16 05:43, Pratyush Anand wrote:
> > On 15/03/2016:06:47:52 PM, James Morse wrote:
> >> If I understand this correctly - you can't kprobe these ldr/str
> >> instructions
> >> as the fault handler wouldn't find
>From: "David A. Long"
>
>Currrently taking exceptions when accessing user data from a kprobe'd
>instruction doesn't work. Avoid this situation by blacklisting the relevant
>functions.
>
>Signed-off-by: David A. Long
Looks good to me.
Reviewed-by:
>From: "David A. Long"
>
>Currrently taking exceptions when accessing user data from a kprobe'd
>instruction doesn't work. Avoid this situation by blacklisting the relevant
>functions.
>
>Signed-off-by: David A. Long
Looks good to me.
Reviewed-by: Masami Hiramatsu
Thanks,
>---
>
Hi James,
On 18/03/2016:02:02:49 PM, James Morse wrote:
> Hi Pratyush,
>
> On 18/03/16 13:29, Pratyush Anand wrote:
> > Probably, I can see why does not it work. So, when we are single stepping an
> > instruction and page fault occurs, we will come to el1_da in entry.S. Here,
> > we
> > do
Hi James,
On 18/03/2016:02:02:49 PM, James Morse wrote:
> Hi Pratyush,
>
> On 18/03/16 13:29, Pratyush Anand wrote:
> > Probably, I can see why does not it work. So, when we are single stepping an
> > instruction and page fault occurs, we will come to el1_da in entry.S. Here,
> > we
> > do
Hi Pratyush,
On 18/03/16 14:43, Pratyush Anand wrote:
> On 18/03/2016:02:02:49 PM, James Morse wrote:
>> In kernel/entry.S when entered from EL0 we test for TIF_SINGLESTEP in the
>> thread_info flags, and use disable_step_tsk/enable_step_tsk to save/restore
>> the
>> single-step state.
>>
>>
Hi Pratyush,
On 18/03/16 14:43, Pratyush Anand wrote:
> On 18/03/2016:02:02:49 PM, James Morse wrote:
>> In kernel/entry.S when entered from EL0 we test for TIF_SINGLESTEP in the
>> thread_info flags, and use disable_step_tsk/enable_step_tsk to save/restore
>> the
>> single-step state.
>>
>>
On 17/03/2016:01:27:26 PM, Pratyush Anand wrote:
> @David: This patch was added in v9 and fixup_exception() had been dropped in
> v9.
> Since, dropping of fixup_exception() also caused to fail some systemtap test
> cases, so it was added back in v10. I wonder if we really need this patch.
> May
On 17/03/2016:01:27:26 PM, Pratyush Anand wrote:
> @David: This patch was added in v9 and fixup_exception() had been dropped in
> v9.
> Since, dropping of fixup_exception() also caused to fail some systemtap test
> cases, so it was added back in v10. I wonder if we really need this patch.
> May
Hi Pratyush,
On 16/03/16 05:43, Pratyush Anand wrote:
> On 15/03/2016:06:47:52 PM, James Morse wrote:
>> If I understand this correctly - you can't kprobe these ldr/str instructions
>> as the fault handler wouldn't find kprobe's out-of line version of the
>> instruction in the exception table...
Hi Pratyush,
On 16/03/16 05:43, Pratyush Anand wrote:
> On 15/03/2016:06:47:52 PM, James Morse wrote:
>> If I understand this correctly - you can't kprobe these ldr/str instructions
>> as the fault handler wouldn't find kprobe's out-of line version of the
>> instruction in the exception table...
On 15/03/2016:06:47:52 PM, James Morse wrote:
> Hi David,
>
> On 09/03/16 05:32, David Long wrote:
> > From: "David A. Long"
> > diff --git a/arch/arm64/lib/copy_from_user.S
> > b/arch/arm64/lib/copy_from_user.S
> > index 4699cd7..0ac2131 100644
> > ---
On 15/03/2016:06:47:52 PM, James Morse wrote:
> Hi David,
>
> On 09/03/16 05:32, David Long wrote:
> > From: "David A. Long"
> > diff --git a/arch/arm64/lib/copy_from_user.S
> > b/arch/arm64/lib/copy_from_user.S
> > index 4699cd7..0ac2131 100644
> > --- a/arch/arm64/lib/copy_from_user.S
> > +++
Hi David,
On 09/03/16 05:32, David Long wrote:
> From: "David A. Long"
> diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
> index 4699cd7..0ac2131 100644
> --- a/arch/arm64/lib/copy_from_user.S
> +++ b/arch/arm64/lib/copy_from_user.S
> @@ -66,6
Hi David,
On 09/03/16 05:32, David Long wrote:
> From: "David A. Long"
> diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
> index 4699cd7..0ac2131 100644
> --- a/arch/arm64/lib/copy_from_user.S
> +++ b/arch/arm64/lib/copy_from_user.S
> @@ -66,6 +66,7 @@
>
From: "David A. Long"
Currrently taking exceptions when accessing user data from a kprobe'd
instruction doesn't work. Avoid this situation by blacklisting the relevant
functions.
Signed-off-by: David A. Long
---
arch/arm64/lib/copy_from_user.S | 1 +
From: "David A. Long"
Currrently taking exceptions when accessing user data from a kprobe'd
instruction doesn't work. Avoid this situation by blacklisting the relevant
functions.
Signed-off-by: David A. Long
---
arch/arm64/lib/copy_from_user.S | 1 +
arch/arm64/lib/copy_to_user.S | 1 +
2
26 matches
Mail list logo