Return-Path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:58324 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750991Ab1INGnW (ORCPT ); Wed, 14 Sep 2011 02:43:22 -0400 Received: by wyh22 with SMTP id 22so1338800wyh.19 for ; Tue, 13 Sep 2011 23:43:21 -0700 (PDT) Message-ID: <4E704D05.6020406@tonian.com> Date: Wed, 14 Sep 2011 08:43:17 +0200 From: Benny Halevy To: tao.peng@emc.com CC: Trond.Myklebust@netapp.com, bergwolf@gmail.com, gusev.vitaliy@nexenta.com, gusev.vitaliy@gmail.com, linux-nfs@vger.kernel.org Subject: Re: [PATCH] nfs: fix inifinite loop at nfs4_layoutcommit_release References: <1314512558-16912-1-git-send-email-gusev.vitaliy@nexenta.com> <1315337382.16274.7.camel@lade.trondhjem.org> <4E669B21.30006@nexenta.com> <1315348373.19556.22.camel@lade.trondhjem.org> <2E1EB2CF9ED1CB4AA966F0EB76EAB4430B0ED3DF@SACMVEXC2-PRD.hq.netapp.com> <2E1EB2CF9ED1CB4AA966F0EB76EAB4430B0ED4C8@SACMVEXC2-PRD.hq.netapp.com> <1315592430.17611.15.camel@lade.trondhjem.org> <4E6B0E48.7050208@tonian.com> <4E6E6C3B.2040605@tonian.com> <1315861851.8350.11.camel@lade.trondhjem.org> <4E6F0B61.4050907@tonian.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On 2011-09-13 10:32, tao.peng@emc.com wrote: >> -----Original Message----- >> From: Benny Halevy [mailto:bhalevy@tonian.com] >> Sent: Tuesday, September 13, 2011 3:51 PM >> To: Trond Myklebust >> Cc: Peng Tao; Peng, Tao; gusev.vitaliy@nexenta.com; gusev.vitaliy@gmail.com; >> linux-nfs@vger.kernel.org >> Subject: Re: [PATCH] nfs: fix inifinite loop at nfs4_layoutcommit_release >> >> On 2011-09-12 14:10, Trond Myklebust wrote: >>> On Mon, 2011-09-12 at 13:31 -0700, Benny Halevy wrote: >>>> On 2011-09-12 07:56, Peng Tao wrote: >>>>>> The layout segments are not really in use while in LAYOUTCOMMIT. >>>>>> We only need to get the stateid right with respect to concurrent layout recalls. >>>>> LAYOUTCOMMIT takes lseg reference to mark them as in use so that >>>>> layoutrecall cannot free them. >>>>> >>>> >>>> And if layoutrecall would have freed layout segments during layoutcommit, >>>> what is your specific concern? >>> >>> That layoutcommit is supposed to return NFS4ERR_BAD_LAYOUT in that case >>> according to section 18.42.3 of RFC5661. I can't find anything in the >>> errata that changes that requirement. >>> >> >> Right. That tells me there no need to strictly serialize LAYOUTCOMMITs >> with CB_LAYOUTRECALL, as long as the layout stateid sent with LAYOUTCOMMIT >> atomically represents the state when the operation was prepared. >> >> That said, since we do want the LAYOUTCOMMIT to succeed, it would be beneficial >> for the client to reply to a CB_LAYOUTRECALL received while a conflicting >> LAYOUTCOMMIT is in progress with NFS4ERR_DELAY. > I agree. How about adding a new flag to nfsi->flags for this? We can use the same flag on to ensure serialization of multiple layoutcommit. nfs_commit_set_lock/nfs_commit_clear_lock may not fit for this. > Sounds good in principle. Can you take a stab at a patch that does this? Benny >> >> The server, on its side, should prevent a distributed deadlock by avoiding >> blocking of a LAYOUTCOMMIT on an outstanding CB_LAYOUTRECALL for the same >> client that sent the LAYOUTCOMMIT. I'm not sure what error would be best to >> return. Maybe NFS4ERR_RECALL_CONFLICT if it would be allowed (it isn't listed >> for LAYOUTCOMMIT at the moment). Just returning NFS4ER_DELAY might lead to >> a live lock situation where neither the LAYOUTCOMMIT not the CB_LAYOUTRECALL >> complete. >> >> Benny >