Thanks for your comments, Trond. > Note that there there is no RFC 2119 normative MUST or even a SHOULD. > We therefore expect to be able to reuse the cookie verifier with a zero > cookie in order to validate that the cookies that our client may still > be caching (e.g. in another open file context) are good. > Either way, as I said previously, the patch is incorrect since it is > setting the verifier to zero in a context where it cannot guarantee > that the next cookie sent in a READDIR call will be a zero. Pls correct me if my understanding is not correct, but since we store the cookieverf in the inode (shared by all open contexts), while every open context has its own dir_cookie, all changes to cookieverf _are_ being done regardless of the dir_cookie value held by other open contexts. If after the cookieverf change, an open context's cookiverf and cookie combination becomes invalid at the server, that open context deals with the EBADCOOKIE as appropriate. f.e. nfs_zap_caches_locked() also clears cookieverf when the dir cache is zapped, irrespective of other open contexts. Also, since we did intend to set the cookieverf to 0 in nfs_invalidate_mapping(), just that if the dir cache happens to be already purged (say by an unrelated vm reclaim), we cancel the invalidation. This causes us to use the old non-zero cookiverf, a different behavior than if the dir cache was not purged. Is this ok ? Isn't it better to consistently use zero cookieverf in both cases ? Thanks, Tomar
