Occationally when multiple sessions are waiting for firmware
response and at the same time if there was a system error
received which will deinitalize the core and remove all sessions
from core list. If client opened new session which will initialize
the core and start the new session. As there will be no response
for old sessions, eventually, they will timeout and try to deinitialize
the core which will reset new session also which is not correct.
So check if timed out session is valid (present in core list) before
deintializing the core from timeout session.
This change also addresses below race condition issue -
If client is opening multiple new sessions and multiple old sessions
are also timedout at the same time and all are waiting for core lock
to be acquired. The new session does init_completion(&core->init_done);
and release core lock before waiting for completion event. As core lock
was released the timed out session will acquire the core lock and deinit
the core and release core lock. As core was deinited, another new session
will do init_completion(&core->init_done); on which the previous session
was waiting for completion event. doing init_completion again on an
already waiting completion event will result in list corruption issues.
Change-Id: I94766ead8b3ecad7d0b87f4b999608f435d0cee2
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
d0af60e008