Utrace .report_jctl serialization issue ?

[dave baukus]

Roland McGrath wrote on 11/11/2010 02:53 PM:
>> Is a utrace engine with .report_jctl enabled suppose to handle
>> do_notify_parent_cldstop(current, notify) processing for the last
>> stopping task ?  Or should it muck with task->ptrace to force
>> tracehook_notify_jctl() to return a non-zero value ?
>>      
> I can't figure out exactly how to construe this as a question about the
> utrace API.  The documented API is that each thread gets a report_jctl
> callback, and the @notify argument is zero in all threads but one.
>
>    
notify originates from do_signal_stop(); it is only non-zero when 
sig->group_stop_count is 1:
notify = sig->group_stop_count == 1 ? CLD_STOPPED : 0;

Herein lies the issue; becaues utrace_report_jctl()  release the lock, 
sig->group_stop_count may be
greater than 1 for all tasks as the execute the above line.

>> I ask because I have a simple multi-threaded process with a utrace engine
>> attached to the process group leader; .report_jctl is enabled.
>>      
> Do you mean the thread_group leader of one process in the process group?
> Or do you mean multiple utrace engines, one per thread, all in the process
> whose pid==pgid (that's what "process group leader" means in POSIX)?
>    
Sorry, old term from older RHEL task->group_leader;
The first task; it does not really matter.
>    
>> If I SIGTSTP the process, occasionally control is not returned to the
>> shell.
>>      
> That sounds like a kernel bug.  There should be nothing your report_jctl
> callback could do (assuming it doesn't send more signals itself) that
> affects the normal job control semantics.
>    
The bug comes about because utrace_report_jctl() releases the lock as 
detailed.
> The kernels that are appropriate to discuss here are upstream kernels with
> the current utrace patches applied (i.e. what you get in the current
> utrace-ptrace git branch), or the most recent Fedora kernels that should
> include that same code.  The code in question might well be the same in
> RHEL6 kernels, but RHEL issues need to be addressed through the proper RHEL
> support channels.  What we will help you with here is the current utrace
> development code.
>
> Perhaps Oleg and/or I will get time soon to look into this issue.
> Chances are better if you provide a test case in the form of a simple
> utrace module and a test scenario using it.
>
>
> Thanks,
> Roland
>
>    
I apologize for posting to the wrong forum.
If I get a chance I will post module and test case, but as you point out 
I am not on the correct code base for this forum.


Thank you for your time.
Dave