On 2013-10-11 22:47, Christoph Hellwig wrote: > I've been looking at this patch and the surrounding code a bit more and > start to really dislike it. > > put_nfs4_file is very much unrelated to the state lock, so having a > version that internally drops it seems wrong. If we look at the usage > of your new locked version there's very few callers: > > > put_nfs4_file_locked > + destroy_layout_state > + put_layout_state > + destroy_layout > + destroy_layout_list > + nfs4_pnfs_return_layout > + pnfs_expire_client > + nfs4_pnfs_get_layout > + nfs4_pnfs_return_layout > > Except for pnfs_expire_client all these are right near the places where > the state lock is dropped, so simply refactoring the code sounds like > a very valid option. I hear you. Makes sense. > > > And btw, the state locking is even more of a mess than I though. I > think it really needs to be split up sooner or later. > I'm working on patches eliminating the state lock by refactoring the code that is currently protected by it, moving all blocking calls to either before or after the critical section. I'll send a RFC patchset as soon as I have the first stab at it completed. 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
