[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Kernel or userland bug: file descript passing in Postfix
tron%zhadum.org.uk@localhost (Matthias Scheler) writes:
>After a lot of debugging and by comparing with a demo program kindly
>provided by Michael van Elst I came up with the attached patch for
>Postfix which seems to fix the problem.
>Is this really a bug in Postfix (in which I case I will commit the patch)
>or is it a kernel bug?
Whatever is considered a bug.... Postfix was changed this way
for compatibility with LP64.
RFC3542 which describes the interface (for IPv6) says that we
do it right:
[...] While sending an
application may or may not include padding at the end of last
ancillary data in msg_controllen and implementations must accept both
as valid. On receiving a portable application must provide space for
padding at the end of the last ancillary data as implementations may
copy out the padding at the end of the control message buffer and
include it in the received msg_controllen. When recvmsg() is called
if msg_controllen is too small for all the ancillary data items
including any trailing padding after the last item an implementation
may set MSG_CTRUNC.
msg_controllen is the size of the buffer for one or more control messages.
CMSG_LEN is the unpadded size of a control message.
CMSG_SPACE is the padded size of a control message.
The RFC allows us to
"copy out the padding at the end of the control message buffer",
an insists that portable applications must provide such a buffer.
I.e. postfix doesn't adhere to the RFC because it only provides
a smaller buffer.
On the other hand, there is nothing that forbids us to be tolerant
and support receiving into a buffer without space for padding.
Michael van Elst
"A potential Snark may lurk in every tree."
Main Index |
Thread Index |