msm: kgsl: Remove a race condition in the event processing code
There could be a race condition if a thread is adding an event while
another thread is processing events. Say that thread A is adding an
event and thread B is processing events. A could read the timestamp
and see that it isn't retired yet and wait for the spinlock to add
it to the list. Meanwhile the timestamp gets retired and the retire
thread takes the spinlock first and proceses the list. End result
is the event for the newly expired timestamp gets added to the list
after the timestamp retires. If there are no subsequent events then
the lame duck event will just sit there.
Avoid this race condition by taking the spinlock before considering
the timestamp. This serializes the two threads ensuring that a new
event cannot be added after the same timestamp is retired.
The race condition could still fail with the locks in the right place
if different cores got different timestamp values so add the correct
barriers to the memory read/write functions to ensure that all cores
read the same value at the same time.
Change-Id: Ic0dedbad02e7aeeaab48373ab28f4dc9cce50db2
Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org>
Loading
Please register or sign in to comment