SUNRPC/cache: fix reporting of expired cache entries in 'content' file.
authorNeilBrown <neilb@suse.de>
Thu, 12 Jul 2012 00:37:34 +0000 (10:37 +1000)
committerJ. Bruce Fields <bfields@redhat.com>
Thu, 12 Jul 2012 15:20:28 +0000 (11:20 -0400)
commit200724a7074281e7a0bf1101784a59fecddfa77d
tree4b20a0b9de0f725d5af7654621bb8b750bb0d0c9
parentbbf43dc888833ac0539e437dbaeb28bfd4fbab9f
SUNRPC/cache: fix reporting of expired cache entries in 'content' file.

Entries that are in a sunrpc cache but are not valid should be reported
with a leading '#' so they look like a comment.
Commit  d202cce8963d9 (sunrpc: never return expired entries in sunrpc_cache_lookup)
broke this for expired entries.

This particularly applies to entries that have been replaced by newer entries.
sunrpc_cache_update sets the expiry of the replaced entry to '0', but it
remains in the cache until the next 'cache_clean'.
The result is that if you

  echo 0 2000000000 1 0 > /proc/net/rpc/auth.unix.gid/channel

several times, then

  cat /proc/net/rpc/auth.unix.gid/content

It will display multiple entries for the one uid, which is at least confusing:

  #uid cnt: gids...
  0 1: 0
  0 1: 0
  0 1: 0

With this patch, expired entries are marked as comments so you get

  #uid cnt: gids...
  0 1: 0
  # 0 1: 0
  # 0 1: 0

These expired entries will never be seen by cache_check() as they are always
*after* a non-expired entry with the same key - so the extra check is only
needed in c_show()

Signed-off-by: NeilBrown <neilb@suse.de>
--
It's not a big problem, but it had me confused for a while, so it could
well confuse others.
Thanks,
NeilBrown
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
net/sunrpc/cache.c