Menu
▾
▴
#2334 Duplicate Indication deliveries
This bug is being opened for SFCB used via the MCP FLDs for the sblim-sfcb-1.3.12-52 used for CIM functionality in IBM Power Systems' Service Processor firmware.
There is a problem that indications are sent with more than one filter.
e.g.
When we make indication filters and then the subscriptions, used the order of CIM_InstModification, CIM_InstCreation, and CIM_InstDeletion.
When we generate a CIM_InstModification indication, we get only one indication at the listening socket, and the filter name matches.
When we generate a CIM_InstCreation indication, we get two indications at the listening socket, where for the first, the filter name matches, but the second is CIM_InstModification.
When we generate a CIM_InstDeletion indication, we get three indications at the listening socket, where the first filter name matches, but the second is CIM_InstCreation and the third is CIM_InstModification.
It looks like code somewhere in the DeliverIndication path is starting at the end of the filter list, walks the list towards the beginning, finds a match and uses that filter to deliver an indication, but does not exit from the loop at that point. It continues to deliver indications until the start of the list is reached.
We also verified that after the SubscriptionRemovalTimeInterval is up, and we repeat the process of generating indications, the DeactivateFilter commands are issued to the indication provider in the same order, and the number of DeactivateFilter commands match the number of indications sent.
At this point a CIM query will show that all of the filters are still present, but the subscriptions have been deleted that use the filters named in the DeactivateFilter commands.
Once the filter list (or subscription list) gets messed up, the next call to CBDeliverIndication will crash.
P.S. We are already in discussion with Narasimha Sharoff and are opening this bug after discussing with him.
3483200-78367-patch
committed to git Apr 4
committed to CVS Mar 1