My initial opinion was that you were moving away from RCU to also rid
the task_struct-utrace assertion failure, which IIRC from some of the
investigations at the time, were mostly for RCU lifetime reasons.
That assertion failure (BUG_ON) was due to an internal bug.
It was entirely for buggy
Yes!
[...]
What is the use case for a utrace client to do a utrace_engine_get/put()?
Wouldn't it be more robust if utrace implicitly handles refcounts as
you've detailed below?
If the only operations that affect this count are implicit, then I assume
you must mean those are attach and detach.
On Tue, Aug 05, 2008 at 07:20:42PM -0700, Roland McGrath wrote:
Yes!
[...]
What is the use case for a utrace client to do a utrace_engine_get/put()?
Wouldn't it be more robust if utrace implicitly handles refcounts as
you've detailed below?
If the only operations that affect this count
Something that's always been an issue in the utrace interface is the
management of struct utrace_attached_engine. It's tricky that you have to
use RCU and/or follow picayune rules in the attach+set_events-callbacks
sequence to be sure your engine pointer is valid. From the beginning, I
expected
