On 04/17, Frederic Weisbecker wrote:
>
> 2013/4/16 Oleg Nesterov :
> >
> > Well, I disagree.
> >
> > To clarify, I agree with WARN_ON_ONCE(), but afaics it has nothing to
> > do with "second_pass",
> >
> >> And these are indeed supposed
> >> to.
> >
> > Indeed, but this is because ptrace_modify_bre
2013/4/16 Oleg Nesterov :
> On 04/16, Frederic Weisbecker wrote:
>> > rc = ptrace_modify_breakpoint(bp, len, type, tsk, disabled);
>> > if (rc)
>> > break;
>>
>> It would be nice to warn here:
>>
>>WARN_ON_ONCE(rc && second_pass);
>
> Well, I disagree
On 04/16, Frederic Weisbecker wrote:
>
> On Sun, Apr 14, 2013 at 09:12:32PM +0200, Oleg Nesterov wrote:
> > ptrace_write_dr7() skips ptrace_modify_breakpoint(disabled => true)
> > unless second_pass, this buys nothing but complicates the code and
> > means that we always do the main loop twice even
On Sun, Apr 14, 2013 at 09:12:32PM +0200, Oleg Nesterov wrote:
> ptrace_write_dr7() skips ptrace_modify_breakpoint(disabled => true)
> unless second_pass, this buys nothing but complicates the code and
> means that we always do the main loop twice even if "disabled" was
> never true.
>
> The comme
ptrace_write_dr7() skips ptrace_modify_breakpoint(disabled => true)
unless second_pass, this buys nothing but complicates the code and
means that we always do the main loop twice even if "disabled" was
never true.
The comment says:
Don't unregister the breakpoints right-away,
unle
5 matches
Mail list logo