This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/23037] New: initialize msg_flags to zero for sendmmsg() calls
- From: "guenther at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 07 Apr 2018 00:14:05 +0000
- Subject: [Bug libc/23037] New: initialize msg_flags to zero for sendmmsg() calls
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=23037
Bug ID: 23037
Summary: initialize msg_flags to zero for sendmmsg() calls
Product: glibc
Version: 2.27
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: guenther at gmail dot com
CC: drepper.fsp at gmail dot com
Target Milestone: ---
The BSD sendmsg(2) interface has a flags argument; the msg_flags member of the
supplied msghdr structure is totally ignored by that API.
It appears that in recent versions of the Linux kernel, that is *not* the case
for the sendmmsg(2) API and instead it uses at least the MSG_EOR flag from the
msg_flags member of each supplied msghdr structure: __sys_sendmmsg() invokes
___sys_sendmsg(), passing allowed_msghdr_flags=MSG_EOR, which is used to
indicate which flags from msg_flags to or-info the flags used for processing:
flags |= (msg_sys->msg_flags & allowed_msghdr_flags);
Since that looks to have been an intentional change on the kernel side, glibc
should initialize the msg_flags member for the calls it makes, particularly in
resolv/res_send.c
The sendmmsg(2) manpage should also be updated to document the need to
initialize the msg_flags members and perhaps call out that this is a difference
in behavior between sendmsg(2) and sendmmsg(2)
--
You are receiving this mail because:
You are on the CC list for the bug.