Ok. I thought that because RFC1813 covers NLM operations that it is. I will extend this question to the Linux NFS mailing list as the client implementation I'm interested is Linux. On Thu, Dec 7, 2017 at 10:59 AM, Trond Myklebust <trondmy@xxxxxxxxx> wrote: > Hi Olga, > > NLM isn't an IETF protocol. > > Cheers > Trond > > On 7 December 2017 at 10:57, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >> >> Hi folks, >> >> I'm looking for guidance for what are responsibilities of the client >> or server to solve the following situation. >> >> Client application is acquiring a blocking lock but shortly after that >> application is killed via ctrl-C. NFS client sent out NLM_LOCK but >> hasn't gotten a reply yet as ctrl-c arrived. To clean up, the client >> is sending CANCEL and UNLOCK to the server. >> >> Server ends up processing CANCEL and UNLOCK first (for whatever reason >> one legitimate one could be network re-ordered packets) and server has >> no state so it's just sending GRANTED replies back (which seems to be >> a legitimate thing to do). Then server processes LOCK and replies to >> the client. >> >> Now we are in the situation where lock was granted to a client that >> doesn't know it's holding one and it prevents other clients from >> grabbing this lock. >> >> Is there a solution or this is broken protocol? >> >> Should it be client's responsibility to notice that it received a LOCK >> reply for which it wasn't waiting and always follow up with an UNLOCK? >> >> Thank you. >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/nfsv4 > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
