[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