On Mon, 2011-02-28 at 17:01 -0500, Trond Myklebust wrote: > On Mon, 2011-02-28 at 16:54 -0500, Jim Rees wrote: > > Trond Myklebust wrote: > > > > nfsi->delegation is released under the appropriate locks well before we > > get here. The above line is 100% racy and risks clobbering any new > > delegation that has been issued after the delegreturn completed... > > > > I'd have been amazed if I'd gotten it right. But there really is a problem > > here, the client does try to use delegations that have been returned, and > > this patch does solve that problem. I'm happy to keep after this but would > > appreciate any suggestions or nudges in the right direction. > > The procedure for returning delegations is supposed to work as follows: > > 1. Remove the nfsi->delegation so that it is no longer visible to > new open() requests > 2. write back any dirty data to the server > 3. Reclaim any locks > 4. Reclaim any open stateids (using CLAIM_DELEGATE_CUR) Errr.... lock reclaim comes after open reclaim, of course... The rest is correct. > 5. delegreturn > > While there may indeed be the odd READ or WRITE that races between 4. > and 5., so that the server receives the delegation stateid after the > delegreturn, that shouldn't matter: the server returns an error, and the > client should retry using the new open stateid. > > What is failing to work correctly here? > -- 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
