This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/16919] recvmsg standard compliance


https://sourceware.org/bugzilla/show_bug.cgi?id=16919

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> ---
Fixing this issue is a lot harder than it looks, especially since the kernel
folks went and added sendmmsg/recvmmsg that also use these structures. For both
recvmmsg and sendmmsg the msghdr structures lie in memory that's (by the
interface contract) writable by the function so it's easy to just patch zeros
into the padding slots before making the syscall. However sendmmsg's msghdr
points to an already-filled control buffer containing cmsghdr structures that
may contain junk in their padding areas, and this buffer is NOT writable. So
you have to do something like copying the control buffers (which may be of very
large total length) to a copy, modifying the msghdr structures to point to the
copies, making the syscall, then putting it all back. At that point it might be
easier (this is what we do in musl) to just loop calling sendmsg rather than
bothering with the sendmmsg syscall...

We should really just demand that this be fixed on the kernel side, so that
when glibc drops support for old kernels somewhere down the line, these ugly
hacks can be dropped and the syscalls can just be safely usable directly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]