kernel/linux.git/net/sunrpc/cache.c, branch v6.19.11

sunrpc: fix cache_request leak in cache_release

2026-03-25T10:13:15+00:00

commit 17ad31b3a43b72aec3a3d83605891e1397d0d065 upstream. When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request. Reported-by: NeilBrown Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@kernel.org Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman

sunrpc: fix race in cache cleanup causing stale nextcheck time

2025-05-11T23:48:22+00:00

When cache cleanup runs concurrently with cache entry removal, a race condition can occur that leads to incorrect nextcheck times. This can delay cache cleanup for the cache_detail by up to 1800 seconds: 1. cache_clean() sets nextcheck to current time plus 1800 seconds 2. While scanning a non-empty bucket, concurrent cache entry removal can empty that bucket 3. cache_clean() finds no cache entries in the now-empty bucket to update the nextcheck time 4. This maybe delays the next scan of the cache_detail by up to 1800 seconds even when it should be scanned earlier based on remaining entries Fix this by moving the hash_lock acquisition earlier in cache_clean(). This ensures bucket emptiness checks and nextcheck updates happen atomically, preventing the race between cleanup and entry removal. Signed-off-by: Long Li Signed-off-by: Chuck Lever

sunrpc: update nextcheck time when adding new cache entries

2025-05-11T23:48:22+00:00

The cache_detail structure uses a "nextcheck" field to control hash table scanning intervals. When a table scan begins, nextcheck is set to current time plus 1800 seconds. During scanning, if cache_detail is not empty and a cache entry's expiry time is earlier than the current nextcheck, the nextcheck is updated to that expiry time. This mechanism ensures that: 1) Empty cache_details are scanned every 1800 seconds to avoid unnecessary scans 2) Non-empty cache_details are scanned based on the earliest expiry time found However, when adding a new cache entry to an empty cache_detail, the nextcheck time was not being updated, remaining at 1800 seconds. This could delay cache cleanup for up to 1800 seconds, potentially blocking threads(such as nfsd) that are waiting for cache cleanup. Fix this by updating the nextcheck time whenever a new cache entry is added. Signed-off-by: Long Li Signed-off-by: Chuck Lever

Revert "sunrpc: clean cache_detail immediately when flush is written frequently"

2025-04-26T16:00:43+00:00

Ondrej reports that certain SELinux tests are failing after commit fc2a169c56de ("sunrpc: clean cache_detail immediately when flush is written frequently"), merged during the v6.15 merge window. Reported-by: Ondrej Mosnacek Fixes: fc2a169c56de ("sunrpc: clean cache_detail immediately when flush is written frequently") Signed-off-by: Chuck Lever

sunrpc: clean cache_detail immediately when flush is written frequently

2025-03-10T13:10:53+00:00

We will write /proc/net/rpc/xxx/flush if we want to clean cache_detail. This updates nextcheck to the current time and calls cache_flush --> cache_clean to clean cache_detail. If we write this interface again within one second, it will only increase flush_time and nextcheck without actually cleaning cache_detail. Therefore, if we keep writing this interface repeatedly within one second, flush_time and nextcheck will keep increasing, even far exceeding the current time, making it impossible to clear cache_detail through the flush interface or cache_cleaner. If someone frequently calls the flush interface, we should immediately clean the corresponding cache_detail instead of continuously accumulating nextcheck. Signed-off-by: Li Lingfeng Signed-off-by: Chuck Lever

sunrpc: suppress warnings for unused procfs functions

2025-02-25T20:04:25+00:00

There is a warning about unused variables when building with W=1 and no procfs: net/sunrpc/cache.c:1660:30: error: 'cache_flush_proc_ops' defined but not used [-Werror=unused-const-variable=] 1660 | static const struct proc_ops cache_flush_proc_ops = { | ^~~~~~~~~~~~~~~~~~~~ net/sunrpc/cache.c:1622:30: error: 'content_proc_ops' defined but not used [-Werror=unused-const-variable=] 1622 | static const struct proc_ops content_proc_ops = { | ^~~~~~~~~~~~~~~~ net/sunrpc/cache.c:1598:30: error: 'cache_channel_proc_ops' defined but not used [-Werror=unused-const-variable=] 1598 | static const struct proc_ops cache_channel_proc_ops = { | ^~~~~~~~~~~~~~~~~~~~~~ These are used inside of an #ifdef, so replacing that with an IS_ENABLED() check lets the compiler see how they are used while still dropping them during dead code elimination. Fixes: dbf847ecb631 ("knfsd: allow cache_register to return error on failure") Reviewed-by: Jeff Layton Acked-by: Chuck Lever Signed-off-by: Arnd Bergmann Signed-off-by: Anna Schumaker

SUNRPC: no need get cache ref when protected by rcu

2025-01-06T14:37:41+00:00

rcu_read_lock/rcu_read_unlock has already provide protection for the pointer we will reference when we call c_show. Therefore, there is no need to obtain a cache reference to help protect cache_head. Additionally, the .put such as expkey_put/svc_export_put will invoke dput, which can sleep and break rcu. Stop get cache reference to fix them all. Fixes: ae74136b4bb6 ("SUNRPC: Allow cache lookups to use RCU protection rather than the r/w spinlock") Suggested-by: NeilBrown Signed-off-by: Yang Erkun Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

SUNRPC: introduce cache_check_rcu to help check in rcu context

2025-01-06T14:37:40+00:00

This is a prepare patch to add cache_check_rcu, will use it with follow patch. Suggested-by: NeilBrown Signed-off-by: Yang Erkun Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

SUNRPC: make sure cache entry active before cache_show

2024-11-19T01:23:05+00:00

The function `c_show` was called with protection from RCU. This only ensures that `cp` will not be freed. Therefore, the reference count for `cp` can drop to zero, which will trigger a refcount use-after-free warning when `cache_get` is called. To resolve this issue, use `cache_get_rcu` to ensure that `cp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 Call Trace: c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Yang Erkun Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

[tree-wide] finally take no_llseek out

2024-09-27T15:18:43+00:00

no_llseek had been defined to NULL two years ago, in commit 868941b14441 ("fs: remove no_llseek") To quote that commit, At -rc1 we'll need do a mechanical removal of no_llseek - git grep -l -w no_llseek | grep -v porting.rst | while read i; do sed -i '/\/d' $i done would do it. Unfortunately, that hadn't been done. Linus, could you do that now, so that we could finally put that thing to rest? All instances are of the form .llseek = no_llseek, so it's obviously safe. Signed-off-by: Al Viro Signed-off-by: Linus Torvalds