On 01/14, u3...@miso.sublimeip.com wrote:
>
> So here again is the patch that I need so badly - clearly it fixes a bug
> and harms nobody:
>
> ---
> diff -Naur before/arch/x86/kernel/hw_breakpoint.c
>
On 01/14, u3...@miso.sublimeip.com wrote:
So here again is the patch that I need so badly - clearly it fixes a bug
and harms nobody:
---
diff -Naur before/arch/x86/kernel/hw_breakpoint.c
Hi,
> I would not say this is a bug but let me repeat, no need to convince me.
>
> Please feel free to re-send the patch(es) I sent to maintainers. Sorry,
> I can't push these changes into Linus's tree.
So here again is the patch that I need so badly - clearly it fixes a bug
and harms nobody:
Hi,
I would not say this is a bug but let me repeat, no need to convince me.
Please feel free to re-send the patch(es) I sent to maintainers. Sorry,
I can't push these changes into Linus's tree.
So here again is the patch that I need so badly - clearly it fixes a bug
and harms nobody:
On 01/10, u3...@miso.sublimeip.com wrote:
>
> Hi Everyone,
>
> > On 01/08, Pedro Alves wrote:
> >>
> >> On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
> >>
> >> > But If we want to allow to trace vsyscall's, hw bp doesn't look very
> >> > nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace
On 01/10, u3...@miso.sublimeip.com wrote:
Hi Everyone,
On 01/08, Pedro Alves wrote:
On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
But If we want to allow to trace vsyscall's, hw bp doesn't look very
nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.
Hi Everyone,
> On 01/08, Pedro Alves wrote:
>>
>> On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
>>
>> > But If we want to allow to trace vsyscall's, hw bp doesn't look very
>> > nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.
>>
>> Irrespective of the whole syscall tracing
On 01/08, Pedro Alves wrote:
>
> On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
>
> > But If we want to allow to trace vsyscall's, hw bp doesn't look very
> > nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.
>
> Irrespective of the whole syscall tracing issue, allowing HW bkpts
On 01/08, Pedro Alves wrote:
On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
But If we want to allow to trace vsyscall's, hw bp doesn't look very
nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.
Irrespective of the whole syscall tracing issue, allowing HW bkpts in
the
Hi Everyone,
On 01/08, Pedro Alves wrote:
On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
But If we want to allow to trace vsyscall's, hw bp doesn't look very
nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.
Irrespective of the whole syscall tracing issue, allowing HW
On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
> But If we want to allow to trace vsyscall's, hw bp doesn't look very
> nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.
Irrespective of the whole syscall tracing issue, allowing HW bkpts in
the vsyscall just seems like a bug fix
On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
But If we want to allow to trace vsyscall's, hw bp doesn't look very
nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.
Irrespective of the whole syscall tracing issue, allowing HW bkpts in
the vsyscall just seems like a bug fix
Dear Jan,
> x86 debug registers are already very scarce. Besides that userland
> applications know they have 4 of them available so it would also break
> them.
If a userland application wants to cheat, then it has no need to bypass
the debug registers: even if there were 4096 of them, covering
On Sun, 02 Dec 2012 20:30:58 +0100, Oleg Nesterov wrote:
> Yes, that is why I said this needs the new option.
I do not mind new options although personally I do not find them meaningful
for an already deprecated ABI compatibility-only issue.
> If the tracer does PTRACE_SYSCALL the tracee
On Sun, 02 Dec 2012 20:30:58 +0100, Oleg Nesterov wrote:
Yes, that is why I said this needs the new option.
I do not mind new options although personally I do not find them meaningful
for an already deprecated ABI compatibility-only issue.
If the tracer does PTRACE_SYSCALL the tracee reports
Dear Jan,
x86 debug registers are already very scarce. Besides that userland
applications know they have 4 of them available so it would also break
them.
If a userland application wants to cheat, then it has no need to bypass
the debug registers: even if there were 4096 of them, covering the
Dear Oleg,
> Yes, I understand, so DR_RW_EXECUTE should probably work. And I even
> sent the patch (untested/uncompiled). But given that even the simple
> bugfix which started this thread was ignored by maintainers, I am
> not sure how we can convince them this change makes sense ;)
Just to
On 12/03, u3...@miso.sublimeip.com wrote:
>
> > However. Of course it would be nice to avoid the new option. IMO it
> > would be better to do nothing ;) vsyscall is deprecated, and EMULATE
> > is x86-specific.
>
> The problem is that the current static glibc invokes the vsyscall page,
Yes I know.
On 12/03, u3...@miso.sublimeip.com wrote:
However. Of course it would be nice to avoid the new option. IMO it
would be better to do nothing ;) vsyscall is deprecated, and EMULATE
is x86-specific.
The problem is that the current static glibc invokes the vsyscall page,
Yes I know.
Still
Dear Oleg,
Yes, I understand, so DR_RW_EXECUTE should probably work. And I even
sent the patch (untested/uncompiled). But given that even the simple
bugfix which started this thread was ignored by maintainers, I am
not sure how we can convince them this change makes sense ;)
Just to confirm,
Hi Oleg,
> However. Of course it would be nice to avoid the new option. IMO it
> would be better to do nothing ;) vsyscall is deprecated, and EMULATE
> is x86-specific.
The problem is that the current static glibc invokes the vsyscall page,
so statically-linked 3rd-party executables that were
Amnon, sorry for delay...
On 11/26, Amnon Shiloh wrote:
>
> > Why do you need to _prevent_, say, sys_gettimeofday()? Why we can't
> > change emulate_vsyscall() to respect PTRACE_SYSCALL and report
> > TRAP_VSYSCALL or PTRACE_EVENT_VSYSCALL as I tried to suggest in
> >
Amnon, sorry for delay...
On 11/26, Amnon Shiloh wrote:
Why do you need to _prevent_, say, sys_gettimeofday()? Why we can't
change emulate_vsyscall() to respect PTRACE_SYSCALL and report
TRAP_VSYSCALL or PTRACE_EVENT_VSYSCALL as I tried to suggest in
Hi Oleg,
However. Of course it would be nice to avoid the new option. IMO it
would be better to do nothing ;) vsyscall is deprecated, and EMULATE
is x86-specific.
The problem is that the current static glibc invokes the vsyscall page,
so statically-linked 3rd-party executables that were
On Mon, Nov 26, 2012 at 11:55:01PM +1100, Amnon Shiloh wrote:
>
> You could of course keep that old code and modify only the very
> first instruction of each routine into a jump instruction, but then
> the code to which the process returns may not be compatible with
> the new kernel and/or
Hi Andrey,
So what do you do if a catched interrupt occured inside vdso code?
You can easily detect that the task is currently in vdso code,
then delay its dump, but how do you detect whether a sigreturn()
or even a series of sigreturn()s won't bring it back to the middle
of some old vdso code?
2012/11/26 Cyrill Gorcunov :
> On Thu, Nov 22, 2012 at 05:12:38PM +0100, Oleg Nesterov wrote:
>> On 11/22, Amnon Shiloh wrote:
>> >
>> > Now however, that "vsyscall" was effectively replaced by vdso, it
>> > creates a new problem for me and probably for anyone else who uses
>> > some form of
On Thu, Nov 22, 2012 at 05:12:38PM +0100, Oleg Nesterov wrote:
> On 11/22, Amnon Shiloh wrote:
> >
> > Now however, that "vsyscall" was effectively replaced by vdso, it
> > creates a new problem for me and probably for anyone else who uses
> > some form of checkpoint/restore:
>
> Oh, sorry, I
On Thu, Nov 22, 2012 at 05:12:38PM +0100, Oleg Nesterov wrote:
On 11/22, Amnon Shiloh wrote:
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of checkpoint/restore:
Oh, sorry, I can't help here.
2012/11/26 Cyrill Gorcunov gorcu...@openvz.org:
On Thu, Nov 22, 2012 at 05:12:38PM +0100, Oleg Nesterov wrote:
On 11/22, Amnon Shiloh wrote:
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of
Hi Andrey,
So what do you do if a catched interrupt occured inside vdso code?
You can easily detect that the task is currently in vdso code,
then delay its dump, but how do you detect whether a sigreturn()
or even a series of sigreturn()s won't bring it back to the middle
of some old vdso code?
On Mon, Nov 26, 2012 at 11:55:01PM +1100, Amnon Shiloh wrote:
You could of course keep that old code and modify only the very
first instruction of each routine into a jump instruction, but then
the code to which the process returns may not be compatible with
the new kernel and/or hardware
Hi Oleg,
> > 2) I was then told (in my own words): "oh, don't worry, the vsyscall page
> >has now been minimized, all it contains now is *real* system calls,
> >and it always calls them".
>
> Not sure where did you get this idea ;) From the very beginning you were
> told that EMULATE
On 11/25, Amnon Shiloh wrote:
>
> 2) I was then told (in my own words): "oh, don't worry, the vsyscall page
>has now been minimized, all it contains now is *real* system calls,
>and it always calls them".
Not sure where did you get this idea ;) From the very beginning you were
told that
On 11/25, Amnon Shiloh wrote:
2) I was then told (in my own words): oh, don't worry, the vsyscall page
has now been minimized, all it contains now is *real* system calls,
and it always calls them.
Not sure where did you get this idea ;) From the very beginning you were
told that EMULATE
Hi Oleg,
2) I was then told (in my own words): oh, don't worry, the vsyscall page
has now been minimized, all it contains now is *real* system calls,
and it always calls them.
Not sure where did you get this idea ;) From the very beginning you were
told that EMULATE mode doesn't
Hi Oleg,
This patch may look ugly, but it is one way to solve my problem.
This way, "strace" too, which is broken since the introduction of
the vsyscall page, will again be able to report when the program
calls "time()" or "gettimeofday()" - currently it cannot!
I think that allowing to set the
Hi Oleg,
> Hello Amnon,
>
> I am a bit confused,
So let's get things in order.
1) I asked for the ability to set hardware breakpoints on the vsyscall
page (x86 debug registers), so that the ptracer can stop the process
whenever it attempts to jump there, then the ptracer can emulate
Hi Oleg,
Hello Amnon,
I am a bit confused,
So let's get things in order.
1) I asked for the ability to set hardware breakpoints on the vsyscall
page (x86 debug registers), so that the ptracer can stop the process
whenever it attempts to jump there, then the ptracer can emulate those
Hi Oleg,
This patch may look ugly, but it is one way to solve my problem.
This way, strace too, which is broken since the introduction of
the vsyscall page, will again be able to report when the program
calls time() or gettimeofday() - currently it cannot!
I think that allowing to set the x86
On 11/23, Pavel Emelyanov wrote:
>
> On 11/22/2012 08:12 PM, Oleg Nesterov wrote:
>
> > Sure. You shouldn't try to save/restore this page(s) directly. But
> > I do not really understand why do you need. IOW, I don't really
> > understand the problem, it depends on what c/r actually does.
>
> Think
forgot to mention...
On 11/23, Oleg Nesterov wrote:
>
> On 11/23, Amnon Shiloh wrote:
> >
> > Or, there is an alternative: if only I (the ptracer or the traced process)
> > was allowed to munmap the vsyscall page,
>
> It is not possible to unmap it. The kernel (swapper_pg_dir) has this
> mapping,
Hello Amnon,
I am a bit confused,
On 11/23, Amnon Shiloh wrote:
>
> What I discovered now, is that PTRACE_SYSCALL (also PTRACE_SINGLESTEP)
> does not work within the vsyscall page, so I cannot trap the kernel-calls
> there (this is very simple to verify using "gdb" or "strace").
Sure, but we
Dear Oleg,
After the detour into the VDSO page, which is really a separate issue,
but one which I was able to work around in user-mode (for my particular
needs, not yet for all others who write checkpoint/restore pacakges),
I am sad to report that despite my previous post, the "vsyscall" problem
Dear Oleg,
After the detour into the VDSO page, which is really a separate issue,
but one which I was able to work around in user-mode (for my particular
needs, not yet for all others who write checkpoint/restore pacakges),
I am sad to report that despite my previous post, the vsyscall problem
Hello Amnon,
I am a bit confused,
On 11/23, Amnon Shiloh wrote:
What I discovered now, is that PTRACE_SYSCALL (also PTRACE_SINGLESTEP)
does not work within the vsyscall page, so I cannot trap the kernel-calls
there (this is very simple to verify using gdb or strace).
Sure, but we alredy
forgot to mention...
On 11/23, Oleg Nesterov wrote:
On 11/23, Amnon Shiloh wrote:
Or, there is an alternative: if only I (the ptracer or the traced process)
was allowed to munmap the vsyscall page,
It is not possible to unmap it. The kernel (swapper_pg_dir) has this
mapping, not the
On 11/23, Pavel Emelyanov wrote:
On 11/22/2012 08:12 PM, Oleg Nesterov wrote:
Sure. You shouldn't try to save/restore this page(s) directly. But
I do not really understand why do you need. IOW, I don't really
understand the problem, it depends on what c/r actually does.
Think about it
On 11/22/2012 08:12 PM, Oleg Nesterov wrote:
> On 11/22, Amnon Shiloh wrote:
>>
>> Now however, that "vsyscall" was effectively replaced by vdso, it
>> creates a new problem for me and probably for anyone else who uses
>> some form of checkpoint/restore:
>
> Oh, sorry, I can't help here. I can
On 11/22, Amnon Shiloh wrote:
>
> Now however, that "vsyscall" was effectively replaced by vdso, it
> creates a new problem for me and probably for anyone else who uses
> some form of checkpoint/restore:
Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they
seem to enjoy trying to
On 11/22, Amnon Shiloh wrote:
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of checkpoint/restore:
Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they
seem to enjoy trying to solve
On 11/22/2012 08:12 PM, Oleg Nesterov wrote:
On 11/22, Amnon Shiloh wrote:
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of checkpoint/restore:
Oh, sorry, I can't help here. I can only add Cyrill
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 =
74 matches
Mail list logo
