> -----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. > > 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 -- 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
