Hi Roland,
Thanks for the quick patch.
> I think this might be the right fix. First, we change the order so that
> UTRACE_INTERRUPT prevails over UTRACE_REPORT. (I'm really not sure why I
> ever had it the other way around.) Next, we keep track of not only whether
> one engine wanted a report when another wanted stop, but of the prevailing
> resume action (i.e. least value still > UTRACE_STOP). After stopping and
> resuming, we apply UTRACE_INTERRUPT or UTRACE_REPORT as needed to make sure
> we get the kind of resume report we need.
I applied your patch. However it doesnt seem to fix the problem.
i.e I see the program still continuing with resume and I dont see any
more callbacks being made.
----------------------------------------------------------------------
In probe5_a init_module
In probe5_b init_module
In probe5_a engine_a_report_signal ffff880206ef9708 signr=5 action=35 ret=10
In probe5_a engine_a_report_signal ffff880206ef9948 signr=5 action=10 ret=13
In probe5_a cleanup_module
---------------------------------------------------------------------
--
Thanks and Regards
Srikar
PS: Changes in probe5_a and probe5_b are
1. remove duplicate print statements in report_signal callbacks.
2. cache the return from report_signal and use it with
utrace_resume_action in report_quiesce.
i.e
static u32 engine_a_report_quiesce(enum utrace_resume_action action,
struct utrace_engine *engine,
struct task_struct *tsk,
unsigned long event)
{
printk(KERN_INFO "In engine_a_report_quiesce with quiesce_action=%x\n",
quiesce_action);
return utrace_resume_action(quiesce_action);
}
* Roland McGrath <rol...@redhat.com> [2009-08-11 14:37:39]:
