In D10477#217696, @royger wrote:

In any case, the patch is incorrect, there's a race. Consider the following scenario:

1. User-space program calls write on the xenstore-device.
2. xs_is_locked returns false.
3. Suspend procedure is started, thus calling xs_lock.
4. User-space syscall continues and calls into xs_dev_request_and_reply.
5. Deadlock again.

There's a window between the xs_is_locked call and the actual xs_lock call, which makes this approach racy. I've already commented this when this patch was originally submitted.

In D10477#217228, @royger wrote:

I've asked several times before requesting the EN that you test stable/10, stable/11 and HEAD to make sure they where working fine, and I was told that everything was working fine and that all issues where fixed, yet here we are, we requested a set of ENs and it's still not working properly.

I've also already told you that I don't think this is correct, it might mitigate the issue you are seeing, but I don't think it's fixing it in any way.

Why does stop_all_proc() block? in xctrl_suspend stop_all_proc is called _before_ suspending xenstore, how can it block? Is there a thread blocked in xs_talkv trying to lock the xenstore lock, and that's preventing it from suspending?