[Bug 1844] Invalid MP packet prefix for message queues

bugzilla-daemon at rtems.org bugzilla-daemon at rtems.org
Thu Jul 21 13:11:10 UTC 2011


https://www.rtems.org/bugzilla/show_bug.cgi?id=1844

--- Comment #2 from Joel Sherrill <joel.sherrill at oarcorp.com> 2011-07-21 08:11:09 CDT ---
(In reply to comment #1)
> It seems that the MP_PACKET_MINIMUM_PACKET_SIZE is not too small.  The
> Message_queue_MP_Packet
> 
> typedef struct {
>   rtems_packet_prefix                Prefix;
>   Message_queue_MP_Remote_operations operation;
>   rtems_name                         name;
>   rtems_option                       option_set;
>   Objects_Id                         proxy_id;
>   uint32_t                           count;
>   size_t                             size;
>   uint32_t                           pad0;
>   CORE_message_queue_Buffer          Buffer;
> }   Message_queue_MP_Packet;
> 
> contains a CORE_message_queue_Buffer which is
> 
> typedef struct {
>   /** This field is the size of this message. */
>   size_t      size;
>   /** This field contains the actual message. */
>   uint32_t    buffer[1];
> } CORE_message_queue_Buffer;
> 
> Thus the sizeof(CORE_message_queue_Buffer) is actually not that useful.  On the
> other hand we have the pad0 field.  What is the use of this field? To put the
> buffer begin on a 64 byte alignment?

The real underlying problem is that this was designed and implemented
back when RTEMS VERY STRICTLY followed the RTEID and ORKID specifications.
That called for messages of fixed size of 16 bytes.   The MP support for
transferring messages was never fully updated to support
variable length messages.

The data in the prefix and "operation arguments" following that have
to be endian converted.  We were careful to ensure way back then that 
all fields in the structure were 32-bit so there were no alignment
issues and only one conversion routine was needed. But the user data
past that in a message send or receive operation should not be endian 
converted.  It is the user's responsibility.

All of this is leading up to the problem that the mpci driver ultimately
defines the actual size of the packet and this places a limit on the
length of messages transferred.  The marshalling code in and out of
the message buffers needs to be examined in context of variable
messages.  There needs to be a way for the mpci driver to let RTEMS
know how large the packet size is so we can determine if the desired
message size can be supported when the queue is global.  

> I think that the packet setup in _Message_queue_MP_Send_request_packet() is
> wrong.  Here we have
> 
>       the_packet->Prefix.length     = sizeof(Message_queue_MP_Packet);
>       if ( size_p )
>         the_packet->Prefix.length     += *size_p;
>       the_packet->Prefix.to_convert = sizeof(Message_queue_MP_Packet);
> 
> and
> 
>       the_packet->Prefix.length     = sizeof(Message_queue_MP_Packet);
>       the_packet->Prefix.to_convert = sizeof(Message_queue_MP_Packet);
> 
> This will convert one 32-bit word of the message, due to the unsuitable usage
> of sizeof() in this particular case?

This worked when sizeof a message was exactly 16-bytes but is wrong now.
There is no mechanism, as explained above, to account for the variable
length message and ultimate limit imposed by a particular MPCI implementation.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the bugs mailing list