[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen: don't longjmp() after domain_crash() in check_wakeup_from_wait()



On 29.07.19 10:34, Andrew Cooper wrote:
On 29/07/2019 05:36, Juergen Gross wrote:
Continuing on the stack saved by __prepare_to_wait() on the wrong cpu
is rather dangerous.

Instead of doing so just call the scheduler again as it already is
happening in the similar case in __prepare_to_wait() when doing the
setjmp() would be wrong.

Signed-off-by: Juergen Gross <jgross@xxxxxxxx>

I'm afraid this is still problematic.  By successfully invoking the
waitqueue, we know that no spinlocks were held, but we have no guarantee
that e.g. an xmalloc()'d pointer is still only stashed in the stack.

But how are the domain_crash() invocations with following do_softirq()
calls in the __prepare_to_wait() case fine then? At the place where
either doing setjmp() or longjmp() it should be okay to throw away the
current stack, or otherwise there would be inconsistencies.

So either there is already a problem in the code regarding how the
domain crashing is done in __prepare_to_wait(), or my solution is just
fine, as it is just expanding the current behavior.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.