On 02/23/2011 12:53 AM, Fabio M. Di Nitto wrote: > On 2/22/2011 11:55 PM, Angus Salkeld wrote: >> On Tue, Feb 22, 2011 at 12:48:32PM -0700, Steven Dake wrote: >>> If the ring id file for the processor is less then 8 bytes, totemsrp would >>> assert. Our speculation is that this condition happens during a fencing >>> operation or local filesystem corruption. >>> >>> With this patch, Corosync will create fresh ring id file data when the >>> incorrect number of bytes are read from the ring id. >>> >>> Amend to use sizeof the strerror string length and PATH_MAX for the path >>> length. >>> >>> Signed-off-by: Steven Dake <[email protected]> >> Reviewed-by: Angus Salkeld <[email protected]> >> >> I hope the change from: >> read (fd, &memb_ring_id->seq, sizeof (unsigned long long)); >> to >> read (fd, &memb_ring_id->seq, sizeof (uint64_t)); >> >> won't cause any problems. > > On i686 i noticed the file being 8 bytes (unsigned long long)... I > wonder if you shutdown corosync, update packages with the fix, then > restart.. is it going to read garbage from the file? > > Fabio
uint64_t is 8 bytes on all platforms (unsigned long long is not well defined but usually 64 bits), and yes I have tested on i386 and x86_64 fedora vms. This brings up another point that the entire code base needs to be inttyped with uint64_t and uint32_t at some point in the future for long term maintenance reasons. Regards -steve > _______________________________________________ > Openais mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
