Just to complete the previous discussion.
Alternatively, we could just fix utrace_stop() to always check
fatal_signal_pending() before return.
But personally I think that report-killed buys nothing, but adds
some complexity to the code.
Perhaps, utrace_stop() should return true if we really
finish_utrace_stop() can check for pending SIGKILL lockless,
ant it can use __fatal_signal_pending() helper.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
--- __UTRACE/kernel/utrace.c~1_FINISH_FATAL_SIGNAL
Kill utrace_report-killed and change the only user, utrace_get_signal(),
to use fatal_signal_pending().
Similarly, change utrace_report_syscall_entry(), noe it is the only caller
of utrace_stop() which checks the returned value.
The boolean returned by utrace_stop()-finish_utrace_stop() is not
- Nobody uses the (inaccurate) value returned by utrace_stop(), change it
to return void.
- use fatal_signal_pending() instead of sigismember(SIGKILL).
- finish_utrace_stop() becomes really trivial, it just clears -stopped.
Fold it into utrace_stop().
Signed-off-by: Oleg Nesterov
Good Day,
We wish to notify you again that you were listed as a beneficiary to
the total sum of 6,000,000.00 GBP (Six Million British Pounds) in the
codicil and last testament of the deceased. (Name now withheld since
this is our second letter to you).
We contacted you because you bear the
On 07/23, Oleg Nesterov wrote:
On 07/22, Roland McGrath wrote:
Who will kfree() engine-data ?
sys_ptrace(PTRACE_DETACH) can do this. But what if the tracer exits
and detaches? Or release_task() does untrace.
All of these are some ptrace.c path that has to use UTRACE_DETACH,
Btw. Roland, unless utrace_get_signal() does dequeue_signal(info),
we pass a random value in info-si_signo to -report_signal().
Yes, _if_ I understand correctly, report_signal can check action,
but perhaps it makes sense to set -si_signo = 0, this may help to
engine writers.
This is really
Because you forgot to add QUIESCE to utrace_set_events's mask !!!
D'oh!
Perhaps it makes sense to have utrace_control() fail with -EINVAL or
something when you try anything but RESUME or DETACH when you do not have
UTRACE_EVENT(QUIESCE) set.
Thanks,
Roland
Agreed, this looks like a right change to me. In any case I think this makes
the code more understandable and logical, and -resume_action is much better
than -reports imho.
Ok.
But, you seem to forget to fix other callers of utrace_stop(),
Yes, it was not a complete patch, just to get your
Hmm. I think this is not exacly right. Suppose that
report-action == UTRACE_INTERRUPT but utrace-interrupt is already set.
In that case, since UTRACE_INTERRUPT = UTRACE_REPORT, we set -report.
Not really bad, but not right anyway.
Ah, true. It enables harmless but superfluous work.
I've
Alternatively, we could just fix utrace_stop() to always check
fatal_signal_pending() before return.
I don't think it makes sense to roll in the check and have a return value
for it unless either it's doing important synchronization there, or every
caller needs the check.
Oh, but it does
Oh, I misremembered the difference between fatal_signal_pending() and
__fatal_signal_pending(), was thinking it had to do with siglock.
I've merged all three patches now.
Thanks,
Roland
12 matches
Mail list logo
