Re: [PATCH] nfs: fix inifinite loop at nfs4_layoutcommit_release

[Benny Halevy <bhalevy@tonian.com>]

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.

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