The former is e.g. PTRACE_SINGLESTEP while an unrelated engine uses
UTRACE_EVENT(SYSCALL_ENTRY). The ptrace engine's report_quiesce returns
UTRACE_SINGLESTEP. finish_resume_report() calls user_enable_single_step().
That seems fine. Right?
In this case ptrace_report_quiesce(event)
On 11/18, Roland McGrath wrote:
Hmm. not sure I understand how this can work. I mean, this won't
enable stepping (in this particular case we are discussing).
I might be confused. I'm thinking of two cases: the report_syscall_entry
pass yields UTRACE_SINGLESTEP, or that it yields
On 11/18, Roland McGrath wrote:
Once again. The tracee sleeps in SYSCALL_ENTER. The tracer resumes
the tracee via utrace_control(UTRACE_SINGLESTEP).
Right. This is another strange corner. It doesn't necessarily make
especially good sense intrinsically for single-step to have this meaning
I'll reply tomorrow, it is to late for me.
But I noticed the funny detail in your email,
On 11/18, Roland McGrath wrote:
Yes. But, hmm.
utrace_stop(task, utrace, UTRACE_RESUME); /* XXX */
This XXX was there about passing UTRACE_RESUME, because that's not really
right.
I
On 11/16, Roland McGrath wrote:
Whatever temporary hacks are fine by me one way or the other.
They will just be coming out later along with assorted other cleanup.
We certainly do want to get this right in the utrace layer.
Yes. But imho it is always good to test/review the patches against
Just in case, forgot to clarify...
On 11/16, Oleg Nesterov wrote:
With this patch make check passes all tests again (to clarify, except
some tests which upstream doesn't pass too), including this one:
with this patch +
[HACK] utrace: fix utrace_resume()-finish_resume_report() logic
And I
On 11/16, Oleg Nesterov wrote:
And I didn't check make xcheck, I guess it still crashes the kernel.
Yes it does. I am almost sure the bug should be trivial, but
somehow can't find find it. Just fyi, to ensure this is connected
to utrace-indirect I applied the hack below and the bug goes away.
Whatever temporary hacks are fine by me one way or the other.
They will just be coming out later along with assorted other cleanup.
We certainly do want to get this right in the utrace layer.
The change we talked about before seems simple enough and should cover this
without new kludges in the
Yes it does. I am almost sure the bug should be trivial, but
somehow can't find find it. Just fyi, to ensure this is connected
to utrace-indirect I applied the hack below and the bug goes away.
Does s/kmem_cache_zalloc/kzalloc/ really have anything to do with it?
Isn't it just the allocation
