On Wed, 3 Feb 2021 14:57:23 +0000 Stefan Hajnoczi <[email protected]> wrote:
> On Fri, Jan 29, 2021 at 04:53:12PM +0100, Greg Kurz wrote: > > pthread_rwlock_rdlock() and pthread_rwlock_wrlock() can fail if a > > deadlock condition is detected or the current thread already owns > > the lock. They can also fail, like pthread_rwlock_unlock(), if the > > mutex wasn't properly initialized. None of these are ever expected > > to happen with fv_VuDev::vu_dispatch_rwlock. > > > > Some users already check the return value and assert, some others > > don't. Introduce rdlock/wrlock/unlock wrappers that just do the > > former and use them everywhere. > > > > Signed-off-by: Greg Kurz <[email protected]> > > What is the purpose of this commit: > 1. Code cleanup/consistency? > 2. Helps debug an issue that doesn't occur in production but you hit > during development? > 3. Needed to diagnose a real-world issue? How do you reproduce it? > > I wanted to check to make sure I'm not missing an issue you found with > production workloads. > I would have provided more details if that came from an actual issue, but you're definitely right to ask : this falls more under 1. > > @@ -645,8 +662,7 @@ static void *fv_queue_thread(void *opaque) > > break; > > } > > /* Mutual exclusion with virtio_loop() */ > > - ret = pthread_rwlock_rdlock(&qi->virtio_dev->vu_dispatch_rwlock); > > - assert(ret == 0); /* there is no possible error case */ > > + vu_dispatch_wrlock(qi->virtio_dev); > > s/vu_dispatch_wrlock/vu_dispatch_rdlock/ ? Oops... definitely...
pgpLAFVBRkysG.pgp
Description: OpenPGP digital signature
