[Openais] [openais] [whitetank] - Patch totemsrp so orf_token_mcast will not fall in case message_item->iov_len == IOVLEN

Jan Friesse jfriesse at redhat.com
Thu Oct 29 01:38:54 PDT 2009


Steve, rohara,
using SORT_QUEUE_ITEM_MAXIOVS is really unnecessary, but it make code
more readable (why somewhere should be MAGIC_CONSTANT + 1?). Anyway,
there is problem and as I wrote, it's in orf_token_mcast, because you
are using item 0 to save message_item->mcast and without any problem
copy copy (in this case) iovec array with 5 items to
&sort_queue_item.iovec[1].

So solution could be (of course) backport corosync code, because it has
no such code.

My solution is shorter and with 2 hours of running heavily loaded
aisexec (cpgbench, evsbench, ...) didn't show any problem (of course,
this doesn't mean, there couldn't be any). So for me, it looks like
solve problem.

Anyway, what do you think is proper solution?

Honza

Steven Dake wrote:
> On Tue, 2009-10-27 at 18:42 -0500, Ryan O'Hara wrote:
>> On Tue, Oct 27, 2009 at 06:18:44PM +0100, Jan Friesse wrote:
>>> See patch. I hope this will fix  
>>> https://bugzilla.redhat.com/show_bug.cgi?id=525280.
>>>
>>> Regards,
>>>   Honza
>>>
>> Do we really need SORT_QUEUE_ITEM_MAXIOVS? Perhaps using "MAXIOVS + 1"
>> in the EVT code is sufficient.
>>
> 
> My general response to this is that if we are running into the MAXIOVS
> constraint on the data structure, increasing MAXIOVS by 1 is not going
> to solve the problem (although it may hide this fault condition).
> 
> The use of an extra define as you point out is unnecessary.
> 
> Regards
> -steve
> 
>> Ryan
>>
>>
>>> diff --git a/branches/whitetank/exec/totemsrp.c b/branches/whitetank/exec/totemsrp.c
>>> index c11a552..c5a74e8 100644
>>> --- a/branches/whitetank/exec/totemsrp.c
>>> +++ b/branches/whitetank/exec/totemsrp.c
>>> @@ -87,6 +87,7 @@
>>>  #define RETRANS_MESSAGE_QUEUE_SIZE_MAX		500 /* allow 500 messages to be queued */
>>>  #define RECEIVED_MESSAGE_QUEUE_SIZE_MAX		500 /* allow 500 messages to be queued */
>>>  #define MAXIOVS					5	
>>> +#define SORT_QUEUE_ITEM_MAXIOVS			MAXIOVS + 1
>>>  #define RETRANSMIT_ENTRIES_MAX			30
>>>  #define TOKEN_SIZE_MAX				64000 /* bytes */
>>>  
>>> @@ -278,7 +279,7 @@ struct message_item {
>>>  };
>>>  
>>>  struct sort_queue_item {
>>> -	struct iovec iovec[MAXIOVS];
>>> +	struct iovec iovec[SORT_QUEUE_ITEM_MAXIOVS];
>>>  	int iov_len;
>>>  };
>>>  
>>> @@ -1916,7 +1917,7 @@ static void memb_state_recovery_enter (
>>>  	strcat (is_originated, seqno_string_hex);
>>>  	sort_queue_item = ptr;
>>>  	assert (sort_queue_item->iov_len > 0);
>>> -	assert (sort_queue_item->iov_len <= MAXIOVS);
>>> +	assert (sort_queue_item->iov_len <= SORT_QUEUE_ITEM_MAXIOVS);
>>>  	messages_originated++;
>>>  	memset (&message_item, 0, sizeof (struct message_item));
>>>  // TODO	 LEAK
>>> _______________________________________________
>>> Openais mailing list
>>> Openais at lists.linux-foundation.org
>>> https://lists.linux-foundation.org/mailman/listinfo/openais
>> _______________________________________________
>> Openais mailing list
>> Openais at lists.linux-foundation.org
>> https://lists.linux-foundation.org/mailman/listinfo/openais
> 



More information about the Openais mailing list