Created attachment 718022 [details]
6.4.z-bz929101-1-Put-handle-to-hdb-in-dispatch-on-unknown-message


Put handle to hdb in dispatch on unknown message

When we receive unknown dispatch type, we should put handle to hdb,
because it was correctly obtained. This problem is only cfg and confdb
libraries, cpg, evs, quorum, ... are not affected and works correctly.

Signed-off-by: Jan Friesse <jfriesse>
Reviewed-by: Fabio M. Di Nitto <fdinitto>

Created attachment 718023 [details]
6.4.z-bz929101-2-Properly-check-result-of-coroipcc_dispatch_put


Properly check result of coroipcc_dispatch_put

When result of coroipcc_dispatch_put it can happen, that one message is
delivered to user application multiple times.

Signed-off-by: Jan Friesse <jfriesse>
Reviewed-by: Fabio M. Di Nitto <fdinitto>

Created attachment 718024 [details]
6.4.z-bz929101-3-coroipcs-Ensure-rb-data-are-not-overwritten


coroipcs: Ensure rb data are not overwritten

With introduce of rb alignment (55600762), it's not enough to subtract
one from number of free bytes, but also alignment must be taken to
account. Easiest solution is to subtract 9 bytes.

Signed-off-by: Jan Friesse <jfriesse>
Reviewed-by: Steven Dake <sdake>

Created attachment 718025 [details]
6.4.z-bz929101-4-Properly-lock-pending_semops


Properly lock pending_semops

pending_semops variable can be changed in two threads. One is actual IPC
connection and second is coropoll. It's really scholar example of race
(one thread doing i++, second doing i--). If socket is full, it can
happen that IPC will increase value and coropoll will decrease,
resulting in unpredictable value. This means, that client IPC can be
informed about more messages then really available, resulting
in reading of garbage messages in library dispatch function.

Solution is to properly lock variable.

Signed-off-by: Jan Friesse <jfriesse>
Reviewed-by: Fabio M. Di Nitto <fdinitto>