summaryrefslogtreecommitdiff
path: root/scripts/kernel-doc.py
diff options
context:
space:
mode:
authorDongsheng Yang <dongsheng.yang@linux.dev>2025-09-01 05:42:00 +0000
committerMikulas Patocka <mpatocka@redhat.com>2025-09-01 13:30:39 +0200
commit1f9ad14aef064ced0f60caae60c62b989de25676 (patch)
tree49f5165a9f839b5dcaf87233d78fa4eec55301fd /scripts/kernel-doc.py
parent8d33a030c566e1f105cd5bf27f37940b6367f3be (diff)
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>
Diffstat (limited to 'scripts/kernel-doc.py')
0 files changed, 0 insertions, 0 deletions