Re: [PATCH 0/3] UTRACE_DETACH fixes

2010-09-10 Thread Roland McGrath
I misunderstood the UTRACE_INTERRUPT without UTRACE_EVENT(QUIESCE) above as if you mean it is possible to get UTRACE_SIGNAL_REPORT without QUIESCE. No, I meant the opposite: since you won't get UTRACE_SIGNAL_REPORT without UTRACE_EVENT(QUIESCE), it might seem that UTRACE_INTERRUPT should not be

Re: [PATCH 0/3] UTRACE_DETACH fixes

2010-09-06 Thread Oleg Nesterov
On 09/03, Roland McGrath wrote: So, it is technically kosher enough to use UTRACE_INTERRUPT without UTRACE_EVENT(QUIESCE) set, if you really know the situation and are sure about all those caveats above. How? see below. I mentioned the examples. I misunderstood the

Re: [PATCH 0/3] UTRACE_DETACH fixes

2010-09-03 Thread Roland McGrath
Hmm. I am not sure I understand. If -report_signal != NULL, then you can't expect -report_quiesce() after utrace_control(INTERRUPT) ? Sorry, I used report_quiesce as shorthand for either report_quiesce, or report_signal with UTRACE_SIGNAL_REPORT. So, it is technically kosher enough to use

Re: [PATCH 0/3] UTRACE_DETACH fixes

2010-09-02 Thread Roland McGrath
But probably we need utrace_detached_ops-report_reap() anyway. -report_death can return UTRACE_DETACH, and after that utrace_report_death() can skip utrace_reset() and do -report_reap(). Yeah, that's a good point. There's no good reason to do a special case check for detached_ops there rather

Re: [PATCH 0/3] UTRACE_DETACH fixes

2010-09-02 Thread Oleg Nesterov
I was going to ping you ;) This is connected to the problem I hit today. Despite the fact I already complained about utrace_get_signal() QUIESCE, I forgot about this and figured out it doesn't work in practice. On 09/02, Roland McGrath wrote: If an engine used UTRACE_INTERRUPT without having

Re: [PATCH 0/3] UTRACE_DETACH fixes

2010-08-26 Thread Oleg Nesterov
On 08/19, Roland McGrath wrote: OK, instead of filling utrace_detached_ops{} we can change start_callback() - if (want UTRACE_EVENT(QUIESCE)) { + if ((want UTRACE_EVENT(QUIESCE)) || ops == detached_ops) { If we're going to have a special-case check for utrace_detached_ops,

Re: [PATCH 0/3] UTRACE_DETACH fixes

2010-08-17 Thread Oleg Nesterov
On 08/17, Oleg Nesterov wrote: Suppose that, say, engine-flags == UTRACE_EVENT(EXEC) (no QUIESCE). 1. start_callback() reads want = engine-flags (== EXEC) 2. mark_engine_detached() sets engine-ops = utrace_detached_ops 3. start_callback() gets ops = utrace_detached_ops

Re: [PATCH 0/3] UTRACE_DETACH fixes

2010-08-16 Thread Oleg Nesterov
On 08/16, Oleg Nesterov wrote: Well, I tried to test these changes, seems to work. But... From 2/3 changelog: This means that mark_engine_detached() can race with REPORT_CALLBACKS() but there is nothing new. Yes, there is nothing new. But, Roland, this is WRONG! With

Re: [PATCH 0/3] UTRACE_DETACH fixes

2010-08-16 Thread Roland McGrath
Whatever we do, start_callback() can see the old engine-flags but the new -ops = utrace_detached_ops. Just suppose that the caller of UTRACE_DETACH is interrupted right after setting engine-ops. * it can check the old flags before using the old ops, or check the old * flags before using the