On 08/18, Roland McGrath wrote:
Unfortunately, this doesn't help if a module doesn't use utrace_control()
but just returns UTRACE_SINGLESTEP/etc. Like Srikar's test-case does.
Yes. I thought about adding a WARN_ON or something. But I think it would
just wind up being confusing or
On 08/17, Roland McGrath wrote:
@@ -1033,6 +1042,18 @@ int utrace_control(struct task_struct *target,
if (unlikely(action UTRACE_DETACH))
return -EINVAL;
+ /*
+ * This is a sanity check for a programming error in the caller.
+ * Their request can only
(I've dropped Srikar's address from the CC since it bounces.
I hope he's reading the list.)
Unfortunately, this doesn't help if a module doesn't use utrace_control()
but just returns UTRACE_SINGLESTEP/etc. Like Srikar's test-case does.
Yes. I thought about adding a WARN_ON or something. But
Hi -
[...] I'm not sure what you mean here about always correct. It is
always correct that you should not use UTRACE_SINGLESTEP without
setting up a callback. [...]
I wonder if utrace could be more helpful here. If an engine just
wants to single-step from some other callback, forcing it to
I wonder if utrace could be more helpful here. If an engine just
wants to single-step from some other callback, forcing it to have a
quiesce callback just to re-re-re-repeat what it already asked for
seems like make-work. Could utrace instead remember the last
instruction received either
In-Reply-To: Oleg Nesterov's message of Monday, 17 August 2009 17:31:23 +0200
20090817153123.ga10...@redhat.com
References: 20090811145211.ga30...@linux.vnet.ibm.com
20090811172310.ga14...@redhat.com
20090811213739.ea81a42...@magilla.sf.frob.com
