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 <[email protected]>
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. The original behaviour of this code, on discovering a mismatched affinity, was to set the affinity back to what it should be and try again. The purpose of this is to try and ensure that we (eventually) can successfully longjmp() and unwind the stack. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
