Pasi, Early test results for 2.7.6 are looking good. Thanks, Vandana On 7/18/19, 3:13 AM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote: Hello Rungta, On Thu, Jul 11, 2019 at 03:24:48PM +0000, Rungta, Vandana wrote: > The core I have in the message thread: https://lists.nfs-ganesha.org/archives/list/devel@lists.nfs-ganesha.org/thre... > was with 2.7.5 with the below change already applied. The core is very reproducible. > I'm curious if nfs-ganesha V2.7.6 works OK for you? Would be nice to know the test results with that version. Thanks, -- Pasi > The window that is fixed by this change - does it also exist for the case where we transition to the next chunk on the last line in mdcache_readdir_chunked. > Read_lock. The first chunk is populated, and we read the entries from that chunk. Then we transition to the next chunk. The next chunk is not populated, he have a ref count on the chunk, and we continue to hold the ref across the lock drop. > > Thanks, > Vandana > > if (look_ck == 0 || > !mdcache_avl_lookup_ck(directory, look_ck, &dirent)) { > fsal_status_t status; > /* This starting position isn't in our cache... > * Go populate the cache and process from there. > */ > if (!has_write) { > /* Upgrade to write lock and retry just in case > * another thread managed to populate this cookie > * in the meantime. > */ > PTHREAD_RWLOCK_unlock(&directory->content_lock); > PTHREAD_RWLOCK_wrlock(&directory->content_lock); > has_write = true; > /* We have a ref on chunk; don't null it out */ > goto again; > } > > > ???On 7/11/19, 8:09 AM, "Daniel Gryniewicz" <dang@redhat.com> wrote: > > Okay, this is a simple fix. It should not, in fact, be holding a ref > across the lock drop, since we are throwing that chunk away anyway. The > unref was in the wrong location. > > https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/461446 > > Daniel > _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org