Merging ptrace branch into mainline

Merging ptrace branch into mainline

[Tejun Heo]

Hello,

Most of the changes that I had on mind when I wrote "Proposal for
ptrace improvements"[1] seem complete.  The details of course changed
quite a bit during implementation iterations but AFAICS all the
features and fixes described in the propsal are now in Oleg's tree
waiting to be pulled into mainline.  New features are still blocked by
the DEVEL flag indicating the API is not finalized yet and should be
used only for developement.

Remaining issues are

* Two different modes of trap notification - directly ptrace_notify()
  and force_sig(SIGTRAP), which makes SIGTRAP special w.r.t. ptrace.

  There are two alternatives.  One is converting SIGTRAP notifications
  into (async) ptrace_notify() notifications.  The other is to leave
  it alone and just declare that SIGTRAP indeed is special and
  userland programs playing with SIGTRAP won't behave transparently
  while ptraced.

  I haven't really looked at it too much but am currently leaning
  towards the latter.

* Somewhat related.  Some part of ptrace, especially breakpoint and
  singlestep handling, is more arch-specific than necessary and archs
  diverged on what is reported how.  Most of this should be unifiable
  or at least categorized.

Neither is very critical and we shouldn't be introducing drastic
userland visible behavior differences no matter which way we choose,
but given that this isn't an urgent thing, I think it would be best to
merge the pending ptrace changes with the DEVEL blocking enabled for
3.1, so that we can have more time settling down things and hopefully
seeing how it works with actual userland usage.

What do you guys think?

Thank you.

-- 
tejun

[1] http://thread.gmane.org/gmane.linux.kernel/1107045

Re: Merging ptrace branch into mainline

[Denys Vlasenko]

On Fri, Jul 22, 2011 at 12:30 PM, Tejun Heo <tj@kernel.org> wrote:
> Hello,
>
> Most of the changes that I had on mind when I wrote "Proposal for
> ptrace improvements"[1] seem complete.  The details of course changed
> quite a bit during implementation iterations but AFAICS all the
> features and fixes described in the propsal are now in Oleg's tree
> waiting to be pulled into mainline.  New features are still blocked by
> the DEVEL flag indicating the API is not finalized yet and should be
> used only for developement.
>
> Remaining issues are
>
> * Two different modes of trap notification - directly ptrace_notify()
>  and force_sig(SIGTRAP), which makes SIGTRAP special w.r.t. ptrace.

To what cases of ptrace stops is this applicable?

I thought with PTRACE_O_TRACESYSGOOD the problem with SIGTRAP
being special under strace is dealt with: now both user-sent
SIGTRAPs and ones generated by int3 instruction are handled correctly
in current strace git.

Is it about single-stepping? Strace doesn't use PTRACE_SIGLESTEP,
and I didn't have the need yet to familiarize myself with it.
Does it generate SIGTRAP?

-- 
vda

Re: Merging ptrace branch into mainline

[Tejun Heo]

On Fri, Jul 22, 2011 at 01:40:36PM +0200, Denys Vlasenko wrote:
> On Fri, Jul 22, 2011 at 12:30 PM, Tejun Heo <tj@kernel.org> wrote:
> To what cases of ptrace stops is this applicable?
> 
> I thought with PTRACE_O_TRACESYSGOOD the problem with SIGTRAP
> being special under strace is dealt with: now both user-sent
> SIGTRAPs and ones generated by int3 instruction are handled correctly
> in current strace git.
> 
> Is it about single-stepping? Strace doesn't use PTRACE_SIGLESTEP,
> and I didn't have the need yet to familiarize myself with it.
> Does it generate SIGTRAP?

Single step and breakpoints use SIGTRAP and there are some variances
on the information being reported depending on archs and IIRC it isn't
always possible to discern those debug traps from kill(SIGTRAP)'s from
userland.  I think cleaning up what information is reported via
siginfo on debug traps should resolve this too.

Thansk.

-- 
tejun

Re: Merging ptrace branch into mainline

[Oleg Nesterov]

On 07/22, Tejun Heo wrote:
>
> Single step and breakpoints use SIGTRAP and there are some variances
> on the information being reported depending on archs and IIRC it isn't
> always possible to discern those debug traps from kill(SIGTRAP)'s from
> userland.

Yes, we should audit the arch/ code.

On x86 the tracer can discern step/breakpoints traps afaics, still probably
it makes sense to change do_int3() to use fill_sigtrap_info(). Currently we
report si_code = SI_KERNEL.

Oleg.