On Thu, Dec 7, 2017 at 11:58 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> 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 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. 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). > > --b. > -- > 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 -- 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
