On Thu, Apr 21, 2022 at 5:25 PM Maxime Coquelin <maxime.coque...@redhat.com> wrote: > On 4/11/22 13:00, David Marchand wrote: > > This change simply annotates existing paths of the code leading to > > manipulations of the vq->access_lock. > > > > One small change is required: vhost_poll_enqueue_completed was getting > > a queue_id to get hold of the vq, while its callers already knew of > > the vq. For the annotation sake, vq is now directly passed. > > It is anyway more consistent with the rest of the code to pass directly > the vq in internal API when queue ID is not needed. > > > vhost_user_lock_all_queue_pairs and vhost_user_unlock_all_queue_pairs > > are skipped since vq->access_lock are conditionally held. > > As discussed off-list, I wonder whether it could be possible to rework > the conditional lock holding using the static array and some macros so > that we could statically specify for each request if the lock is > required.
We did discuss some ideas off-list, but in the end, since we have multiple locks being dynamically taken in vhost_user_lock_all_queue_pairs, I see no way to statically annotate the code. We could rework the code to have message handlers in a consolidated static array, but that would not help with annotations. I had some patches going in that direction (related to some fd fixes I sent before), but it needs more work. I'll see if I can send this later in the release or it will go to next release. -- David Marchand
