Return-Path: Received: from mail-ua0-f178.google.com ([209.85.217.178]:34827 "EHLO mail-ua0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753151AbdLMSjX (ORCPT ); Wed, 13 Dec 2017 13:39:23 -0500 Received: by mail-ua0-f178.google.com with SMTP id l2so2251535uak.2 for ; Wed, 13 Dec 2017 10:39:23 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <026e01d36f95$da192e90$8e4b8bb0$@mindspring.com> References: <20171207165838.GA4096@fieldses.org> <019f01d36f8d$0ce06220$26a12660$@mindspring.com> <026e01d36f95$da192e90$8e4b8bb0$@mindspring.com> From: Olga Kornievskaia Date: Wed, 13 Dec 2017 13:39:21 -0500 Message-ID: Subject: Re: [nfsv4] questing about NLM LOCK, CANCEL UNLOCK To: Frank Filz Cc: "J. Bruce Fields" , linux-nfs , "nfsv4@ietf.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-nfs-owner@vger.kernel.org List-ID: On Thu, Dec 7, 2017 at 2:59 PM, Frank Filz wrote: >> On Thu, Dec 7, 2017 at 1:56 PM, Frank Filz wro= te: >> >> On Thu, Dec 7, 2017 at 11:58 AM, J. Bruce Fields >> >> >> >> wrote: >> >> > On Thu, Dec 07, 2017 at 11:10:16AM -0500, Olga Kornievskaia wrote: >> >> >> Ok. I thought that because RFC1813 covers NLM operations that it i= s. >> >> > >> >> > Yeah, I don't see a harm to the occasional NLM question on the v4 >> >> > working group list. It's a bit of an orphaned protocol, so there's >> >> > not really any other implementation-independent forum. >> >> > >> >> >> I will extend this question to the Linux NFS mailing list as the >> >> >> client implementation I'm interested is Linux. >> >> > >> >> > But that's fine too. >> >> > >> >> > I thought that LOCK/CANCEL race was one of the motivations for >> >> > NFSv4, so... >> >> > >> >> >> >> Is there a solution or this is broken protocol? >> >> > >> >> > ... I'd always assumed the protocol was impossible to implement >> >> > 100% correctly, though maybe there's some clever solution. >> >> >> >> Is such race still possible with the linux server implementation >> >> which is >> > single >> >> threaded and in my testing isn't processing LOCK/CANCEL out-of-order >> then? >> >> >> >> >> >> 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? >> >> > >> >> > That would be tricky and still not handle all cases, I think. >> >> >> >> Yes I'm not sure the client can do it. It will have no info about the >> >> lock >> > and not >> >> sure how to create an appropriate UNLOCK reply (unless we keep around >> >> lock info of all cancelled locks). >> >> > The NLM4_GRANTED call has a response where the client can respond >> > NLM4_DENIED to indicate it is not accepting the lock. >> > >> > The Ganesha NFS server could process out of order, however, if the >> > client responds to the grant with NLM4_DENIED, Ganesha will properly >> > release the lock. >> >> This is the case for when the server is doing a callback to the client a= nd >> granting the lock and client has ability to reply with denied. The situa= tion I'm >> curious about is just after the initial LOCK request is sent and server = hasn't >> processed it and it got&processed a CANCEL/UNLOCK. > > Oh, woops, yea... if the lock doesn't block, then the situation is differ= ent. When the client gets the LOCK response, it really should check and see= if it was actually waiting for that response, or actually, the client shou= ld probably delay sending UNLOCK if it has not got a response to an outstan= ding lock request yet. Current linux client does not do that. > CANCEL is only for cancelling a blocked lock, so shouldn't be sent unless= the server has already responded to the LOCK with NLM4_BLOCKED, in which c= ase there is no ordering issue (Ganesha should handle ordering issue betwee= n NLM4_GRANT call and NLM4_CANCEL). Current linux client will send a CANCEL even if it didn't receive the reply from the server. > If we want NLM4_CANCEL to be able to cancel an inflight LOCK request, the= n we would need to add semantics which would include the server either resp= onding to the cancel to let the client know it hasn't processed the LOCK re= quest yet, or it should somehow remember the cancel so it can ignore the LO= CK request when it processes it (which is probably too much for the server = to deal with). Sounds like Ganesha server (and Netapp) will have orphan locks that would require manual lock break or server reboot. >> > The imperfectness of NLM is why I have seen requests for tools to free >> > wedged locks... We haven't managed to write such a tool for Ganesha >> > yet (so either we don't actually have that many NLM clients, or folks >> > are using other mechanisms to deal with the issue - restarting the >> > server and making all the clients reclaim the locks they want is one w= ay to >> do it...). >> >> Yes server-side lock breaking or rebooting is a way out this situation i= n >> practice. >> > >> > Frank >> > >> > >> > --- >> > This email has been checked for viruses by Avast antivirus software. >> > https://www.avast.com/antivirus >> > >