Return-Path: Received: from mail-oi0-f50.google.com ([209.85.218.50]:35047 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751889AbbJNROo (ORCPT ); Wed, 14 Oct 2015 13:14:44 -0400 Received: by oixx6 with SMTP id x6so15769488oix.2 for ; Wed, 14 Oct 2015 10:14:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 14 Oct 2015 13:14:43 -0400 Message-ID: Subject: Re: [PATCH 1/1] Adding issync field to delegreturn_exit tracepoint From: Trond Myklebust To: Olga Kornievskaia Cc: Andrew W Elble , linux-nfs Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Wed, Oct 14, 2015 at 10:58 AM, Olga Kornievskaia wrote: > On Tue, Oct 13, 2015 at 3:46 PM, Trond Myklebust > wrote: >> 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. > > Trond thank you for the explanations. While I haven't hit the last > case of the race I would still like to bring up that we've seen a case > where ACCESS is sent and then DELEGRETURN and then delegation stateid > is used by the IO. Perhaps the commit 5e99b532bb95 helps in that case. > But if not, then this case of the race can't be handled by the server. That's a different bug, and is indeed a client issue. It should be fixed by commit 24311f884189 + 5e99b532bb95. Please let me know if that is not the case.