Return-Path: Received: from fieldses.org ([173.255.197.46]:56530 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754755AbdLGQ6j (ORCPT ); Thu, 7 Dec 2017 11:58:39 -0500 Date: Thu, 7 Dec 2017 11:58:38 -0500 To: Olga Kornievskaia Cc: Trond Myklebust , linux-nfs , "nfsv4@ietf.org" Subject: Re: [nfsv4] questing about NLM LOCK, CANCEL UNLOCK Message-ID: <20171207165838.GA4096@fieldses.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: From: bfields@fieldses.org (J. Bruce Fields) Sender: linux-nfs-owner@vger.kernel.org List-ID: On Thu, Dec 07, 2017 at 11:10:16AM -0500, Olga Kornievskaia wrote: > Ok. I thought that because RFC1813 covers NLM operations that it is. 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. > >> 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. --b.