- **status**: assigned --> unassigned
- **Milestone**: 4.4.FC --> future
---
** [tickets:#40] IMM: Protect OI-handles against rapid switching of OI role.**
**Status:** unassigned
**Created:** Tue May 07, 2013 11:31 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue Sep 17, 2013 10:34 AM UTC
**Owner:** Anders Bjornerstedt
Migrated from:
http://devel.opensaf.org/ticket/3092
----------------------------------------------------------
This is related to the issues in #3072 and #3086.
Repeated fast switching of OI role using the same OI handle can
in theory result in imma library crashes due to a message being
delivered to the "wrong" implementer. That is ImplementerSet??,
implementerClear, implementerSet, ....etc. can result in a callback
arriving on the handle when has changed its role from that which
the callback was intended for.
This ticket could be classed as a defect. The reason we class it
as an enhancement is that we have not actually seen this happen
yet and the fix is quite complex and thus not without risk.
If a role switch occurs when there are messages backloged destined
for the old role, but arriving to the OI in the new role, then
this will cause the same symptom as the race fix in #3072.
The backloged messages may actually reside in two places.
Either backlogged in the incomming MDS buffer and not yet
processed by the MDS thread, Or backlogged in the process internal
IPC queue between the MDS thread and the application thread.
The crash actually observed was in the MDS thread which indicates
MDS backlog to the old role. We have not seen an incident of the
second case, but it is sure to happen sooner or later since
we have seen the first case.
I propose to fix this issue by adding a generation counter to
the client_node/handle. The generation counter is incremented
each time a successful reply on implementerClear is received.
Messages put to the IPC queue by the MDS thread will be stamped
with the generation count at the time of MDS reception. On
the other side, saImmOiDispatch() will check that the generation
count of the message matches the generation count of the handle
at the time of reception in the application thread. If it does not
match then the message is discarded.
On the server side, the IMMND will also have a generationCount
associated with the connection. It will increment the
generationCount when it is replying OK on an implementerClear
for that connection.
The IMMND sending an OI callback message to the client will stamp
the message with the generationCount. The MDS thread in the client
receiving the message will check that the generation count of
the MDS message destined for OI has the same generation count
as the generationCount of the handle. If not, the message is
discarded.
There should be no need for the OI to send the generationCount
to the server. This since they are incremented on both sides
by the same logical event, a successful implementerClear.
There is of course the issue of ERR_TIMEOUT on implementerClear.
If this happens then the only practical solution would be to
mark the handle as stale and exposed. But this case should be rare.
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
