Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 929096

Summary: CPG: Corosync can duplicate and/or lost messages - Local IPC
Product: Red Hat Enterprise Linux 6 Reporter: Libor Miksik <lmiksik>
Component: corosyncAssignee: Jan Friesse <jfriesse>
Status: CLOSED ERRATA QA Contact: Cluster QE <mspqa-list>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.4CC: abienven, bmarson, cluster-maint, jfriesse, jkortus, mjuricek, perfbz, pm-eus, sdake
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: corosync-1.2.3-36.el6_1.8 Doc Type: Bug Fix
Doc Text:
When running applications which used the Corosync IPC library, some messages in the dispatch() function were lost or duplicated. This update properly checks the return values of the dispatch_put() function, returns the correct remaining bytes in the IPC ring buffer, and ensures that the IPC client is correctly informed about the real number of messages in the ring buffer. Now, messages in the dispatch() function are no longer lost or duplicated.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-08 12:16:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 922671    
Bug Blocks:    
Attachments:
Description Flags
6.1.z-bz929096-1-Put-handle-to-hdb-in-dispatch-on-unknown-message
none
6.1.z-bz929096-2-Properly-check-result-of-coroipcc_dispatch_put
none
6.1.z-bz929096-3-Properly-lock-pending_semops none

Description Libor Miksik 2013-03-29 09:17:39 UTC
This bug has been copied from bug #922671 and has been proposed
to be backported to 6.1 z-stream (EUS).

Comment 4 Jan Friesse 2013-04-02 07:42:51 UTC
Created attachment 730642 [details]
6.1.z-bz929096-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>

Comment 5 Jan Friesse 2013-04-02 07:43:05 UTC
Created attachment 730644 [details]
6.1.z-bz929096-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>

Comment 6 Jan Friesse 2013-04-02 07:43:08 UTC
Created attachment 730645 [details]
6.1.z-bz929096-3-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>

Comment 11 errata-xmlrpc 2013-04-08 12:16:57 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0713.html