And. If we have multiple tracers, then utrace_control(SINGLESTEP) just
fools the caller, another engine can do utrace_control(RESUME) at any
moment.
Sure, but more likely nobody will.
I think you are right, utrace_control() should simply consider UTRACE_XXXSTEP
as UTRACE_REPORT.
All else
Btw, I believe we have another problem. utrace_control(SINGLESTEP) calls
user_enable_single_step() under utrace-lock. I don't really understand
the magic in enable_single_step() but is_setting_trap_flag() calls
access_process_vm(), this doesn't look good under spinlock.
Yes, this has been on
On 09/23, Roland McGrath wrote:
Hmm. Not sure how to fix this...
Well, one thing it can do is just punt them down to UTRACE_REPORT.
It's only a non-guaranteed optimization that these effects happen
directly from utrace_control() without being reinforced by a final
