summaryrefslogtreecommitdiffstats
path: root/include/uapi/misc
diff options
context:
space:
mode:
authorOhad Sharabi <osharabi@habana.ai>2021-12-07 13:30:20 +0100
committerOded Gabbay <ogabbay@kernel.org>2021-12-26 07:59:09 +0100
commite2558f0f84d85bfe2407b91d57798f133d8ad32a (patch)
tree8780499666f4ddfd5a5af42e69ea563f8a7d5d34 /include/uapi/misc
parenthabanalabs: modify cpu boot status error print (diff)
downloadlinux-e2558f0f84d85bfe2407b91d57798f133d8ad32a.tar.xz
linux-e2558f0f84d85bfe2407b91d57798f133d8ad32a.zip
habanalabs: prevent wait if CS in multi-CS list completed
By the original design we assumed that if we "miss" multi CS completion it is of no severe consequence as we'll just call wait_for_multi_cs again. Sequence of events for such scenario: 1. user submit CS with sequence N 2. user calls wait for multi-CS with only CS #N in the list 3. the multi CS call starts with poll of the CSs but find that none completed (while CS #N did not completed yet) 4. now, multi CS #N complete but multi CS CTX was not yet created for the above multi-CS. so, attempt to complete multi-CS fails (as no multi CS CTX exist) 5. wait_for_multi_cs call now does init_wait_multi_cs_completion (and for this create the multi-CS CTX) 6. wait_for_multi_cs wits on completion but will not get one as CS #N already completed To fix the issue we initialize the multi-CS CTX prior polling the fences. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Diffstat (limited to 'include/uapi/misc')
0 files changed, 0 insertions, 0 deletions