diff options
author | Vasant Hegde <hegdevasant@linux.vnet.ibm.com> | 2020-12-17 12:29:28 +0530 |
---|---|---|
committer | Vasant Hegde <hegdevasant@linux.vnet.ibm.com> | 2021-01-06 14:54:40 +0530 |
commit | 489cf50817441684ab8d70e9e3e2f019bfe4475c (patch) | |
tree | be7e3539c9e11eb318aafb7b044a9aee6b02d2ed /include | |
parent | 4b2450e3011ee1401b875cf43c58adf86a4b7394 (diff) | |
download | skiboot-489cf50817441684ab8d70e9e3e2f019bfe4475c.zip skiboot-489cf50817441684ab8d70e9e3e2f019bfe4475c.tar.gz skiboot-489cf50817441684ab8d70e9e3e2f019bfe4475c.tar.bz2 |
SBE: Check timer state before scheduling timer
[ Upstream commit 47ab3a92298e72e44b9477a02b1312a09272a54a ]
Timer flow:
- OPAL sends timer chip-op to SBE and waits for ACK
- Until we get ACK interrupt from SBE we will not schedule any new timer
- Once we get ACK either we wait for timer expiry -OR- schedule
new one if new-timer-request < inflight-timer-timeout value.
- If we get new timer request while processing current one
p9_sbe_update_timer_expiry code sets `has_new_target` and we
schedule it in ACK path (p9_sbe_timer_resp()).
p9_sbe_timer_resp() is callback handler and its called without lock.
It does not check whether timer message is busy or not (timer_ctrl_msg).
So in theory we may hit below scenario and corrupt msg_list.
CPU 1 -> Timer ACK (callback handler) -- its not holding any lock
CPU 2 -> Grabbed sbe_timer_lock -> scheduled timer --> done
CPU 3 -> p9_sbe_update_timer_expiry() -> see timer is busy -> sets has_new_timer -> done
CPU 1 -> gets chance to grab sbe_timer_lock -> saw has_new_timer -> Called p9_sbe_timer_schedule() --> List corrupted !
This patch adds timer message busy check in p9_sbe_timer_resp().
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions