Hi,
It is not a bug, but you are right that this is less than optimal,
and should probably be done the way you suggest.
buf_prepend() and the pre-allocated header space was
introduced at a late stage, to make it possible to send complete
buffers (in the tipc_send_bufXX()) calls directly from the user
without copying. I did not realize then that this would be
useful even in the "ordinary" tipc_sendXX()" calls.
There will not be a buffer overrun, though, because the permitted
buffer maximum is adjusted down internally (in media.c) for the pre-
allocated headroom. The max_buffer size as seen from the core
code is hence only 1404 bytes, which is an obvious waste of space, but
not a bug.
This is something I would like to change, but I can not prioritize it
right now. This is the kind of changes that easily go wrong, and
requires some analysis and testing. I will add it to our TODO list.
/Jon
all...@wi... <mailto:all...@wi...>
wrote:
Hi Jon:
I'm not sure if there is a latent bug in the msg_build() routine in
msg.h. Shouldn't the message header be placed into the empty buffer
using buf_copy_prepend() rather than buf_copy_append()?
My understanding is that buf_acquire() returns a buffer that has
reserved space at the front of the buffer for TIPC header (and any
bearer header too). However, using buf_copy_append() to insert the
message header won't taken advantage of this reserved space, and could
result in the ensuing buf_safe_append() operations overwriting the end
of the buffer.
Can you confirm this bug? My impression from past experience is that
Linux is fairly forgiving of buffer overruns of this sort, but it still
seems wrong.
Regards,
Al
|
