Replying to myself: Apparently, the callers are expected to manually perform the UNLOCK later. I've added a comment in the code for future reference. Y.
On Sat, Dec 1, 2018 at 8:53 PM Yaniv Kaul <yk...@redhat.com> wrote: > I'm looking at the code and I'm not sure if there's a missing UNLOCK there > (location marked in bold red) for cache->gc_lock : > > LOCK(&cache->gc_lock); > bucket = id % cache->gc_nbuckets; > agl = BUCKET_START(cache->gc_cache, bucket); > for (i = 0; i < AUX_GID_CACHE_ASSOC; i++, agl++) { > if (!agl->gl_list || agl->gl_id != id) > continue; > > /* > @uid and @gid reflect the latest UID/GID of the > process performing the syscall (taken from frame->root). > > If the UID and GID has changed for the PID since the > time we cached it, we should treat the cache as having > stale values and query them freshly. > */ > if (agl->gl_uid != uid || agl->gl_gid != gid) > break; > > /* > * We don't put new entries in the cache when expiration=0, but > * there might be entries still in there if expiration was > * changed very recently. Writing the check this way ensures > * that they're not used. > */ > if (now < agl->gl_deadline) { > *return agl;* > } > > /* > * We're not going to find any more UID matches, and reaping > * is handled further down to maintain LRU order. > */ > break; > } > UNLOCK(&cache->gc_lock); > return NULL; > } > > > TIA, > Y. > > >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel