Hi, Trond, > -----Original Message----- > From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] > On Behalf Of Trond Myklebust > Sent: Tuesday, September 13, 2011 5:11 AM > To: Benny Halevy > 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 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. Do you mean that if client sends layoutcommit at the same time as server sends layoutrecall for overlapped range, then server must reject layoutcommit with NFS4ERR_BADLAYOUT when receiving layoutcommit? RFC5661 section 18.42.3 says: If the layout identified in the arguments does not exist, the error NFS4ERR_BADLAYOUT is returned. The layout being committed may also be rejected if it does not correspond to an existing layout with an iomode of LAYOUTIOMODE4_RW. IMHO, in the above case, server cannot decide if the layout exists until client returns response to layoutrecall. But I can't find any requirement in RFC5661 that server must wait for layoutrecall's response before processing layoutcommit. Thanks, Tao ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
