Return-Path: Received: from mail-ob0-f177.google.com ([209.85.214.177]:34296 "EHLO mail-ob0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751973AbbJMTq5 (ORCPT ); Tue, 13 Oct 2015 15:46:57 -0400 Received: by obbda8 with SMTP id da8so22786497obb.1 for ; Tue, 13 Oct 2015 12:46:57 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 13 Oct 2015 15:46:56 -0400 Message-ID: Subject: Re: [PATCH 1/1] Adding issync field to delegreturn_exit tracepoint From: Trond Myklebust To: Andrew W Elble Cc: Olga Kornievskaia , linux-nfs Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, Oct 13, 2015 at 1:58 PM, Andrew W Elble wrote: > > Trond Myklebust writes: > > >> > OK. So what are the symptoms? I'm having trouble seeing how a race can > >> > happen, given a correctly coded server. > >> > >> Here's what the server sees: > >> open (foobar) replies back with a delegation > >> various operations including a close() > >> some time goes by... > >> open (foobar) replies back with the same delegation > > > > Why? Olga, we already had this discussion. That sort of server > > behaviour is never going to work without races and is the root cause > > of your problem. We simply won't ever support servers that do this. > > Trond, > > Specifically, what would the correct behavior be here? The server should honour the open without repeating the delegation. The client already knows about the delegation due to the first open, so there is no value whatsoever in repeating it. In addition, as you see from Olga's example, it causes races with the return of that delegation.