starfive-tech/linux.git/fs/fscache, branch rt-linux-release

fscache: Use only one fscache_object_cong_wait.

2023-11-06T11:24:42+00:00

In the commit mentioned below, fscache was converted from slow-work to workqueue. slow_work_enqueue() and slow_work_sleep_till_thread_needed() did not use a per-CPU workqueue. They choose from two global waitqueues depending on the SLOW_WORK_VERY_SLOW bit which was not set so it always one waitqueue. I can't find out how it is ensured that a waiter on certain CPU is woken up be the other side. My guess is that the timeout in schedule_timeout() ensures that it does not wait forever (or a random wake up). fscache_object_sleep_till_congested() must be invoked from preemptible context in order for schedule() to work. In this case this_cpu_ptr() should complain with CONFIG_DEBUG_PREEMPT enabled except the thread is bound to one CPU. wake_up() wakes only one waiter and I'm not sure if it is guaranteed that only one waiter exists. Replace the per-CPU waitqueue with one global waitqueue. Fixes: 8b8edefa2fffb ("fscache: convert object to use workqueue instead of slow-work") Reported-by: Gregor Beck Cc: stable-rt@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior Link: https://lkml.kernel.org/r/20211029083839.xwwt7jgzru3kcpii@linutronix.de

fscache: Remove an unused static variable

2021-10-04T21:13:12+00:00

The fscache object CREATE_OBJECT work state isn't ever referred to, so remove it and avoid the unused variable warning caused by W=1. Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2

fscache: Fix some kerneldoc warnings shown up by W=1

2021-10-04T21:11:00+00:00

Fix some kerneldoc warnings in the fscache driver that are shown up by W=1. Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: Mauro Carvalho Chehab cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2

fscache: Use refcount_t for the cookie refcount instead of atomic_t

2021-08-27T12:34:03+00:00

Use refcount_t for the fscache_cookie refcount instead of atomic_t and rename the 'usage' member to 'ref' in such cases. The tracepoints that reference it change from showing "u=%d" to "r=%d". Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/162431204358.2908479.8006938388213098079.stgit@warthog.procyon.org.uk/

fscache: Fix fscache_cookie_put() to not deref after dec

2021-08-27T12:34:02+00:00

fscache_cookie_put() accesses the cookie it has just put inside the tracepoint that monitors the change - but this is something it's not allowed to do if we didn't reduce the count to zero. Fix this by dropping most of those values from the tracepoint and grabbing the cookie debug ID before doing the dec. Also take the opportunity to switch over the usage and where arguments on the tracepoint to put the reason last. Fixes: a18feb55769b ("fscache: Add tracepoints") Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/162431203107.2908479.3259582550347000088.stgit@warthog.procyon.org.uk/

fscache: Fix cookie key hashing

2021-08-27T12:34:02+00:00

The current hash algorithm used for hashing cookie keys is really bad, producing almost no dispersion (after a test kernel build, ~30000 files were split over just 18 out of the 32768 hash buckets). Borrow the full_name_hash() hash function into fscache to do the hashing for cookie keys and, in the future, volume keys. I don't want to use full_name_hash() as-is because I want the hash value to be consistent across arches and over time as the hash value produced may get used on disk. I can also optimise parts of it away as the key will always be a padded array of aligned 32-bit words. Fixes: ec0328e46d6e ("fscache: Maintain a catalogue of allocated cookies") Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/162431201844.2908479.8293647220901514696.stgit@warthog.procyon.org.uk/

fscache: Change %p in format strings to something else

2021-08-27T12:34:02+00:00

Change plain %p in format strings in fscache code to something more useful, since %p is now hashed before printing and thus no longer matches the contents of an oops register dump. Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/160588474843.3465195.5446072310069374803.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/162431199509.2908479.2950631488219944294.stgit@warthog.procyon.org.uk/

fscache: Remove the object list procfile

2021-08-27T12:34:02+00:00

Remove the object list procfile from fscache as objects will become entirely internal to the cache. Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/162431198332.2908479.5847286163455099669.stgit@warthog.procyon.org.uk/

fscache, cachefiles: Remove the histogram stuff

2021-08-27T12:34:02+00:00

Remove the histogram stuff as it's mostly going to be outdated. Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/162431195953.2908479.16770977195634296638.stgit@warthog.procyon.org.uk/

fscache: Procfile to display cookies

2021-08-27T12:34:02+00:00

Add /proc/fs/fscache/cookies to display active cookies. Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/158861211871.340223.7223853943667440807.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/159465771021.1376105.6933857529128238020.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/160588460994.3465195.16963417803501149328.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/162431194785.2908479.786917990782538164.stgit@warthog.procyon.org.uk/