Change ptrace_traceme() to use the new helpers. Kill the now unused
prepare_ptrace_attach/finish_ptrace_attach.
finish_ptrace_attach(ret) logic was wrong. If -parent has PF_EXITING
we must UTRACE_DETACH but ret == 0. Fix this.
Note: we attach the new engine unconditionally, before security
Introduce the empty struct ptrace_context, change ptrace_attach_task()
to setup engine-data.
It should be used for ptrace_set_action() and ptrace_set_stop_event(),
the current usage of -ptrace is racy.
Also, -exit_code and -last_siginfo should live in engine-data too.
Eventually, all
On 08/14, Roland McGrath wrote:
- minor, but it is possible that tracehook_notify_jctl() will
be called before tracehook_get_signal(). Not a real problem,
but shouldn't UTRACE_STOP mean stop as soon as possible ?
No. It means stop before this thread can newly cause any
Does this mean you intend to abandon the ptrace-revamp draft series that
added ptrace_context et al cleanups in the pre-utrace code? Or are you
culling bits from there to integrate differently now?
It should be used for ptrace_set_action() and ptrace_set_stop_event(),
the current usage of
I merged 7 and 8. My review comments on these are just to raise things to
think about between now and the final form. I don't intend them to slow
down the progress of your current hacking.
Thanks,
Roland
In-Reply-To: Oleg Nesterov's message of Monday, 17 August 2009 17:31:23 +0200
20090817153123.ga10...@redhat.com
References: 20090811145211.ga30...@linux.vnet.ibm.com
20090811172310.ga14...@redhat.com
20090811213739.ea81a42...@magilla.sf.frob.com
Now. we should make sure that every user of UTRACE_DETACH frees
engine-data. And, we have to introduce ptrace_report_reap() which
should free it too.
Right, or you can have a report_death callback (or even just report_quiesce
when passed UTRACE_EVENT(DEATH)) that always detaches. In that
