Re: How to handle Clone/Fork/Exec when traceSyscall is true

[Sami Wagiaalla <swagiaal at redhat dot com>]

Hi Yao,

I have recently started working on systemcall tracing so i am not an 
expert but
i can answer some of your concerns :)
> At present(06/08/2006), to set tracing syscall, the Task requires that
> traceSyscall boolean be set to true.  When a task is continued via 
> sendContinue (), if the traceSyscall is true, PTRACE_SYSCALL is
> used instead of using PTRACE_CONT.
>   
I have changed that (although not committed yet). In my code the Task 
state machine
handles the transition into syscall tracing mode. The boolean has been 
eliminated
ptrace options are set when syscall states are entered, and all 
continues are replaced
with syscallContinues.
> The problem is that, take EXECVE syscall for example, the wait logic
> will deliver SyscallEvent(Enter EXECVE Syscall) before ExecedEvent, and
> then deliver SyscallEvent(Exit EXECVE Syscall), when traceSyscall is
> true.  In current Task State Machine, ExecedEvent could not be handled
> when StateMachine is in state "runningInSyscall".
>
> If I enable testI386Regs, and set task.traceSyscall to true, the error
> could be seen as follows,
>
> Time: 0.313
> There was 1 error:
> 1) testI386Regs(frysk.proc.TestI386Regs)java.lang.RuntimeException:
> {frysk.proc.LinuxTask@226870,pid=21048,tid=21048,state=runningInSyscall}
> in state "runningInSyscall" did not handle handleExecedEvent
>
> At first, I doubt that this problem is caused by Task State Machine,
> and try to override handleExecedEvent in runningInSyscall, and then I
> realize that it is not a good solution to this problem, so I give up
> on this way.
>   
Why is that not a good solution ?
> And then, according to the semantics of ExecedEvent and SyscallEvent,
> SyscallEvent is to notify when enter and exit Syscall(execve, in this
> case), while ExecEvent is to update the state of Child(Correct me if I
> am wrong), so both of them are right and necessary, but Frysk may be
> confused by the order of these events.
> If low-level wait logic could deliver SyscallEvents (Enter and Exit) 
> before ExecedEvent, Frysk could handle SyscallEvents to do notification
> and then handle ExecedEvent to update Child state without such error.
>
> The key point here is how and where to deliver the couple of
> SyscallEvents atomically, without permitting any other events are
> inserted between them.  IMO, Linux kernel is a candidate to achieve
> this, but I am not a guru in Linux kernel.  I am thinking how to put
> ExecedEvent after SyscallEvent(Exit a Syscall) in Frysk, but I could
> not reorder these two events in a reasonable way.  Any comments or
> advice on this?  Thanks in advance
Some one else might have a better answer to this but a general Frysk policy
is to try to not fake events, reorder them, or otherwise heavily alter 
what the
underlying primitives tell us. We try to be as 'honest' with the user as 
possible.
If nessecery we can create a 'postExecEvent' or change execEvent 
notification
to always use the exit of the exec syscall as its  cue.

Cheers,
 Sami