reject retransmitted tokens
if token.aru = aru in token on last rotation ... do some logic
Here is how the current code works:
last_aru = instance->my_last_aru;
instance->my_last_aru = token->aru;
reject retransmitted tokens
if token.aru = aru in token on last rotation ... do some logic
The issue is last_aru will be set to token->aru when a token retransmission
occurs before a new token arrives.
This results in the "do some logic" part happening more often then it should.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2917 fd59a12c-fef9-0310-b244-a6a79926bd2f
'dump_subsys_config()' which is is turn used by the static function
'dump_full_config()' which is never used.
Are these functions used by someone using some magic? I did not find
any reference and even the flag LOGSYS_DEBUG, which prevents them from
compiling, does not exist at some other point.
If these functions are really not used, please remove them (because at
least one of them has a buffer overflow). Patch against 1.2.3
is attached.
If there is a need for these functions, I'll send a patch to fix
the 'decode_mode()' function.
Kind regards
Andreas Florath
Signed-off-by: Andreas Florath <gnu4u at flonatel dot org>
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2915 fd59a12c-fef9-0310-b244-a6a79926bd2f
we had some __attribute__((__noreturn__))
and some __attribute__((noreturn))
I made them all: __attribute__((noreturn))
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2853 fd59a12c-fef9-0310-b244-a6a79926bd2f
trigger the dumping of flight data using:
corosync-objctl -w runtime.blackbox.dump_flight_data=anything
trigger the dumping of state using:
corosync-objctl -w runtime.blackbox.dump_state=anything
then read the flight data as usual:
corosync-fplay
This patch includes a wrapper script called:
corosync-blackbox
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2799 fd59a12c-fef9-0310-b244-a6a79926bd2f
newly retransmitted entry from the list. It is possible this memmove operation
can buffer overflow because it has an invalid length calculation fixed by this
revision.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2794 fd59a12c-fef9-0310-b244-a6a79926bd2f
- Memset for res_setup variable in coroipcs:req_setup_send
- Two memset in logsys for buffers
- Problem in corosync_totem_stats_updater where avg_token_holdtime has
size of avg_backlog_calc
- corosync_totem_stats_init where avg_backlog_calc is 32 bits (not 64)
- objdb problem if new_valie_len != object->value_len. In such case
newly allocated memory is not initialized and in some situations,
value_len is not updated.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2787 fd59a12c-fef9-0310-b244-a6a79926bd2f
This patch fixes crashes found by repeated pacemaker CTS SimluStart
tests. When you bring up the nodes together it can cause a lot of
configuration changes and sync gets started and aborted
lots of times.
When abort is called the ring_id is not changed which means that any
sync packet that arrive from that point on will be accepted as valid.
I have seen old barrier messages causing the processing index to increment
later causing an array out of bounds.
This patch memsets the ring_id to 0, thus causing the ring_id in the packet and
my_ring_id not to match.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2757 fd59a12c-fef9-0310-b244-a6a79926bd2f
1) don't send notifications if the key is the same.
2) Add key value change notifications to key_inc & key_dec
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2746 fd59a12c-fef9-0310-b244-a6a79926bd2f
1. the reload callback was not sent to the library,
2. totem exponentially added new callbacks because the old ones were not
removed properly.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2684 fd59a12c-fef9-0310-b244-a6a79926bd2f