There is at least one change from the earlier behaviour -- rather than
utrace_attach_task() retrying by itself on a !parent attach, -EAGAIN is
returned to the user. That may need changes to the utrace client side.
Oops, that was not intentional. I've restored the old behavior.
I've just
utrace_attach_task() checks -exit_state == EXIT_DEAD. Why? I mean,
how can it help, we don't hold any locks, target can change its
-exit_state right after the check.
Good catch, thanks. This is a remnant of the utrace-indirect code,
where utrace_first_engine() had an interlock with
what about get_utrace_lock() ? Do we really need the EXI_DEAD check?
And this check looks racy too.
It is not strictly necessary any more, no. It now serves as an early
unsynchronized check before taking the utrace lock, rather than as a
reliable interlock. The same is now true of the check
Roland McGrath roland at redhat.com writes:
Hi, Ananth. Sorry everything has slid so long (again).
(I have far too many hats and the past month not so many brains!)
Here is my immediate agenda for utrace hacking:
* I have incorporated the embed struct utrace changes.
I did various
i've been looking at the patch at the utrace.patch at:
http://people.redhat.com/roland/utrace/2.6-current/
hopefully, that's the latest one.
Yes, it's updated frequently. The .id files tell you what git commit the
patch corresponds to, so we can be mutually clear in making references.
