Hi Oleg,
Yes, I can see that "arch/x86/kernel/vsyscall_64.c"
has changed dramatically since I last looked at it.
Since this is the case, I no longer need to trap the vsyscall page.
Now however, that "vsyscall" was effectively replaced by vdso, it
creates a new problem for me and probably for
Hi Amnon,
Please read my previous email ;)
http://marc.info/?l=linux-kernel=135342649119153
On 11/21, u3...@miso.sublimeip.com wrote:
>
> Hi Oleg,
>
> > Or. Perhaps we can define TRAP_VSYSCALL and change emulate_vsyscall() to
> > do
> >
> >
> > if (current->ptrace &&
Hi Amnon,
Please read my previous email ;)
http://marc.info/?l=linux-kernelm=135342649119153
On 11/21, u3...@miso.sublimeip.com wrote:
Hi Oleg,
Or. Perhaps we can define TRAP_VSYSCALL and change emulate_vsyscall() to
do
if (current-ptrace test_thread_flag(TIF_SYSCALL_TRACE))
Hi Oleg,
Yes, I can see that arch/x86/kernel/vsyscall_64.c
has changed dramatically since I last looked at it.
Since this is the case, I no longer need to trap the vsyscall page.
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone
Hi Oleg,
> Or. Perhaps we can define TRAP_VSYSCALL and change emulate_vsyscall() to
> do
>
>
> if (current->ptrace && test_thread_flag(TIF_SYSCALL_TRACE))
> send_sigtrap(TRAP_VSYSCALL, ...);
>
> if it returns true?
>
I wish it were possible, but the vsyscall page is entered
On 11/20, Oleg Nesterov wrote:
>
> On 11/19, Steven Rostedt wrote:
> >
> > Is this really what we want?
>
> I am not sure, that is why I am asking.
Yes.
And,
> Well yes, with the new implementation __vsyscall_page simply does
> syscall, so I guess (say) strace will "just work". But, afaics,
On Tue, 2012-11-20 at 16:48 +0100, Oleg Nesterov wrote:
> > But here, there's no prejudice between tasks. All tasks will now hit the
> > breakpoint regardless of if it is being traced or not.
> ^^
>
> This is hardware breakpoint, it is per-task.
I forgot that hw breakpoints are
On 11/19, Steven Rostedt wrote:
>
> On Mon, 2012-11-19 at 18:47 +0100, Oleg Nesterov wrote:
> >
> > Just I think Amnon has a point, shouldn't we change this change like below?
> > (on top of this fixlet).
> >
> > Oleg.
> >
> > --- x/arch/x86/kernel/hw_breakpoint.c
> > +++
Dear Steve,
> But here, there's no prejudice between tasks. All tasks will now hit the
> breakpoint regardless of if it is being traced or not.
Just to clarify, there is no intention to allow conventional breakpoints
in the vsyscall page - that would indeed be a disaster affecting all other
Dear Steve,
But here, there's no prejudice between tasks. All tasks will now hit the
breakpoint regardless of if it is being traced or not.
Just to clarify, there is no intention to allow conventional breakpoints
in the vsyscall page - that would indeed be a disaster affecting all other
On 11/19, Steven Rostedt wrote:
On Mon, 2012-11-19 at 18:47 +0100, Oleg Nesterov wrote:
Just I think Amnon has a point, shouldn't we change this change like below?
(on top of this fixlet).
Oleg.
--- x/arch/x86/kernel/hw_breakpoint.c
+++ x/arch/x86/kernel/hw_breakpoint.c
@@
On Tue, 2012-11-20 at 16:48 +0100, Oleg Nesterov wrote:
But here, there's no prejudice between tasks. All tasks will now hit the
breakpoint regardless of if it is being traced or not.
^^
This is hardware breakpoint, it is per-task.
I forgot that hw breakpoints are swapped out
On 11/20, Oleg Nesterov wrote:
On 11/19, Steven Rostedt wrote:
Is this really what we want?
I am not sure, that is why I am asking.
Yes.
And,
Well yes, with the new implementation __vsyscall_page simply does
syscall, so I guess (say) strace will just work. But, afaics, only
if
Hi Oleg,
Or. Perhaps we can define TRAP_VSYSCALL and change emulate_vsyscall() to
do
if (current-ptrace test_thread_flag(TIF_SYSCALL_TRACE))
send_sigtrap(TRAP_VSYSCALL, ...);
if it returns true?
I wish it were possible, but the vsyscall page is entered in user-mode,
On Mon, 2012-11-19 at 18:47 +0100, Oleg Nesterov wrote:
> On 11/09, Oleg Nesterov wrote:
> >
> > On 11/09, Oleg Nesterov wrote:
> > >
> > > Note: TASK_SIZE doesn't look right at least on x86, I think it should
> > > be replaced by TASK_SIZE_MAX.
> > > ...
> > > ---
On 11/09, Oleg Nesterov wrote:
>
> On 11/09, Oleg Nesterov wrote:
> >
> > Note: TASK_SIZE doesn't look right at least on x86, I think it should
> > be replaced by TASK_SIZE_MAX.
> > ...
> > --- x/arch/x86/kernel/hw_breakpoint.c
> > +++ x/arch/x86/kernel/hw_breakpoint.c
> > @@ -200,7 +200,7 @@ int
On 11/09, Oleg Nesterov wrote:
On 11/09, Oleg Nesterov wrote:
Note: TASK_SIZE doesn't look right at least on x86, I think it should
be replaced by TASK_SIZE_MAX.
...
--- x/arch/x86/kernel/hw_breakpoint.c
+++ x/arch/x86/kernel/hw_breakpoint.c
@@ -200,7 +200,7 @@ int
On Mon, 2012-11-19 at 18:47 +0100, Oleg Nesterov wrote:
On 11/09, Oleg Nesterov wrote:
On 11/09, Oleg Nesterov wrote:
Note: TASK_SIZE doesn't look right at least on x86, I think it should
be replaced by TASK_SIZE_MAX.
...
--- x/arch/x86/kernel/hw_breakpoint.c
+++
On 11/09, Oleg Nesterov wrote:
>
> Note: TASK_SIZE doesn't look right at least on x86, I think it should
> be replaced by TASK_SIZE_MAX.
> ...
> --- x/arch/x86/kernel/hw_breakpoint.c
> +++ x/arch/x86/kernel/hw_breakpoint.c
> @@ -200,7 +200,7 @@ int arch_check_bp_in_kernelspace(struct
> va =
arch_check_bp_in_kernelspace() tries to avoid the overflow and does 2
TASK_SIZE checks but it needs OR, not AND. Consider va = TASK_SIZE -1
and len = 2 case.
Note: TASK_SIZE doesn't look right at least on x86, I think it should
be replaced by TASK_SIZE_MAX.
Signed-off-by: Oleg Nesterov
---
arch_check_bp_in_kernelspace() tries to avoid the overflow and does 2
TASK_SIZE checks but it needs OR, not AND. Consider va = TASK_SIZE -1
and len = 2 case.
Note: TASK_SIZE doesn't look right at least on x86, I think it should
be replaced by TASK_SIZE_MAX.
Signed-off-by: Oleg Nesterov
On 11/09, Oleg Nesterov wrote:
Note: TASK_SIZE doesn't look right at least on x86, I think it should
be replaced by TASK_SIZE_MAX.
...
--- x/arch/x86/kernel/hw_breakpoint.c
+++ x/arch/x86/kernel/hw_breakpoint.c
@@ -200,7 +200,7 @@ int arch_check_bp_in_kernelspace(struct
va =
22 matches
Mail list logo