From: Daniel Kabs <dkabs@mobotix.com>
To: linux-kernel@vger.kernel.org
Subject: Problem with unix sockets: SOCK_DGRAM ignores MSG_TRUNC
Date: Mon, 29 Jan 2007 12:59:49 +0100 [thread overview]
Message-ID: <200701291259.50155.dkabs@mobotix.com> (raw)
Hi,
I use unix domain datagram sockets for IPC, e.g. I receive messages by
calling recv().
"man 2 recv" tells me about the flags argument to a recv() call, namely:
MSG_TRUNC
Return the real length of the packet, even when it was longer
than the passed buffer. Only valid for packet sockets.
Thus I used recv() with flags MSG_TRUNC|MSG_PEEK in order to detect
message truncation due to insufficient buffer size.
Strangely enough, MSG_TRUNC seems to get ignored by the kernel: If the
message received is larger than the receive buffer I supplied, the
function returns the size of the buffer. I think, the function should
return the real message length instead (at least according to the manual
page).
To work around this problem, I now use the ioctl FIONREAD instead.
On the other hand, in this mailing list, I found an old bug report
describing the same problem using UDP sockets:
http://groups.google.com/group/fa.linux.kernel/browse_frm/thread/fb6acbb527507e26/ad0b2ba33b6b66fa
UDP sockets seem to have been patched by now. From linux/net/ipv4/udp.c:
udp_recvmsg()
...
err = copied;
if (flags & MSG_TRUNC)
err = skb->len - sizeof(struct udphdr);
...
Why doesn't unix_dgram_recvmsg() in linux/net/unix/af_unix.c contain code
to this effect? Is this a feature or a bug? What is the correct semantics
of MSG_TRUNC when used for unix sockets?
Cheers
Daniel Kabs
PS: According to some lkml archives, my previous mail did not come
through, so I reposted it.
next reply other threads:[~2007-01-29 11:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-29 11:59 Daniel Kabs [this message]
2007-02-05 0:52 ` Problem with unix sockets: SOCK_DGRAM ignores MSG_TRUNC David Miller
2007-02-06 12:55 ` Daniel Kabs
2007-02-06 20:11 ` David Schwartz
2007-02-07 8:58 ` Daniel Kabs
2007-02-07 9:31 ` Daniel Kabs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200701291259.50155.dkabs@mobotix.com \
--to=dkabs@mobotix.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox