On Wed, 17 Mar 2010 17:33:07 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Wed, Feb 03, 2010 at 05:31:31PM +1100, NeilBrown wrote: > > If sunrpc_cache_lookup finds an expired entry, remove it from > > the cache and return a freshly created non-VALID entry instead. > > This ensures that we only ever get a usable entry, or an > > entry that will become usable once an update arrives. > > i.e. we will never need to repeat the lookup. > > > > This allows us to remove the 'is_expired' test from cache_check > > (i.e. from cache_is_valid). cache_check should never get an expired > > entry as 'lookup' will never return one. If it does happen - due to > > inconvenient timing - then just accept it as still valid, it won't be > > very much past it's use-by date. > > Looks right to me. Thanks, applied. > > By the way, if we get sunrpc_cache_update(old, new1) and > sunrpc_cache_update(old, new2) simultaneously, what happens? Interesting question. I guess you could get two entries for the same key in the cache. However the ->parse routines are protected by i_mutex so you would need on update to come through /proc/net/rpc/..../channel, and the other to come through the legacy nfsd syscal. Highly unlikely. > > More generally: should we try to ensure that a cache never contains two > entries which match the same key? I don't think we need to. The newer will over-ride the older which will eventually expire from the cache or be flushed. So worst-case someone will look in the /content file, see two entries with the same key, and get confused. I don't think it is a problem that needs fixing. Thanks, NeilBrown -- 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
