On Wed, 2015-11-25 at 15:20 +0200, Mika Kuoppala wrote: > We assume that lock is held on start of the loop scope. > Some paths continuing inside loop didn't adhere to this > assumption, causing segfault on unlocking an already > unlocked mutex. Fix this by re-aquiring lock always. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93013 > Cc: Michał Winiarski <michal.winiarski@xxxxxxxxx> > Cc: Thomas Wood <thomas.wood@xxxxxxxxx> > Signed-off-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxx> Reviewed-by: Michał Winiarski <michal.winiarski@xxxxxxxxx> > --- > tests/drm_import_export.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/tests/drm_import_export.c b/tests/drm_import_export.c > index 49486ab..cfe5f6d 100644 > --- a/tests/drm_import_export.c > +++ b/tests/drm_import_export.c > @@ -161,20 +161,20 @@ static void *import_close_thread(void *data) > pthread_mutex_unlock(&t->mutex); > } > else > - /* We take the lock right after > entering the loop */ > + /* Lock should be held on entering > the loop */ > continue; > } > + > if (bo == NULL) { > /* > * If the bo is NULL it means that we've > unreferenced in other > * thread - therefore we should expect > ENOENT > */ > igt_assert_eq(errno, ENOENT); > - continue; > + } else { > + drm_intel_bo_unreference(bo); > } > > - drm_intel_bo_unreference(bo); > - > pthread_mutex_lock(&t->mutex); > } > pthread_mutex_unlock(&t->mutex); _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
