From: Swen Schillig [mailto:s...@vnet.ibm.com] > Besides, memory allocations or other operations which could possibly end in > blocking or otherwise fatal situations must be avoided under a lock-condition > anyway. > We must try to prevent such "no-way" out situations.
So the problem in this unlock situation is the following: In the case of an FSAL that doesn't support lock owners for byte range locks, Ganesha maintains a union of all locks with the FSAL. The problem is when a client process exits and sends unlock(0 - EOF). Meanwhile, there are hundreds of locks on the same file from other lock owners. Ganesha can't just send unlock(0 - EOF) to the FSAL, because that would unlock every single lock. So Ganesha creates an unlock list, by walking every lock that still exists, and subtracting it from the 0 - EOF. The result might then be hundreds of little unlocks as the 0 - EOF is split up. The problem is when we get an ENOMEM while trying to allocate a structure to split part of that 0 - EOF. How do we recover from that? What if we get ENOMEM the first time we try and split? What if we get ENOMEM while trying to process an unlock request from a client (which BTW, MAY not retry that end of process unlock, I'm not sure how the client works, it probably doesn't retry forever). If you can't process an unlock, and the client will respond (immediately or eventually) to the error by just forgetting about the lock, you can't ever bring the lock state to correctness. Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
