Rojin George

Yes, looks like a use after free... mostly that fsal_fd was released in some other path but missed to be removed from fd_lru...

I hit another case at high load for which fsal_fd_global_counter went negative and in remove_fd_lru, we hit abort... with many IO happening parallely, seems IO lead close and fd_lru lead...

This was not seen after picking the patch to start the fd_lru, only after reaching lowwat and also after Inserting reopened files into fd lru....In FSAL had scenarios where we...

Something like below patch needs to be done...refer my comments also for completness... https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1184121

@ffilz - Please check my patches around the fd_lru... https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1184735 https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1184736 https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1184737

As discussed during the last call, all changes have been put up to the HEAD of below gerrit... https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1184737

@Haroldll Yeah, we have faced this...Please cherry pick this patch... https://gerrithub.io/c/ffilz/nfs-ganesha/+/1174224

@aepotapov - Please check, if your Ganesha code fork have picked up the below patch...This should resolve above lock ordering problem scenario...Kindly confirm once validated... https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1170151 https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1174224 Also there have...

Was thinking if we could reduce the lock contention period in Ganesha by avoiding readdir to take content_lock in rw mode to read entire chunk, may be we can hold...

@ffilz - This was seen in a virtualized environment and backend was really slow...