aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorVasant Hegde <hegdevasant@linux.vnet.ibm.com>2020-12-17 12:29:28 +0530
committerVasant Hegde <hegdevasant@linux.vnet.ibm.com>2021-01-06 14:54:40 +0530
commit489cf50817441684ab8d70e9e3e2f019bfe4475c (patch)
treebe7e3539c9e11eb318aafb7b044a9aee6b02d2ed /include
parent4b2450e3011ee1401b875cf43c58adf86a4b7394 (diff)
downloadskiboot-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