linux-toradex.git/include/linux/sunrpc/cache.h, branch v4.6-rc3

sunrpc/cache: make cache flushing more reliable.

2015-10-23T19:57:30+00:00

The caches used to store sunrpc authentication information can be
flushed by writing a timestamp to a file in /proc.

This timestamp has a one-second resolution and any entry in cache that
was last_refreshed *before* that time is treated as expired.

This is problematic as it is not possible to reliably flush the cache
without interrupting NFS service.
If the current time is written to the "flush" file, any entry that was
added since the current second started will still be treated as valid.
If one second beyond than the current time is written to the file
then no entries can be valid until the second ticks over.  This will
mean that no NFS request will be handled for up to 1 second.

To resolve this issue we make two changes:

1/ treat an entry as expired if the timestamp when it was last_refreshed
  is before *or the same as* the expiry time.  This means that current
  code which writes out the current time will now flush the cache
  reliably.

2/ when a new entry in added to the cache -  set the last_refresh timestamp
  to 1 second *beyond* the current flush time, when that not in the
  past.
  This ensures that newly added entries will always be valid.

Now that we have a very reliable way to flush the cache, and also
since we are using "since-boot" timestamps which are monotonic,
change cache_purge() to set the smallest future flush_time which
will work, and leave it there: don't revert to '1'.

Also disable the setting of the 'flush_time' far into the future.
That has never been useful and is now awkward as it would cause
last_refresh times to be strange.
Finally: if a request is made to set the 'flush_time' to the current
second, assume the intent is to flush the cache and advance it, if
necessary, to 1 second beyond the current 'flush_time' so that all
active entries will be deemed to be expired.

As part of this we need to add a 'cache_detail' arg to cache_init()
and cache_fresh_locked() so they can find the current ->flush_time.

Signed-off-by: NeilBrown 
Reported-by: Olaf Kirch 
Signed-off-by: J. Bruce Fields

sunrpc: Switch to using hash list instead single list

2015-08-13T12:59:03+00:00

Switch using list_head for cache_head in cache_detail,
it is useful of remove an cache_head entry directly from cache_detail.

v8, using hash list, not head list

Signed-off-by: Kinglong Mee 
Reviewed-by: NeilBrown 
Signed-off-by: J. Bruce Fields

sunrpc/nfsd: Remove redundant code by exports seq_operations functions

2015-08-13T12:59:02+00:00

Nfsd has implement a site of seq_operations functions as sunrpc's cache.
Just exports sunrpc's codes, and remove nfsd's redundant codes.

v8, same as v6

Signed-off-by: Kinglong Mee 
Reviewed-by: NeilBrown 
Signed-off-by: J. Bruce Fields

sunrpc: prepare NFS for 2038

2013-08-19T13:55:01+00:00

1) The kernel sunrpc code needs to handle seconds since epoch
greater than 2147483647. This means functions that parse time
as an int need to handle it as time_t.

2) The kernel changes must be accompanied by userspace changes
in nfs-utils.

Signed-off-by: Harshula Jayasuriya 
Signed-off-by: J. Bruce Fields

net/sunrpc: xpt_auth_cache should be ignored when expired.

2013-07-01T21:53:28+00:00

commit d202cce8963d9268ff355a386e20243e8332b308
    sunrpc: never return expired entries in sunrpc_cache_lookup

moved the 'entry is expired' test from cache_check to
sunrpc_cache_lookup, so that it happened early and some races could
safely be ignored.

However the ip_map (in svcauth_unix.c) has a separate single-item
cache which allows quick lookup without locking.  An entry in this
case would not be subject to the expiry test and so could be used
well after it has expired.

This is not normally a big problem because the first time it is used
after it is expired an up-call will be scheduled to refresh the entry
(if it hasn't been scheduled already) and the old entry will then
be invalidated.  So on the second attempt to use it after it has
expired, ip_map_cached_get will discard it.

However that is subtle and not ideal, so replace the "!cache_valid"
test with "cache_is_expired".
In doing this we drop the test on the "CACHE_VALID" bit.  This is
unnecessary as the bit is never cleared, and an entry will only
be cached if the bit is set.

Reported-by: Bodo Stroesser 
Signed-off-by: NeilBrown 
Signed-off-by: J. Bruce Fields

sunrpc/cache: ensure items removed from cache do not have pending upcalls.

2013-07-01T21:53:28+00:00

It is possible for a race to set CACHE_PENDING after cache_clean()
has removed a cache entry from the cache.
If CACHE_PENDING is still set when the entry is finally 'put',
the cache_dequeue() will never happen and we can leak memory.

So set a new flag 'CACHE_CLEANED' when we remove something from
the cache, and don't queue any upcall if it is set.

If CACHE_PENDING is set before CACHE_CLEANED, the call that
cache_clean() makes to cache_fresh_unlocked() will free memory
as needed.  If CACHE_PENDING is set after CACHE_CLEANED, the
test in sunrpc_cache_pipe_upcall will ensure that the memory
is not allocated.

Reported-by: 
Signed-off-by: NeilBrown 
Signed-off-by: J. Bruce Fields

SUNRPC: remove "cache_request" argument in sunrpc_cache_pipe_upcall() function

2013-02-15T15:43:47+00:00

Passing this pointer is redundant since it's stored on cache_detail structure,
which is also passed to sunrpc_cache_pipe_upcall () function.

Signed-off-by: Stanislav Kinsbursky 
Signed-off-by: J. Bruce Fields

SUNRPC: introduce cache_detail->cache_request callback

2013-02-15T15:43:45+00:00

This callback will allow to simplify upcalls in further patches in this
series.

Signed-off-by: Stanislav Kinsbursky 
Signed-off-by: J. Bruce Fields

svcrpc: Revert "sunrpc/cache.h: replace simple_strtoul"

2012-11-15T12:40:32+00:00

Commit bbf43dc888833ac0539e437dbaeb28bfd4fbab9f "sunrpc/cache.h: replace
simple_strtoul" introduced new range-checking which could cause get_int
to fail on unsigned integers too large to be represented as an int.

We could parse them as unsigned instead--but it turns out svcgssd is
actually passing down "-1" in some cases.  Which is perhaps stupid, but
there's nothing we can do about it now.

So just revert back to the previous "sloppy" behavior that accepts
either representation.

Cc: stable@vger.kernel.org
Reported-by: Sven Geggus 
Signed-off-by: J. Bruce Fields

nfsd: add get_uint for u32's

2012-07-25T13:18:27+00:00

I don't think there's a practical difference for the range of values
these interfaces should see, but it would be safer to be unambiguous.

Signed-off-by: J. Bruce Fields