aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/cdns3/cdns3-ti.c
diff options
context:
space:
mode:
authorBreno Leitao <[email protected]>2025-07-16 17:38:48 +0000
committerTejun Heo <[email protected]>2025-07-17 01:02:12 +0000
commite14fd98c6d66cb76694b12c05768e4f9e8c95664 (patch)
treef9921177f9568e83adb6f96c17db56ede564b59d /drivers/usb/cdns3/cdns3-ti.c
parentselftests/sched_ext: Fix exit selftest hang on UP (diff)
downloadkernel-e14fd98c6d66cb76694b12c05768e4f9e8c95664.tar.gz
kernel-e14fd98c6d66cb76694b12c05768e4f9e8c95664.zip
sched/ext: Prevent update_locked_rq() calls with NULL rq
Avoid invoking update_locked_rq() when the runqueue (rq) pointer is NULL in the SCX_CALL_OP and SCX_CALL_OP_RET macros. Previously, calling update_locked_rq(NULL) with preemption enabled could trigger the following warning: BUG: using __this_cpu_write() in preemptible [00000000] This happens because __this_cpu_write() is unsafe to use in preemptible context. rq is NULL when an ops invoked from an unlocked context. In such cases, we don't need to store any rq, since the value should already be NULL (unlocked). Ensure that update_locked_rq() is only called when rq is non-NULL, preventing calling __this_cpu_write() on preemptible context. Suggested-by: Peter Zijlstra <[email protected]> Fixes: 18853ba782bef ("sched_ext: Track currently locked rq") Signed-off-by: Breno Leitao <[email protected]> Acked-by: Andrea Righi <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Cc: [email protected] # v6.15
Diffstat (limited to 'drivers/usb/cdns3/cdns3-ti.c')
0 files changed, 0 insertions, 0 deletions