Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spec issue: potential deadlocks in concurrent messages and replies #466

Open
jlevon opened this issue May 5, 2021 · 4 comments
Open

spec issue: potential deadlocks in concurrent messages and replies #466

jlevon opened this issue May 5, 2021 · 4 comments

Comments

@jlevon
Copy link
Collaborator

jlevon commented May 5, 2021

From Stefan:

> Are there rules for avoiding deadlock between client->server and
> server->client messages? For example, the client sends
> VFIO_USER_REGION_WRITE and the server sends VFIO_USER_VM_INTERRUPT
> before replying to the write message.
> 
> Multi-threaded clients and servers could end up deadlocking if messages
> are processed while polling threads handle other device activity (e.g.
> I/O requests that cause DMA messages).
> 
> Pipelining has the nice effect that the oldest message must complete
> before the next pipelined message starts. It imposes a maximum issue
> depth of 1. Still, it seems like it would be relatively easy to hit
> re-entrancy or deadlock issues since both the client and the server can
> initiate messages and may need to wait for a response.
@tmakatos tmakatos assigned tmakatos and unassigned tmakatos May 10, 2021
@tmakatos
Copy link
Member

tmakatos commented May 10, 2021

Are there rules for avoiding deadlock between client->server and
server->client messages? For example, the client sends
VFIO_USER_REGION_WRITE and the server sends VFIO_USER_VM_INTERRUPT
before replying to the write message.

In this case, neither the client nor the server can assume that after they've sent a request the only thing they expect to receive is the response. They should examine the message header and act accordingly.

Multi-threaded clients and servers could end up deadlocking if messages
are processed while polling threads handle other device activity (e.g.
I/O requests that cause DMA messages).

Pipelining has the nice effect that the oldest message must complete
before the next pipelined message starts. It imposes a maximum issue
depth of 1. Still, it seems like it would be relatively easy to hit
re-entrancy or deadlock issues since both the client and the server can
initiate messages and may need to wait for a response.

My understanding is that this isn't any different from physical hardware. In vfio-user, messages have no dependencies, so a deadlock can only occur when the device is used improperly. @jlevon do you agree?

@tmakatos
Copy link
Member

tmakatos commented Jun 8, 2021

@jlevon ping

@jlevon
Copy link
Collaborator Author

jlevon commented Jun 9, 2021

I'm struggling to understand how this could be a spec issue at all. It seems like an entirely an implementation-level thing. I'm thinking this is maybe WONTFIX ?

@tmakatos
Copy link
Member

tmakatos commented Jun 9, 2021

I agree with you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants