]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
dm-pcache: remove ctrl_lock for pcache_cache_segment
authorDongsheng Yang <dongsheng.yang@linux.dev>
Mon, 1 Sep 2025 05:42:00 +0000 (05:42 +0000)
committerMikulas Patocka <mpatocka@redhat.com>
Mon, 1 Sep 2025 11:30:39 +0000 (13:30 +0200)
commit1f9ad14aef064ced0f60caae60c62b989de25676
tree49f5165a9f839b5dcaf87233d78fa4eec55301fd
parent8d33a030c566e1f105cd5bf27f37940b6367f3be
dm-pcache: remove ctrl_lock for pcache_cache_segment

The smatch checker reports a “scheduler in atomic context” problem in
the following call chain:

miss_read_end_req()
   -> cache_seg_put()
      -> cache_seg_invalidate()
         -> cache_seg_gen_increase()
            -> mutex_lock(&cache_seg->ctrl_lock);

In practice, this `mutex_lock` will not actually schedule, because it is
only called when `cache_seg_put()` drops the last reference, which is
single-threaded. That is also why the issue never shows up during real
testing.

However, the code is still buggy. The original purpose of `ctrl_lock`
was to prevent read/write conflicts on the cache segment control
information. Looking at the current usage, all control information
accesses are single-threaded: reads only occur during the init phase,
where no conflicts are possible, and writes happen once in the init
phase (also single-threaded) and once when `cache_seg_put()` drops the
last reference (again single-threaded).

Therefore, this patch removes `ctrl_lock` entirely and adds comments in
the appropriate places to document this logic.

Signed-off-by: Dongsheng Yang <dongsheng.yang@linux.dev>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
drivers/md/dm-pcache/cache.h
drivers/md/dm-pcache/cache_segment.c