On 2013-10-16 15:33, Christoph Hellwig wrote: > On Wed, Oct 16, 2013 at 03:18:21PM +0300, Benny Halevy wrote: >> The nfs4.1 layout stateid is like any other stateid (open/lock/deleg) >> but it's life time is a bit different as it is not descending from the >> open stateid (though the protocol requires the client to use it >> to acquire the first layout for the file) and it is released via >> either LAYOUTRETURN or CLOSE (in the "return_on_close" case). >> The rules here are different enough from open/lock/deleg stateids that >> pnfsd needs special code to handle the management of the actual layout state >> under the layout stateid and manipulate it accordingly. > > I'm not primarily ocnfused about the protocol even if that isn't all > that clear either. I'm more worried about the code in and around > nfs4_find_create_layout_stateid. I have looked a bit deeper into it > and I think the main problem is that struct nfs4_stid isn't refcounted > by itself, which really confused me expecting nfsd4_lookup_stateid > to return a reference to it. > True. That is likely to change with the state lock elimination project where a stateid would get refcounted once found and its pointer is returned to the caller. -- 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
