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
24 matches
Mail list logo
