Thanks! -----Original Message----- From: <tao.peng@xxxxxxx> Date: Wed, 14 Sep 2011 03:53:30 To: <bhalevy@xxxxxxxxxx> Cc: <Trond.Myklebust@xxxxxxxxxx>; <bergwolf@xxxxxxxxx>; <gusev.vitaliy@xxxxxxxxxxx>; <gusev.vitaliy@xxxxxxxxx>; <linux-nfs@xxxxxxxxxxxxxxx> Subject: RE: [PATCH] nfs: fix inifinite loop at nfs4_layoutcommit_release > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@xxxxxxxxxx] > Sent: Wednesday, September 14, 2011 2:43 PM > To: Peng, Tao > Cc: Trond.Myklebust@xxxxxxxxxx; bergwolf@xxxxxxxxx; > gusev.vitaliy@xxxxxxxxxxx; gusev.vitaliy@xxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] nfs: fix inifinite loop at nfs4_layoutcommit_release > > On 2011-09-13 10:32, tao.peng@xxxxxxx wrote: > >> -----Original Message----- > >> From: Benny Halevy [mailto:bhalevy@xxxxxxxxxx] > >> Sent: Tuesday, September 13, 2011 3:51 PM > >> To: Trond Myklebust > >> Cc: Peng Tao; Peng, Tao; gusev.vitaliy@xxxxxxxxxxx; gusev.vitaliy@xxxxxxxxx; > >> linux-nfs@xxxxxxxxxxxxxxx > >> 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? OK, I will spend some time on it this week. Thanks, Tao > > 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 > > ÿôèº{.nÇ+?·?®??+%?Ëÿ±éݶ¥?wÿº{.nÇ+?·¥?{±þwìþ)í?æèw* jg¬±¨ ¶????Ý¢jÿ¾«þG«?éÿ¢¸ ¢·¦j:+v?¨?wèjØm¶?ÿþø ¯ù ®w¥þ?àþf£¢·h??â?úÿ?Ù¥
