In D10477#217696, @royger wrote:In any case, the patch is incorrect, there's a race. Consider the following scenario:
- User-space program calls write on the xenstore-device.
- xs_is_locked returns false.
- Suspend procedure is started, thus calling xs_lock.
- User-space syscall continues and calls into xs_dev_request_and_reply.
- 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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Apr 28 2017
Apr 28 2017
ouyangzhaowei_huawei.com added a comment to D10477: avoid deadlock between suspend and a user space process.
Apr 25 2017
Apr 25 2017
ouyangzhaowei_huawei.com added a comment to D10477: avoid deadlock between suspend and a user space process.
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?
Apr 24 2017
Apr 24 2017