[PATCH 3/4] utrace_set_events: fix UTRACE_EVENT(REAP) case

Roland McGrath roland at redhat.com
Tue Aug 17 00:13:08 UTC 2010


> 	- It is possible that both ->death and ->reap are true. In this
> 	  case it is OK to clear UTRACE_EVENT(REAP), but set_events fails.

No, it's not OK to clear it.  Once ->reap is set, then the engine's
ops->report_reap might or might not have been called already.  If
utrace_set_events() returns 0, then it's claiming a guarantee that the
clearing of the bit took effect and no callback can be made.  

The only way it could be reliable in practice is if the caller is inside
the report_death callback or synchronizing with it.  In that situation,
the engine should just return UTRACE_DETACH from its report_death callback.

> 	- OTOH, if ->reap is true, set_events disallows "clear" but allows
> 	  "set", the latter case should be forbidden too.
> 
> 	  If utrace_set_events(UTRACE_EVENT(REAP)) succeeds, the caller
> 	  has all rights to expect ->report_reap() will be caller later.

Correct.

> If you take this patch, then please consider the next one.

Ok.


Thanks,
Roland




More information about the utrace-devel mailing list