| Message ID | 1459175641-12520-3-git-send-email-adhemerval.zanella@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 28/03/16 15:34, Adhemerval Zanella wrote: > POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen > to be of size int and socklen_t respectively. However Linux defines it as > both size_t and for 64-bit it requires some adjustments to make the > functions standard compliance. > > This patch fixes it by creating a temporary header and zeroing the pad > fields for 64-bits architecture where size of size_t exceeds the size of > the int. sendmsg is harder to fix because cmsghdr also needs fix ups: > /* Structure used for storage of ancillary data object information. */ > struct cmsghdr > { > - size_t cmsg_len; /* Length of data in cmsg_data plus length > - of cmsghdr structure. > - !! The type should be socklen_t but the > - definition of the kernel is incompatible > - with this. */ > +#if __BYTE_ORDER == __BIG_ENDIAN > + int __glibc_reserved1; /* Pad toadjust Linux size to POSIX defined > + size for cmsg_len. */ > + socklen_t cmsg_len; /* Length of data in cmsg_data plus length > + of cmsghdr structure. */ > +#else > + socklen_t cmsg_len; > + int __glibc_reserved1; > +#endif > int cmsg_level; /* Originating protocol. */ > int cmsg_type; /* Protocol specific type. */ ... > ssize_t > __libc_sendmsg (int fd, const struct msghdr *msg, int flags) > { > + /* POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen > + to be int and socklen_t respectively. However Linux defines it as > + both size_t. So for 64-bit it requires some adjustments by copying to > + temporary header and zeroing the pad fields. */ > +#if __WORDSIZE == 64 > + struct msghdr hdr; > + if (msg != NULL) > + { > + hdr = *msg; > + hdr.__glibc_reserved1 = 0; > + hdr.__glibc_reserved2 = 0; > + msg = &hdr; > + } > +#endif e.g. user supplied msg.msg_control might contain cmsghdr with __glibc_reserved1 != 0 since user code might not initialize the struct. in musl this is fixed by copying the controls to a tmp buf on the stack (which has fixed size so it can fail) and fixing the paddings there.
On 03/28/2016 04:34 PM, Adhemerval Zanella wrote: > diff --git a/sysdeps/unix/sysv/linux/check_native.c b/sysdeps/unix/sysv/linux/check_native.c > index b3cbbe3..a8e447e 100644 > --- a/sysdeps/unix/sysv/linux/check_native.c > +++ b/sysdeps/unix/sysv/linux/check_native.c > @@ -111,10 +111,13 @@ __check_native (uint32_t a1_index, int *a1_native, > { > struct msghdr msg = > { > - (void *) &nladdr, sizeof (nladdr), > - &iov, 1, > - NULL, 0, > - 0 > + .msg_name = (void *) &nladdr, > + .msg_namelen = sizeof (nladdr), > + .msg_iov = &iov, > + .msg_iovlen = 1, > + .msg_control = NULL, > + .msg_controllen = 0, > + .msg_flags = 0 > }; The requirement for such changes always makes me nervous. If we have breakage in our own code, how many applications are affected? Note that the recvmsg manual page says “is defined as follows” about struct msghdr, not “contains the following members in some arbitrary order”. Is standards compliance here really worth this risk? (I do not have a strong opinion either way, I just want to raise this point.) Florian
On 07/04/16 10:56, Florian Weimer wrote: > On 03/28/2016 04:34 PM, Adhemerval Zanella wrote: >> diff --git a/sysdeps/unix/sysv/linux/check_native.c b/sysdeps/unix/sysv/linux/check_native.c >> index b3cbbe3..a8e447e 100644 >> --- a/sysdeps/unix/sysv/linux/check_native.c >> +++ b/sysdeps/unix/sysv/linux/check_native.c >> @@ -111,10 +111,13 @@ __check_native (uint32_t a1_index, int *a1_native, >> { >> struct msghdr msg = >> { >> - (void *) &nladdr, sizeof (nladdr), >> - &iov, 1, >> - NULL, 0, >> - 0 >> + .msg_name = (void *) &nladdr, >> + .msg_namelen = sizeof (nladdr), >> + .msg_iov = &iov, >> + .msg_iovlen = 1, >> + .msg_control = NULL, >> + .msg_controllen = 0, >> + .msg_flags = 0 >> }; > > The requirement for such changes always makes me nervous. If we have > breakage in our own code, how many applications are affected? > yes, it looks risky. > Note that the recvmsg manual page says “is defined as follows” about > struct msghdr, not “contains the following members in some arbitrary order”. > i think the man page should be more clear about that the msg_controllen, msg_iovlen and cmsg_len types conflict with posix. to prevent more non-portable code being written based on the linux man page. > Is standards compliance here really worth this risk? > > (I do not have a strong opinion either way, I just want to raise this > point.) > > Florian >
On 07-04-2016 06:22, Szabolcs Nagy wrote: > On 28/03/16 15:34, Adhemerval Zanella wrote: >> POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen >> to be of size int and socklen_t respectively. However Linux defines it as >> both size_t and for 64-bit it requires some adjustments to make the >> functions standard compliance. >> >> This patch fixes it by creating a temporary header and zeroing the pad >> fields for 64-bits architecture where size of size_t exceeds the size of >> the int. > > sendmsg is harder to fix because cmsghdr also needs fix ups: > >> /* Structure used for storage of ancillary data object information. */ >> struct cmsghdr >> { >> - size_t cmsg_len; /* Length of data in cmsg_data plus length >> - of cmsghdr structure. >> - !! The type should be socklen_t but the >> - definition of the kernel is incompatible >> - with this. */ >> +#if __BYTE_ORDER == __BIG_ENDIAN >> + int __glibc_reserved1; /* Pad toadjust Linux size to POSIX defined >> + size for cmsg_len. */ >> + socklen_t cmsg_len; /* Length of data in cmsg_data plus length >> + of cmsghdr structure. */ >> +#else >> + socklen_t cmsg_len; >> + int __glibc_reserved1; >> +#endif >> int cmsg_level; /* Originating protocol. */ >> int cmsg_type; /* Protocol specific type. */ > ... > >> ssize_t >> __libc_sendmsg (int fd, const struct msghdr *msg, int flags) >> { >> + /* POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen >> + to be int and socklen_t respectively. However Linux defines it as >> + both size_t. So for 64-bit it requires some adjustments by copying to >> + temporary header and zeroing the pad fields. */ >> +#if __WORDSIZE == 64 >> + struct msghdr hdr; >> + if (msg != NULL) >> + { >> + hdr = *msg; >> + hdr.__glibc_reserved1 = 0; >> + hdr.__glibc_reserved2 = 0; >> + msg = &hdr; >> + } >> +#endif > > e.g. user supplied msg.msg_control might contain cmsghdr > with __glibc_reserved1 != 0 since user code might not > initialize the struct. > > in musl this is fixed by copying the controls to a tmp > buf on the stack (which has fixed size so it can fail) > and fixing the paddings there. > Yes I am aware and I noted this in my patch header: 1. Current sendmsg fix does not handle larger msg_control neither pads the cmsghdr associated. The problem with this approach is to accomplish a complete fix it will require to allocate a limited buffer, copying the incoming struct and zero pad. Although it tend to work it also add some limitation of total msg_control length. The general usage for such facily is passing file descriptors and permissions between processes over unix sockets so it might be factible to use a large stack allocated buffer (1024, 2048 or large) and return ENOMEM for larger buffers. I am planning to send a fix for this based on this patch.
On 07-04-2016 08:37, Szabolcs Nagy wrote: > On 07/04/16 10:56, Florian Weimer wrote: >> On 03/28/2016 04:34 PM, Adhemerval Zanella wrote: >>> diff --git a/sysdeps/unix/sysv/linux/check_native.c b/sysdeps/unix/sysv/linux/check_native.c >>> index b3cbbe3..a8e447e 100644 >>> --- a/sysdeps/unix/sysv/linux/check_native.c >>> +++ b/sysdeps/unix/sysv/linux/check_native.c >>> @@ -111,10 +111,13 @@ __check_native (uint32_t a1_index, int *a1_native, >>> { >>> struct msghdr msg = >>> { >>> - (void *) &nladdr, sizeof (nladdr), >>> - &iov, 1, >>> - NULL, 0, >>> - 0 >>> + .msg_name = (void *) &nladdr, >>> + .msg_namelen = sizeof (nladdr), >>> + .msg_iov = &iov, >>> + .msg_iovlen = 1, >>> + .msg_control = NULL, >>> + .msg_controllen = 0, >>> + .msg_flags = 0 >>> }; >> >> The requirement for such changes always makes me nervous. If we have >> breakage in our own code, how many applications are affected? >> > > yes, it looks risky. > >> Note that the recvmsg manual page says “is defined as follows” about >> struct msghdr, not “contains the following members in some arbitrary order”. >> > > i think the man page should be more clear about > that the msg_controllen, msg_iovlen and cmsg_len > types conflict with posix. > > to prevent more non-portable code being written > based on the linux man page. > >> Is standards compliance here really worth this risk? >> >> (I do not have a strong opinion either way, I just want to raise this >> point.) >> >> Florian >> > I do not have a strong opinion as well, but I also do not see it a compelling reason to *not* follow the standard as well. I would follow Szabolcs suggestion and update the manual specifying to more portable way to access the structures is through designated initializers (which gcc accepts in c90 as well). Best option would be to get this fixed in kernel, but it is another thread.
On 28/03/16 15:34, Adhemerval Zanella wrote: > /* Structure used for storage of ancillary data object information. */ > struct cmsghdr > { > - size_t cmsg_len; /* Length of data in cmsg_data plus length > - of cmsghdr structure. > - !! The type should be socklen_t but the > - definition of the kernel is incompatible > - with this. */ > +#if __BYTE_ORDER == __BIG_ENDIAN > + int __glibc_reserved1; /* Pad toadjust Linux size to POSIX defined > + size for cmsg_len. */ > + socklen_t cmsg_len; /* Length of data in cmsg_data plus length > + of cmsghdr structure. */ > +#else > + socklen_t cmsg_len; > + int __glibc_reserved1; > +#endif > int cmsg_level; /* Originating protocol. */ > int cmsg_type; /* Protocol specific type. */ i think #if __WORDSIZE == 64 is missing here. but even in that case there is a subtle issue: if the size_t member is removed all other members have 4byte alignment, so the struct alignment changes from 8byte to 4byte. it is not clear from the standard how the msg_control buffer may be allocated (since only CMSG_* macros can access it), on linux the kernel makes a copy so it does not care about alignment in user-space, but the struct alignment is still visible in the c and c++ abi. msg_control usage should be probably documented in the linux man-page: glibc sunrpc sometimes uses plain char[], nscd uses a union with struct cmsghdr, i think neither of them makes a CMSG_FIRSTHDR (&msg)->cmsg_len access strictly iso c confrom, but the later at least uses correct alignment. maybe a posix issue should be filed to the austin group.
On Mon, Mar 28, 2016 at 11:34:00AM -0300, Adhemerval Zanella wrote: > POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen > to be of size int and socklen_t respectively. However Linux defines it as > both size_t and for 64-bit it requires some adjustments to make the > functions standard compliance. > > This patch fixes it by creating a temporary header and zeroing the pad > fields for 64-bits architecture where size of size_t exceeds the size of > the int. > > Also the new recvmsg and sendmsg implementation is only added on libc, > with libpthread only containing a compat symbol. Just a heads-up: this needs a bug report/patch to the Linux man-pages project as well, since they're currently documenting the wrong types. The documented types should probably be fixed to align with the standard, with a note about them previously being wrong added to the NOTES section. Rich
On 21-04-2016 11:01, Szabolcs Nagy wrote: > On 28/03/16 15:34, Adhemerval Zanella wrote: >> /* Structure used for storage of ancillary data object information. */ >> struct cmsghdr >> { >> - size_t cmsg_len; /* Length of data in cmsg_data plus length >> - of cmsghdr structure. >> - !! The type should be socklen_t but the >> - definition of the kernel is incompatible >> - with this. */ >> +#if __BYTE_ORDER == __BIG_ENDIAN >> + int __glibc_reserved1; /* Pad toadjust Linux size to POSIX defined >> + size for cmsg_len. */ >> + socklen_t cmsg_len; /* Length of data in cmsg_data plus length >> + of cmsghdr structure. */ >> +#else >> + socklen_t cmsg_len; >> + int __glibc_reserved1; >> +#endif >> int cmsg_level; /* Originating protocol. */ >> int cmsg_type; /* Protocol specific type. */ > > i think #if __WORDSIZE == 64 is missing here. > Right, I will add it. > but even in that case there is a subtle issue: > if the size_t member is removed all other > members have 4byte alignment, so the struct > alignment changes from 8byte to 4byte. > > it is not clear from the standard how the > msg_control buffer may be allocated (since > only CMSG_* macros can access it), on linux > the kernel makes a copy so it does not care > about alignment in user-space, but the struct > alignment is still visible in the c and c++ abi. Indeed and I am not sure how to enforce (and if it is really required) in the cleanest way. Do you think this as an blocker for such fix? I am asking because I am following the mips64 ip thread failure report for musl and looks like it is not really related to the change of struct alignment. Also I am testing on s390x and looks like both make check and ip shows no issue. > > msg_control usage should be probably documented > in the linux man-page: glibc sunrpc sometimes > uses plain char[], nscd uses a union with struct > cmsghdr, i think neither of them makes a > > CMSG_FIRSTHDR (&msg)->cmsg_len > > access strictly iso c confrom, but the later at > least uses correct alignment. > > maybe a posix issue should be filed to the > austin group. >
Hello Szabolcs On 21 April 2016 at 16:01, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > On 28/03/16 15:34, Adhemerval Zanella wrote: >> /* Structure used for storage of ancillary data object information. */ >> struct cmsghdr >> { >> - size_t cmsg_len; /* Length of data in cmsg_data plus length >> - of cmsghdr structure. >> - !! The type should be socklen_t but the >> - definition of the kernel is incompatible >> - with this. */ >> +#if __BYTE_ORDER == __BIG_ENDIAN >> + int __glibc_reserved1; /* Pad toadjust Linux size to POSIX defined >> + size for cmsg_len. */ >> + socklen_t cmsg_len; /* Length of data in cmsg_data plus length >> + of cmsghdr structure. */ >> +#else >> + socklen_t cmsg_len; >> + int __glibc_reserved1; >> +#endif >> int cmsg_level; /* Originating protocol. */ >> int cmsg_type; /* Protocol specific type. */ > > i think #if __WORDSIZE == 64 is missing here. > > but even in that case there is a subtle issue: > if the size_t member is removed all other > members have 4byte alignment, so the struct > alignment changes from 8byte to 4byte. > > it is not clear from the standard how the > msg_control buffer may be allocated (since > only CMSG_* macros can access it), on linux > the kernel makes a copy so it does not care > about alignment in user-space, but the struct > alignment is still visible in the c and c++ abi. > > msg_control usage should be probably documented > in the linux man-page: glibc sunrpc sometimes > uses plain char[], nscd uses a union with struct > cmsghdr, i think neither of them makes a > > CMSG_FIRSTHDR (&msg)->cmsg_len > > access strictly iso c confrom, but the later at > least uses correct alignment. > > maybe a posix issue should be filed to the > austin group. Below are the current snippets of code shown in the cmsg(3) man page. Could you please tell me more exactly what you think needs fixing? [[ EXAMPLE This code looks for the IP_TTL option in a received ancillary buffer: struct msghdr msgh; struct cmsghdr *cmsg; int *ttlptr; int received_ttl; /* Receive auxiliary data in msgh */ for (cmsg = CMSG_FIRSTHDR(&msgh); cmsg != NULL; cmsg = CMSG_NXTHDR(&msgh, cmsg)) { if (cmsg->cmsg_level == IPPROTO_IP && cmsg->cmsg_type == IP_TTL) { ttlptr = (int *) CMSG_DATA(cmsg); received_ttl = *ttlptr; break; } } if (cmsg == NULL) { /* Error: IP_TTL not enabled or small buffer or I/O error */ } The code below passes an array of file descriptors over a UNIX domain socket using SCM_RIGHTS: struct msghdr msg = {0}; struct cmsghdr *cmsg; int myfds[NUM_FD]; /* Contains the file descriptors to pass */ int *fdptr; union { /* Ancillary data buffer, wrapped in a union in order to ensure it is suitably aligned */ char buf[CMSG_SPACE(sizeof myfds)]; struct cmsghdr align; } u; msg.msg_control = u.buf; msg.msg_controllen = sizeof u.buf; cmsg = CMSG_FIRSTHDR(&msg); cmsg->cmsg_level = SOL_SOCKET; cmsg->cmsg_type = SCM_RIGHTS; cmsg->cmsg_len = CMSG_LEN(sizeof(int) * NUM_FD); fdptr = (int *) CMSG_DATA(cmsg); /* Initialize the payload */ memcpy(fdptr, myfds, NUM_FD * sizeof(int)); ]] Cheers, Michael
On 22/04/16 09:04, Michael Kerrisk (man-pages) wrote: > On 21 April 2016 at 16:01, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: >> it is not clear from the standard how the >> msg_control buffer may be allocated (since >> only CMSG_* macros can access it), on linux >> the kernel makes a copy so it does not care >> about alignment in user-space, but the struct >> alignment is still visible in the c and c++ abi. >> >> msg_control usage should be probably documented >> in the linux man-page: glibc sunrpc sometimes >> uses plain char[], nscd uses a union with struct >> cmsghdr, i think neither of them makes a >> >> CMSG_FIRSTHDR (&msg)->cmsg_len >> >> access strictly iso c confrom, but the later at >> least uses correct alignment. >> >> maybe a posix issue should be filed to the >> austin group. > > Below are the current snippets of code shown in the cmsg(3) man page. > Could you please tell me more exactly what you think needs fixing? > thanks, this is what i was looking for. (i missed cmsg(3), only looked at recvmsg(2) and sendmsg(2).) this means some code in glibc and iproute2 should be fixed to use such a union. (what a nasty interface.) > [[ > EXAMPLE > This code looks for the IP_TTL option in a received ancillary > buffer: > > struct msghdr msgh; > struct cmsghdr *cmsg; > int *ttlptr; > int received_ttl; > > /* Receive auxiliary data in msgh */ > > for (cmsg = CMSG_FIRSTHDR(&msgh); cmsg != NULL; > cmsg = CMSG_NXTHDR(&msgh, cmsg)) { > if (cmsg->cmsg_level == IPPROTO_IP > && cmsg->cmsg_type == IP_TTL) { > ttlptr = (int *) CMSG_DATA(cmsg); > received_ttl = *ttlptr; > break; > } > } > > if (cmsg == NULL) { > /* Error: IP_TTL not enabled or small buffer or I/O error */ > } > > The code below passes an array of file descriptors over a UNIX > domain socket using SCM_RIGHTS: > > struct msghdr msg = {0}; > struct cmsghdr *cmsg; > int myfds[NUM_FD]; /* Contains the file descriptors to pass */ > int *fdptr; > union { /* Ancillary data buffer, wrapped in a union > in order to ensure it is suitably aligned */ > char buf[CMSG_SPACE(sizeof myfds)]; > struct cmsghdr align; > } u; > > msg.msg_control = u.buf; > msg.msg_controllen = sizeof u.buf; > cmsg = CMSG_FIRSTHDR(&msg); > cmsg->cmsg_level = SOL_SOCKET; > cmsg->cmsg_type = SCM_RIGHTS; > cmsg->cmsg_len = CMSG_LEN(sizeof(int) * NUM_FD); > fdptr = (int *) CMSG_DATA(cmsg); /* Initialize the payload */ > memcpy(fdptr, myfds, NUM_FD * sizeof(int)); > ]] > > Cheers, > > Michael >
Hi Szabolcs, On 22 April 2016 at 12:25, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > On 22/04/16 09:04, Michael Kerrisk (man-pages) wrote: >> On 21 April 2016 at 16:01, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: >>> it is not clear from the standard how the >>> msg_control buffer may be allocated (since >>> only CMSG_* macros can access it), on linux >>> the kernel makes a copy so it does not care >>> about alignment in user-space, but the struct >>> alignment is still visible in the c and c++ abi. >>> >>> msg_control usage should be probably documented >>> in the linux man-page: glibc sunrpc sometimes >>> uses plain char[], nscd uses a union with struct >>> cmsghdr, i think neither of them makes a >>> >>> CMSG_FIRSTHDR (&msg)->cmsg_len >>> >>> access strictly iso c confrom, but the later at >>> least uses correct alignment. >>> >>> maybe a posix issue should be filed to the >>> austin group. >> >> Below are the current snippets of code shown in the cmsg(3) man page. >> Could you please tell me more exactly what you think needs fixing? >> > > thanks, this is what i was looking for. > (i missed cmsg(3), only looked at recvmsg(2) and sendmsg(2).) > > this means some code in glibc and iproute2 should be fixed > to use such a union. (what a nasty interface.) So, the code in the cmsg(3) man page seems okay then? Cheers, Michael >> [[ >> EXAMPLE >> This code looks for the IP_TTL option in a received ancillary >> buffer: >> >> struct msghdr msgh; >> struct cmsghdr *cmsg; >> int *ttlptr; >> int received_ttl; >> >> /* Receive auxiliary data in msgh */ >> >> for (cmsg = CMSG_FIRSTHDR(&msgh); cmsg != NULL; >> cmsg = CMSG_NXTHDR(&msgh, cmsg)) { >> if (cmsg->cmsg_level == IPPROTO_IP >> && cmsg->cmsg_type == IP_TTL) { >> ttlptr = (int *) CMSG_DATA(cmsg); >> received_ttl = *ttlptr; >> break; >> } >> } >> >> if (cmsg == NULL) { >> /* Error: IP_TTL not enabled or small buffer or I/O error */ >> } >> >> The code below passes an array of file descriptors over a UNIX >> domain socket using SCM_RIGHTS: >> >> struct msghdr msg = {0}; >> struct cmsghdr *cmsg; >> int myfds[NUM_FD]; /* Contains the file descriptors to pass */ >> int *fdptr; >> union { /* Ancillary data buffer, wrapped in a union >> in order to ensure it is suitably aligned */ >> char buf[CMSG_SPACE(sizeof myfds)]; >> struct cmsghdr align; >> } u; >> >> msg.msg_control = u.buf; >> msg.msg_controllen = sizeof u.buf; >> cmsg = CMSG_FIRSTHDR(&msg); >> cmsg->cmsg_level = SOL_SOCKET; >> cmsg->cmsg_type = SCM_RIGHTS; >> cmsg->cmsg_len = CMSG_LEN(sizeof(int) * NUM_FD); >> fdptr = (int *) CMSG_DATA(cmsg); /* Initialize the payload */ >> memcpy(fdptr, myfds, NUM_FD * sizeof(int)); >> ]] >> >> Cheers, >> >> Michael >> >
On 22/04/16 14:19, Michael Kerrisk (man-pages) wrote: > Hi Szabolcs, > > On 22 April 2016 at 12:25, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: >> On 22/04/16 09:04, Michael Kerrisk (man-pages) wrote: >>> On 21 April 2016 at 16:01, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: >>>> it is not clear from the standard how the >>>> msg_control buffer may be allocated (since >>>> only CMSG_* macros can access it), on linux >>>> the kernel makes a copy so it does not care >>>> about alignment in user-space, but the struct >>>> alignment is still visible in the c and c++ abi. >>>> >>>> msg_control usage should be probably documented >>>> in the linux man-page: glibc sunrpc sometimes >>>> uses plain char[], nscd uses a union with struct >>>> cmsghdr, i think neither of them makes a >>>> >>>> CMSG_FIRSTHDR (&msg)->cmsg_len >>>> >>>> access strictly iso c confrom, but the later at >>>> least uses correct alignment. >>>> >>>> maybe a posix issue should be filed to the >>>> austin group. >>> >>> Below are the current snippets of code shown in the cmsg(3) man page. >>> Could you please tell me more exactly what you think needs fixing? >>> >> >> thanks, this is what i was looking for. >> (i missed cmsg(3), only looked at recvmsg(2) and sendmsg(2).) >> >> this means some code in glibc and iproute2 should be fixed >> to use such a union. (what a nasty interface.) > > So, the code in the cmsg(3) man page seems okay then? > yes (i originally thought the cast in CMSG_FIRSTHDR from the union* to struct cmsghdr* would be invalid on the sending side, but it's ok. on the receiving side the dereference through the (int*) cast is debatable, but should work in practice.) > Cheers, > > Michael > >>> [[ >>> EXAMPLE >>> This code looks for the IP_TTL option in a received ancillary >>> buffer: >>> >>> struct msghdr msgh; >>> struct cmsghdr *cmsg; >>> int *ttlptr; >>> int received_ttl; >>> >>> /* Receive auxiliary data in msgh */ >>> >>> for (cmsg = CMSG_FIRSTHDR(&msgh); cmsg != NULL; >>> cmsg = CMSG_NXTHDR(&msgh, cmsg)) { >>> if (cmsg->cmsg_level == IPPROTO_IP >>> && cmsg->cmsg_type == IP_TTL) { >>> ttlptr = (int *) CMSG_DATA(cmsg); >>> received_ttl = *ttlptr; >>> break; >>> } >>> } >>> >>> if (cmsg == NULL) { >>> /* Error: IP_TTL not enabled or small buffer or I/O error */ >>> } >>> >>> The code below passes an array of file descriptors over a UNIX >>> domain socket using SCM_RIGHTS: >>> >>> struct msghdr msg = {0}; >>> struct cmsghdr *cmsg; >>> int myfds[NUM_FD]; /* Contains the file descriptors to pass */ >>> int *fdptr; >>> union { /* Ancillary data buffer, wrapped in a union >>> in order to ensure it is suitably aligned */ >>> char buf[CMSG_SPACE(sizeof myfds)]; >>> struct cmsghdr align; >>> } u; >>> >>> msg.msg_control = u.buf; >>> msg.msg_controllen = sizeof u.buf; >>> cmsg = CMSG_FIRSTHDR(&msg); >>> cmsg->cmsg_level = SOL_SOCKET; >>> cmsg->cmsg_type = SCM_RIGHTS; >>> cmsg->cmsg_len = CMSG_LEN(sizeof(int) * NUM_FD); >>> fdptr = (int *) CMSG_DATA(cmsg); /* Initialize the payload */ >>> memcpy(fdptr, myfds, NUM_FD * sizeof(int)); >>> ]] >>> >>> Cheers, >>> >>> Michael >>> >> > > >
On 21/04/2016 14:14, Rich Felker wrote: > On Mon, Mar 28, 2016 at 11:34:00AM -0300, Adhemerval Zanella wrote: >> POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen >> to be of size int and socklen_t respectively. However Linux defines it as >> both size_t and for 64-bit it requires some adjustments to make the >> functions standard compliance. >> >> This patch fixes it by creating a temporary header and zeroing the pad >> fields for 64-bits architecture where size of size_t exceeds the size of >> the int. >> >> Also the new recvmsg and sendmsg implementation is only added on libc, >> with libpthread only containing a compat symbol. > > Just a heads-up: this needs a bug report/patch to the Linux man-pages > project as well, since they're currently documenting the wrong types. > The documented types should probably be fixed to align with the > standard, with a note about them previously being wrong added to the > NOTES section. > > Rich > Based on previous messages I think Michael Kerrisk is already taking care of it. I think the remaining issue regarding this patch is 1. the alignment issue for cmsg_hdr and 2. the sendmsg cmsg padding. For 1. I do not think this should be a block issue, so I would like ask if someone have a impending reason for this patch. For 2. I already have prepared patch that I intend to send after this fix is upstream.
On 03/28/2016 10:34 AM, Adhemerval Zanella wrote: > POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen > to be of size int and socklen_t respectively. However Linux defines it as > both size_t and for 64-bit it requires some adjustments to make the > functions standard compliance. I expressed objections to the follow-up patch to this (tackling the same type inconsistency within cmsgbuf) and, on reflection, my objection applies as well (with somewhat less force) to this patch, so I'm going to explain myself once here. send/recv(m)msg are kernel primitives, and the fundamental basis of my objection is that I think the C library should always faithfully expose all the true kernel interfaces, *even if they are in some way wrong*. This conformance violation should be addressed by the kernel first, and only then should the C library follow suit. That means that neither this patch, nor the follow-up patch tackling cmsgbuf, should be applied at all. If either has already been applied, they should be backed out. (If the kernel developers refuse to fix a conformance violation, then that kernel has chosen to permanently deviate from the standard and, again, the C library should faithfully reflect that.) This objection has extra force under four circumstances all of which apply to send/recv(m)msg: * The problem is a minor deviation from a standard and is unlikely to affect non-contrived programs. * The kernel primitives in question are async-signal-safe; that is a difficult contract to uphold in user space -- the more work the C library does, the more likely it is to screw something up. * A completely transparent user-space workaround would need to allocate memory. In this case, it is my considered opinion that the proposed hard upper limit on the size of cmsgbuf is *far* more likely to break existing programs than leaving the status quo alone. * The kernel primitives in question are arbitrarily extensible, so it is not possible to guarantee that a user-space workaround cannot break future additions to the interface. Earlier, I said that I didn't like copying cmsgbuf because it wasn't possible to be sure that no cmsg opcodes cared (now or in the future) about the address of the buffer, and Adhemerval said (effectively) that such an opcode would not make sense. That's not true. Imagine, if you will, a cmsg that expects the ancillary buffer to be overlaid on a shared memory area, and rewrites the *non*-ancillary buffer to reflect the location of that memory area in the receiver. Contrived? Perhaps. Can we be sure no one will ever want to do something like that? No, we cannot. zw
On 07/06/2016 10:31, Zack Weinberg wrote: > On 03/28/2016 10:34 AM, Adhemerval Zanella wrote: >> POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen >> to be of size int and socklen_t respectively. However Linux defines it as >> both size_t and for 64-bit it requires some adjustments to make the >> functions standard compliance. > > I expressed objections to the follow-up patch to this (tackling the same > type inconsistency within cmsgbuf) and, on reflection, my objection > applies as well (with somewhat less force) to this patch, so I'm going > to explain myself once here. > > send/recv(m)msg are kernel primitives, and the fundamental basis of my > objection is that I think the C library should always faithfully expose > all the true kernel interfaces, *even if they are in some way wrong*. > This conformance violation should be addressed by the kernel first, and > only then should the C library follow suit. That means that neither > this patch, nor the follow-up patch tackling cmsgbuf, should be applied > at all. If either has already been applied, they should be backed out. I strongly disagree with this definition, the C library is still an abstraction on underlying kernel and GLIBC should and follows POSIX standards even when it deviates from the kernel primitives. The same idea of standard is what drove the various fixes on both math library conformance and various primitives (quick_exit is an example). And it is also why some from community view explicit exposing some Linux primitives (such as gettid) to be a controversial subject. But I do agree with that it *should* be fixed in kernel in the same way it has fixed deviation from standard: by providing a new syscall entry and by glibc using is directly. > > (If the kernel developers refuse to fix a conformance violation, then > that kernel has chosen to permanently deviate from the standard and, > again, the C library should faithfully reflect that.) > > This objection has extra force under four circumstances all of which > apply to send/recv(m)msg: > > * The problem is a minor deviation from a standard and is unlikely to > affect non-contrived programs. I agree it is a minor deviation, but it is still a deviation I see no compelling reason to just continue to deviate from standard just because it might not affect non-contrived programs. > > * The kernel primitives in question are async-signal-safe; that is a > difficult contract to uphold in user space -- the more work the C > library does, the more likely it is to screw something up. It is not the kernel that provides async-signal-safe, but rather the way the underlying libc wrapper is programmed. If we had an async-signal-safe malloc, we could allocate an arbitrary copy buffer. And current wrappers does not call any non async-signal-safe functions. > > * A completely transparent user-space workaround would need to allocate > memory. In this case, it is my considered opinion that the proposed > hard upper limit on the size of cmsgbuf is *far* more likely to break > existing programs than leaving the status quo alone. That's why I sent the second part of my fix as RFC and this part I think it is the most controversial nit which I am not sure if the possible breakage is worth. I am proposing to use a large buffer to avoid issues on mostly usercases, but indeed it might not be suffice for some rare cases. But again, such cases I presume it would be rare and somewhat easily fixable. > > * The kernel primitives in question are arbitrarily extensible, so it > is not possible to guarantee that a user-space workaround cannot > break future additions to the interface. > > Earlier, I said that I didn't like copying cmsgbuf because it wasn't > possible to be sure that no cmsg opcodes cared (now or in the future) > about the address of the buffer, and Adhemerval said (effectively) that > such an opcode would not make sense. That's not true. Imagine, if you > will, a cmsg that expects the ancillary buffer to be overlaid on a > shared memory area, and rewrites the *non*-ancillary buffer to reflect > the location of that memory area in the receiver. Again, I see to no problem in this scenario: the function prototype states a constant cmsghdr and it will not change its state. Even if the ancillary buffer might change, it is up to application to synchronize its access and call sendmsg in a flow where the data is a consistent state. I personally see that calling a syscall with a buffer in racy condition does not make sense. Contrived? Perhaps. > Can we be sure no one will ever want to do something like that? No, we > cannot. > > zw >
On Tue, Jun 7, 2016 at 10:21 AM, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: > On 07/06/2016 10:31, Zack Weinberg wrote: >> >> send/recv(m)msg are kernel primitives, and the fundamental basis of my >> objection is that I think the C library should always faithfully expose >> all the true kernel interfaces, *even if they are in some way wrong*. >> This conformance violation should be addressed by the kernel first, and >> only then should the C library follow suit. That means that neither >> this patch, nor the follow-up patch tackling cmsgbuf, should be applied >> at all. If either has already been applied, they should be backed out. > > I strongly disagree with this definition, the C library is still an > abstraction on underlying kernel and GLIBC should and follows POSIX > standards even when it deviates from the kernel primitives. The same > idea of standard is what drove the various fixes on both math library > conformance and various primitives (quick_exit is an example). You are going to have a very hard time persuading me to change my position, and this ain't gonna do it. This is circular logic. "We should follow POSIX because we should follow POSIX." I would consider a real (not made up for the purpose, and ideally, already existing) program that is broken by not having these types be as POSIX specifies to be a *valid argument* for changing the types, but even that might not be a *persuasive* argument for changing the types, especially since Florian has pointed out actual breakage from changing them. (Frankly, I think Florian's report of actual breakage should be the last word on the subject - back the patch out already, and let us never speak of this again.) What would persuade you to accept *my* position on this issue? (I'm cc:ing some of the usual standards-compliance gurus. I'm slightly more likely to be convinced by someone who is not advocating for their own patch.) > And it is also why some from community view explicit exposing some > Linux primitives (such as gettid) to be a controversial subject. As soon as I get some spare time (probably not in the 2.24 time frame) I am going to post a patch that makes glibc expose every single one of the Linux primitives that we don't already expose, because that's what I think we should do. But that's a tangent from this discussion. ... >> Earlier, I said that I didn't like copying cmsgbuf because it wasn't >> possible to be sure that no cmsg opcodes cared (now or in the future) >> about the address of the buffer, and Adhemerval said (effectively) that >> such an opcode would not make sense. That's not true. Imagine, if you >> will, a cmsg that expects the ancillary buffer to be overlaid on a >> shared memory area, and rewrites the *non*-ancillary buffer to reflect >> the location of that memory area in the receiver. > > Again, I see to no problem in this scenario: the function prototype states > a constant cmsghdr and it will not change its state. Even if the ancillary > buffer might change, it is up to application to synchronize its access > and call sendmsg in a flow where the data is a consistent state. I personally > see that calling a syscall with a buffer in racy condition does not make > sense. You clearly still don't get it. It's not about the buffer being in a racy condition. It's that the *address might be part of the message.* "Nobody should do that" is NOT a valid objection, because this is an arbitrarily extensible interface. Let me try again with another example. Imagine that there exists a SCM_CREATE_SHMEM ancillary message whose effect is to *convert that chunk of the ancillary buffer into a shared memory area*. The kernel will remap the data portion of the cmsg into the receiver, and supply the receiver with the address at which it was mapped. (You might be about to object that it doesn't make sense to embed the desired shared memory area in the cmsg, but, again, that is not a valid objection. This is an arbitrarily extensible interface. People can, will, and *have* done arbitrarily bizarre things with it.) Copying the ancillary buffer, *in and of itself*, would break this message. So would applying any small size limit to the length of an ancillary buffer. And come to think of it, this hypothetical cmsg would also justify the kernel's insisting to continue to use size_t for both cmsg_len and msg_controllen. zw
On 08/06/2016 17:15, Zack Weinberg wrote: > On Tue, Jun 7, 2016 at 10:21 AM, Adhemerval Zanella > <adhemerval.zanella@linaro.org> wrote: >> On 07/06/2016 10:31, Zack Weinberg wrote: >>> >>> send/recv(m)msg are kernel primitives, and the fundamental basis of my >>> objection is that I think the C library should always faithfully expose >>> all the true kernel interfaces, *even if they are in some way wrong*. >>> This conformance violation should be addressed by the kernel first, and >>> only then should the C library follow suit. That means that neither >>> this patch, nor the follow-up patch tackling cmsgbuf, should be applied >>> at all. If either has already been applied, they should be backed out. >> >> I strongly disagree with this definition, the C library is still an >> abstraction on underlying kernel and GLIBC should and follows POSIX >> standards even when it deviates from the kernel primitives. The same >> idea of standard is what drove the various fixes on both math library >> conformance and various primitives (quick_exit is an example). > > You are going to have a very hard time persuading me to change my > position, and this ain't gonna do it. This is circular logic. "We > should follow POSIX because we should follow POSIX." > > I would consider a real (not made up for the purpose, and ideally, > already existing) program that is broken by not having these types be > as POSIX specifies to be a *valid argument* for changing the types, > but even that might not be a *persuasive* argument for changing the > types, especially since Florian has pointed out actual breakage from > changing them. (Frankly, I think Florian's report of actual breakage > should be the last word on the subject - back the patch out already, > and let us never speak of this again.) > > What would persuade you to accept *my* position on this issue? I am stating we follow POSIX to very reason we follow other technical standard: to provide libc compatibility. And the breakage Florian has pointed (and I replied) is a very specific one that also require the interposing library to know a very deal of the interposed library. This kind of tooling is highly coupled with implementation and there are various hacks and slight breakages that minor GLIBC changes already incurred (for instance on libsanitizer, every TCB size change needs to be explicit take in account). And I do not see the tooling breakage as compelling reason to break interface changes and fixes. > > (I'm cc:ing some of the usual standards-compliance gurus. I'm > slightly more likely to be convinced by someone who is not advocating > for their own patch.) > >> And it is also why some from community view explicit exposing some >> Linux primitives (such as gettid) to be a controversial subject. > > As soon as I get some spare time (probably not in the 2.24 time frame) > I am going to post a patch that makes glibc expose every single one of > the Linux primitives that we don't already expose, because that's what > I think we should do. But that's a tangent from this discussion. This has been discussed before, so I would suggest you to first read Joseph suggested list [1]. The original thread [2] also show more discussion for each syscalls [2]. [1] https://sourceware.org/ml/libc-alpha/2015-11/msg00373.html [2] https://sourceware.org/ml/libc-alpha/2013-02/msg00030.html > > ... >>> Earlier, I said that I didn't like copying cmsgbuf because it wasn't >>> possible to be sure that no cmsg opcodes cared (now or in the future) >>> about the address of the buffer, and Adhemerval said (effectively) that >>> such an opcode would not make sense. That's not true. Imagine, if you >>> will, a cmsg that expects the ancillary buffer to be overlaid on a >>> shared memory area, and rewrites the *non*-ancillary buffer to reflect >>> the location of that memory area in the receiver. >> >> Again, I see to no problem in this scenario: the function prototype states >> a constant cmsghdr and it will not change its state. Even if the ancillary >> buffer might change, it is up to application to synchronize its access >> and call sendmsg in a flow where the data is a consistent state. I personally >> see that calling a syscall with a buffer in racy condition does not make >> sense. > > You clearly still don't get it. It's not about the buffer being in a > racy condition. It's that the *address might be part of the message.* > "Nobody should do that" is NOT a valid objection, because this is an > arbitrarily extensible interface. > > Let me try again with another example. Imagine that there exists a > SCM_CREATE_SHMEM ancillary message whose effect is to *convert that > chunk of the ancillary buffer into a shared memory area*. The kernel > will remap the data portion of the cmsg into the receiver, and supply > the receiver with the address at which it was mapped. (You might be > about to object that it doesn't make sense to embed the desired shared > memory area in the cmsg, but, again, that is not a valid objection. > This is an arbitrarily extensible interface. People can, will, and > *have* done arbitrarily bizarre things with it.) Copying the > ancillary buffer, *in and of itself*, would break this message. So > would applying any small size limit to the length of an ancillary > buffer. And come to think of it, this hypothetical cmsg would also > justify the kernel's insisting to continue to use size_t for both > cmsg_len and msg_controllen. This very interface does not make sense: the ancillary message will be required to be remmaped anyway in syscall transition to kernel space. So in the end, if you try to remap a 1GB buffer in this hypothetical syscall, kernel in the end will need to first to copy the 1GB message to kernel space and then remap the original pointer. I highly double kernel will ever supports such syscall or any syscall that you might pass a buffer that is suppose to be volatile.
On 06/08/2016 04:57 PM, Adhemerval Zanella wrote: > On 08/06/2016 17:15, Zack Weinberg wrote: >> What would persuade you to accept *my* position on this issue? > > I am stating we follow POSIX to very reason we follow other technical > standard: to provide libc compatibility. There are some places where POSIX and Linux disagree. In as much as we possibly can we should try to standardize on POSIX. Each decision should be done on a case-by-base basis, and I think in this case of recvmsg/sendmsg it is possible to comply with POSIX without serious problems. I've only seen rare examples of theoretical breakage, and the reported dlsym issue simply needs fixing in the dynamic loader. I support the use of a standard, and working to try and comply with the standard, and also to work with the standard to fix it as we go. The mess that was futex return codes before Michael, Torvald and others started documenting and refining things should show how out of control some linux syscalls can get. If we really want better network APIs then we should just be creating them ourselves, implementing them in Linux, and exporting them via glibc wrappers/headers. We should make APIs that are *better* than recvmsg/sendmsg. Once we get a good API we can propose that to POSIX. Rather than the other way around, which is a half-hearted attempt to be POSIX compatible, but with enough changes to provided portability issues and documentation problems. I will end by giving a counter example... In POSIX section 2.9.7 it states that 39 filesystem operations need to be atomic with respect to eachother given threads in a process. This is huge performance killer, particularly the write and fstat atomicity. As of linux 3.14 the two threads calling write at exactly the same time (on the same fd) will actually get two distinct offsets, which is good, you get interleaved writes. The rest of the functions will never, and should not be, guaranteed atomic (wrt to threads in the same process), and glibc on linux should never follow POSIX in this case. To support POSIX we would need userspace IO locks and purposely serialize these operations. Each case for conformance should be considered on it's own merit. Regarding adding all linux syscalls, please see: https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers and the notes that Adhemerval provided.
On Wed, Jun 8, 2016 at 4:57 PM, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: > On 08/06/2016 17:15, Zack Weinberg wrote: >> On Tue, Jun 7, 2016 at 10:21 AM, Adhemerval Zanella >> <adhemerval.zanella@linaro.org> wrote: >>> On 07/06/2016 10:31, Zack Weinberg wrote: >>>> >>>> send/recv(m)msg are kernel primitives, and the fundamental basis of my >>>> objection is that I think the C library should always faithfully expose >>>> all the true kernel interfaces, *even if they are in some way wrong*. ... >> You are going to have a very hard time persuading me to change my >> position, and this ain't gonna do it. This is circular logic. "We >> should follow POSIX because we should follow POSIX." >> >> I would consider a real (not made up for the purpose, and ideally, >> already existing) program that is broken by not having these types be >> as POSIX specifies to be a *valid argument* for changing the types, >> but even that might not be a *persuasive* argument for changing the >> types[.] ... >> What would persuade you to accept *my* position on this issue? > > I am stating we follow POSIX to very reason we follow other technical > standard: to provide libc compatibility. This is not a response to my argument. I said that I consider faithfully exposing all the true kernel interfaces to be MORE IMPORTANT than following POSIX. I also told you what I would consider to be a valid (but not necessarily persuasive) argument against my position: exhibit a real program that is broken by this conformance deviation. You respond by reiterating that following POSIX is important in the abstract. Sure, but I still think that faithfully exposing all the true kernel interfaces is *more* important. You give a reason why it's important in the abstract: to provide compatibility with other systems. Sure, but for that to have any persuasive force at all, you need to exhibit a real program that cares. And I would still like to know what could persuade *you* to agree with *me*; maybe then I could actually present that. > And the breakage Florian has pointed (and I replied) is a very > specific one that also require the interposing library to know a > very deal of the interposed library. This kind of tooling is highly > coupled with implementation and there are various hacks and slight > breakages that minor GLIBC changes already incurred (for instance > on libsanitizer, every TCB size change needs to be explicit take > in account). I'm sorry, I have not been able to make any sense whatsoever out of this paragraph. > And I do not see the tooling breakage as compelling reason to break > interface changes and fixes. If you're trying to say that you think the breakage Florian cited is too unusual to worry about, I cannot agree with that. We're bending over backward to keep old Emacs binaries working that depended on glibc-specific details of the malloc implementation -- interposition of network APIs is commonplace by comparison. (I also suspect that this *can't* be easily papered over by messing with the semantics of dlsym() -- see upcoming reply to Carlos.) >> You clearly still don't get it. It's not about the buffer being in a >> racy condition. It's that the *address might be part of the message.* >> "Nobody should do that" is NOT a valid objection, because this is an >> arbitrarily extensible interface. >> >> Let me try again with another example. [...] > This very interface does not make sense What part of '"Nobody should do that" is NOT a valid objection' was unclear? zw
On Wed, Jun 8, 2016 at 11:18 PM, Carlos O'Donell <carlos@redhat.com> wrote: > On 06/08/2016 04:57 PM, Adhemerval Zanella wrote: >> On 08/06/2016 17:15, Zack Weinberg wrote: >>> What would persuade you to accept *my* position on this issue? >> >> I am stating we follow POSIX to very reason we follow other technical >> standard: to provide libc compatibility. > > There are some places where POSIX and Linux disagree. > In as much as we possibly can we should try to standardize on POSIX. Right, so as I have been saying all along, I don't agree with this; I think it is *more important* to faithfully reflect the semantics of each supported kernel. If that means that glibc-on-Linux has different semantics than glibc-on-FreeBSD (for instance), well, that was probably unavoidable anyway. The reason for this is that POSIX is very slow, and the C library should not stand in the way of *improvements* to the kernel interface. The case we're arguing about is relatively minor, but maybe someone has an actual need for size_t-sized ancillary data buffers - I don't think we should be judging whether that is a valid use case. (A much more significant issue here is the ridiculous delays in adding things like gettid() and getrandom().) > Each decision should be done on a case-by-base basis, and I think in > this case of recvmsg/sendmsg it is possible to comply with POSIX without > serious problems. I've only seen rare examples of theoretical breakage, > and the reported dlsym issue simply needs fixing in the dynamic loader. I do not think the reported dlsym issue is a simple matter to fix. I haven't sat down and worked it out, but I am fairly sure it is possible, for most symbols that glibc exposes multiple versions of, to construct a pair of interposition modules which are black-box indistinguishable except that one of them needs version A and the other needs version B -- which is to say, whatever dlsym("name", RTLD_NEXT) does, it's going to be wrong for one of them. Which is why there is dlvsym()... but changing the semantics of dlsym() strikes me as asking for much greater breakage. zw
On Wed, 8 Jun 2016, Carlos O'Donell wrote: > Regarding adding all linux syscalls, please see: > https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers > and the notes that Adhemerval provided. Note that we have never managed to reach consensus on syscall wrappers. However, I now disagree with the idea of a separate libinux-syscalls.so library, or of only adding to libc.so those syscalls considered appropriate for the OS-independent GNU API. I think that all non-obsolete syscalls that can meaningfully be used outside of glibc in a glibc-using program, even those extremely OS-specific or only likely to be of use to a handful of programs on an OS, should have wrappers added to glibc, and that we should not need to decide when adding them whether they are appropriate for the OS-independent GNU API (although if there is consensus for putting them in the OS-independent GNU API at the time they are added, they should go there at that point - other functions might be added to the OS-independent GNU API later). We *do* still need to decide for such wrappers what the userspace types are to use with them, what the prototype is, what header declares the functions, and how errno and thread cancellation are handled. And we *do* need documentation in the glibc manual for all such wrappers, and testcases in the glibc testsuite (though some such tests may not be able to do more than test that a call to the function compiles and links).
On 09/06/2016 10:25, Zack Weinberg wrote: > On Wed, Jun 8, 2016 at 4:57 PM, Adhemerval Zanella > <adhemerval.zanella@linaro.org> wrote: >> On 08/06/2016 17:15, Zack Weinberg wrote: >>> On Tue, Jun 7, 2016 at 10:21 AM, Adhemerval Zanella >>> <adhemerval.zanella@linaro.org> wrote: >>>> On 07/06/2016 10:31, Zack Weinberg wrote: >>>>> >>>>> send/recv(m)msg are kernel primitives, and the fundamental basis of my >>>>> objection is that I think the C library should always faithfully expose >>>>> all the true kernel interfaces, *even if they are in some way wrong*. > ... >>> You are going to have a very hard time persuading me to change my >>> position, and this ain't gonna do it. This is circular logic. "We >>> should follow POSIX because we should follow POSIX." >>> >>> I would consider a real (not made up for the purpose, and ideally, >>> already existing) program that is broken by not having these types be >>> as POSIX specifies to be a *valid argument* for changing the types, >>> but even that might not be a *persuasive* argument for changing the >>> types[.] > ... >>> What would persuade you to accept *my* position on this issue? >> >> I am stating we follow POSIX to very reason we follow other technical >> standard: to provide libc compatibility. > > This is not a response to my argument. > > I said that I consider faithfully exposing all the true kernel > interfaces to be MORE IMPORTANT than following POSIX. I also told you > what I would consider to be a valid (but not necessarily persuasive) > argument against my position: exhibit a real program that is broken by > this conformance deviation. > > You respond by reiterating that following POSIX is important in the > abstract. Sure, but I still think that faithfully exposing all the > true kernel interfaces is *more* important. You give a reason why > it's important in the abstract: to provide compatibility with other > systems. Sure, but for that to have any persuasive force at all, you > need to exhibit a real program that cares. > > And I would still like to know what could persuade *you* to agree with > *me*; maybe then I could actually present that. Like Carlos has pointed out, my idea is not blindly follow POSIX in any statement, but rather discuss if each standard definition and interface make sense to implement or not in glibc. Now, I see that not only conformance, but also compatibility is a goal GLIBC is aim to provide. I do not see the case that I should provide a real program, mostly because real programs either will fix the system difference by themselves. Now related this specific issue: BZ#16919 was opened in 2014 and there was some discussion in the way it should be fixed in GLIBC. Now, what you are advocating is we should close it as WONTFIX, keep the documentation that GLIBC does not follow the standard and state that we won't fix it in GLIBC. I personally do not oppose for this course of action, but we need *consensus*. What I do not agree is to GLIBC also blindly follow kernel interfaces, even when they differ from POSIX or any other standard GLIBC aims to follow. But I do agree that libsanitizer breakage it is something we should consider, even if relies on implementation details not exposed by the API. That why I talked with Carlos en Joseph at IRC (and my mistake here, I should have brought it on maillist as well). And my understanding it is still desirable to push this fix. > >> And the breakage Florian has pointed (and I replied) is a very >> specific one that also require the interposing library to know a >> very deal of the interposed library. This kind of tooling is highly >> coupled with implementation and there are various hacks and slight >> breakages that minor GLIBC changes already incurred (for instance >> on libsanitizer, every TCB size change needs to be explicit take >> in account). > > I'm sorry, I have not been able to make any sense whatsoever out of > this paragraph. I mean that the way libsanitizer couple with GLIBC requires to know internal specific details that is not part of the ABI/exported interfaces. And also it is possible to hook on libc provided symbols with some sanitizer changes, so stating this change breaks libsanitizer is not a strong reason to block this fix IMHO. > >> And I do not see the tooling breakage as compelling reason to break >> interface changes and fixes. > > If you're trying to say that you think the breakage Florian cited is > too unusual to worry about, I cannot agree with that. We're bending > over backward to keep old Emacs binaries working that depended on > glibc-specific details of the malloc implementation -- interposition > of network APIs is commonplace by comparison. > > (I also suspect that this *can't* be easily papered over by messing > with the semantics of dlsym() -- see upcoming reply to Carlos.) Because EMACS uses a defined ABI/interface GLIBC aimed to exposed. The Florian specific one is another bug [1]. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=14932 > >>> You clearly still don't get it. It's not about the buffer being in a >>> racy condition. It's that the *address might be part of the message.* >>> "Nobody should do that" is NOT a valid objection, because this is an >>> arbitrarily extensible interface. >>> >>> Let me try again with another example. > [...] >> This very interface does not make sense > > What part of '"Nobody should do that" is NOT a valid objection' was > unclear? It is not 'nobody should do that', it is 'this interface you described do not make sense'.
On 06/09/2016 09:35 AM, Zack Weinberg wrote: > On Wed, Jun 8, 2016 at 11:18 PM, Carlos O'Donell <carlos@redhat.com> wrote: >> On 06/08/2016 04:57 PM, Adhemerval Zanella wrote: >>> On 08/06/2016 17:15, Zack Weinberg wrote: >>>> What would persuade you to accept *my* position on this issue? >>> >>> I am stating we follow POSIX to very reason we follow other technical >>> standard: to provide libc compatibility. >> >> There are some places where POSIX and Linux disagree. >> In as much as we possibly can we should try to standardize on POSIX. > > Right, so as I have been saying all along, I don't agree with this; I > think it is *more important* to faithfully reflect the semantics of > each supported kernel. If that means that glibc-on-Linux has > different semantics than glibc-on-FreeBSD (for instance), well, that > was probably unavoidable anyway. That's fine so long as you don't pretend to be POSIX-compatible. > The reason for this is that POSIX is very slow, and the C library > should not stand in the way of *improvements* to the kernel interface. It doesn't stand in the way. We have lots of interfaces that are non-POSIX and we aren't touching them. > The case we're arguing about is relatively minor, but maybe someone > has an actual need for size_t-sized ancillary data buffers - I don't > think we should be judging whether that is a valid use case. The problem I have with this line of argument is that a standards-conforming interface name was taken and changed. If you really wanted size_t sized ancillary data buffers we should have just declared a different type and new functions to handle that. It's that easy. > (A much more significant issue here is the ridiculous delays in adding > things like gettid() and getrandom().) There are no delays in adding gettid or getrandom, there are only the lack of skilled people willing to do the work at level of quality required of a core library implementation. >> Each decision should be done on a case-by-base basis, and I think in >> this case of recvmsg/sendmsg it is possible to comply with POSIX without >> serious problems. I've only seen rare examples of theoretical breakage, >> and the reported dlsym issue simply needs fixing in the dynamic loader. > > I do not think the reported dlsym issue is a simple matter to fix. I > haven't sat down and worked it out, but I am fairly sure it is > possible, for most symbols that glibc exposes multiple versions of, to > construct a pair of interposition modules which are black-box > indistinguishable except that one of them needs version A and the > other needs version B -- which is to say, whatever dlsym("name", > RTLD_NEXT) does, it's going to be wrong for one of them. Which is why > there is dlvsym()... but changing the semantics of dlsym() strikes me > as asking for much greater breakage. The entire dlsym/dlvsym discussion is a red-herring. At some point you'll need to interpose yourself in front of a versioned interface and you'll need two things to do it properly: * A versioned symbol of your own. * Use of dlvsym(). Anything that doesn't work with this setup is a bug we need to fix. Fixing dlsym() is a required fix because the semantics are just plain wrong, and it happened to fix the present use case, but eventually it doesn't work.
On Fri, 10 Jun 2016, Carlos O'Donell wrote: > > (A much more significant issue here is the ridiculous delays in adding > > things like gettid() and getrandom().) > > There are no delays in adding gettid or getrandom, there are only the > lack of skilled people willing to do the work at level of quality required > of a core library implementation. For gettid I think the actual issue is difficulty in establishing consensus in the absence of unanimity. That's caused issues for all of: gettid / pthread_gettid_np, explicit_bzero, strlcpy / strlcat, Linux syscall wrappers in general especially where not appropriate for the OS-independent GNU API. (I think all of those are appropriate for inclusion in glibc.)
On 06/10/2016 02:19 PM, Joseph Myers wrote: > On Fri, 10 Jun 2016, Carlos O'Donell wrote: > >>> (A much more significant issue here is the ridiculous delays in adding >>> things like gettid() and getrandom().) >> >> There are no delays in adding gettid or getrandom, there are only the >> lack of skilled people willing to do the work at level of quality required >> of a core library implementation. > > For gettid I think the actual issue is difficulty in establishing > consensus in the absence of unanimity. That's caused issues for all of: > gettid / pthread_gettid_np, explicit_bzero, strlcpy / strlcat, Linux > syscall wrappers in general especially where not appropriate for the > OS-independent GNU API. (I think all of those are appropriate for > inclusion in glibc.) The OS-independent GNU API is in my mind an issue of documentation, describing which APIs are Linux-specific and which are not. I would be happy to see gettid implemented as a wrapper if someone would step up to document exactly how it behaves and where it is valid to use the resulting return value and in what APIs. That I think is where everyone balks at the work.
On Fri, 10 Jun 2016, Carlos O'Donell wrote: > > For gettid I think the actual issue is difficulty in establishing > > consensus in the absence of unanimity. That's caused issues for all of: > > gettid / pthread_gettid_np, explicit_bzero, strlcpy / strlcat, Linux > > syscall wrappers in general especially where not appropriate for the > > OS-independent GNU API. (I think all of those are appropriate for > > inclusion in glibc.) > > The OS-independent GNU API is in my mind an issue of documentation, > describing which APIs are Linux-specific and which are not. There were objections from Roland and Mike at least to adding Linux-specific APIs to libc.so. Now, I disagree with the proposal for libinux-syscalls.so: * Because of thread cancellation (something that needs considering for each syscall wrapper, along with errno and the choice of types), libinux-syscalls.so would be closely tied to a particular libc version, so you can't readily keep around copies from multiple libc versions. * Thus, removing any interfaces from it to add them to libc.so would be problematic, because glibc would need to install multiple versions of libinux-syscalls.so. * We cannot readily tell when adding an interface whether it would remain Linux-specific or be adopted by other OSes in future, and so whether it belongs in the OS-independent GNU API or not. So we cannot tell when adding an interface which library it belongs in. So we'd be likely repeatedly to add interfaces to libinux-syscalls.so and then add them to libc.so as well, accumulating compat duplicates in libinux-syscalls.so. But it's not clear there's consensus on adding syscall wrappers to libc.so, and there certainly isn't unanimity. > I would be happy to see gettid implemented as a wrapper if someone > would step up to document exactly how it behaves and where it is valid > to use the resulting return value and in what APIs. That I think is > where everyone balks at the work. I think the answer is that the return value may be used with syscalls that take tids (which are legimitate interfaces for glibc users to use, in most cases), some of which may have matching glibc interfaces and some of which may not. While we should describe what wrappers do in the glibc manual, ultimately for Linux-specific syscall wrappers the kernel's behavior is more authoritative than the manual.
On 06/10/2016 04:17 PM, Joseph Myers wrote: > I think the answer is that the return value may be used with syscalls that > take tids (which are legimitate interfaces for glibc users to use, in most > cases), some of which may have matching glibc interfaces and some of which > may not. While we should describe what wrappers do in the glibc manual, > ultimately for Linux-specific syscall wrappers the kernel's behavior is > more authoritative than the manual. The authoritative source in this case is the linux man pages project IMO.
diff --git a/conform/data/sys/socket.h-data b/conform/data/sys/socket.h-data index 442d4d2..3a6cf7c 100644 --- a/conform/data/sys/socket.h-data +++ b/conform/data/sys/socket.h-data @@ -22,10 +22,9 @@ type {struct msghdr} element {struct msghdr} {void*} msg_name element {struct msghdr} socklen_t msg_namelen element {struct msghdr} {struct iovec*} msg_iov -// Bug 16919: wrong type for msg_iovlen and msg_controllen members. -xfail-element {struct msghdr} int msg_iovlen +element {struct msghdr} int msg_iovlen element {struct msghdr} {void*} msg_control -xfail-element {struct msghdr} socklen_t msg_controllen +element {struct msghdr} socklen_t msg_controllen element {struct msghdr} int msg_flags type {struct iovec} @@ -35,8 +34,7 @@ element {struct iovec} size_t iov_len type {struct cmsghdr} -// Bug 16919: wrong type for cmsg_len member. -xfail-element {struct cmsghdr} socklen_t cmsg_len +element {struct cmsghdr} socklen_t cmsg_len element {struct cmsghdr} int cmsg_level element {struct cmsghdr} int cmsg_type diff --git a/nptl/Makefile b/nptl/Makefile index dc3ccab..4240928 100644 --- a/nptl/Makefile +++ b/nptl/Makefile @@ -109,12 +109,13 @@ libpthread-routines = nptl-init vars events version pt-interp \ lll_timedlock_wait lll_timedwait_tid \ pt-fork pt-vfork \ ptw-write ptw-read ptw-close ptw-fcntl ptw-accept \ - ptw-connect ptw-recv ptw-recvfrom ptw-recvmsg ptw-send \ - ptw-sendmsg ptw-sendto ptw-fsync ptw-lseek ptw-llseek \ + ptw-connect ptw-recv ptw-recvfrom ptw-send \ + ptw-sendto ptw-fsync ptw-lseek ptw-llseek \ ptw-msync ptw-nanosleep ptw-open ptw-open64 ptw-pause \ ptw-pread ptw-pread64 ptw-pwrite ptw-pwrite64 \ ptw-tcdrain ptw-wait ptw-waitpid ptw-msgrcv ptw-msgsnd \ ptw-sigwait ptw-sigsuspend \ + ptw-oldrecvmsg ptw-oldsendmsg \ pt-raise pt-system \ flockfile ftrylockfile funlockfile \ sigaction \ @@ -204,10 +205,10 @@ CFLAGS-recv.c = -fexceptions -fasynchronous-unwind-tables CFLAGS-send.c = -fexceptions -fasynchronous-unwind-tables CFLAGS-accept.c = -fexceptions -fasynchronous-unwind-tables CFLAGS-sendto.c = -fexceptions -fasynchronous-unwind-tables -CFLAGS-sendmsg.c = -fexceptions -fasynchronous-unwind-tables CFLAGS-connect.c = -fexceptions -fasynchronous-unwind-tables -CFLAGS-recvmsg.c = -fexceptions -fasynchronous-unwind-tables CFLAGS-recvfrom.c = -fexceptions -fasynchronous-unwind-tables +CFLAGS-oldrecvmsg.c = -fexceptions -fasynchronous-unwind-tables +CFLAGS-oldrecvfrom.c = -fexceptions -fasynchronous-unwind-tables CFLAGS-pt-system.c = -fexceptions diff --git a/sysdeps/unix/sysv/linux/Makefile b/sysdeps/unix/sysv/linux/Makefile index 9999600..af8e13a 100644 --- a/sysdeps/unix/sysv/linux/Makefile +++ b/sysdeps/unix/sysv/linux/Makefile @@ -124,7 +124,11 @@ ifeq ($(subdir),socket) sysdep_headers += net/if_ppp.h net/ppp-comp.h \ net/ppp_defs.h net/if_arp.h net/route.h net/ethernet.h \ net/if_slip.h net/if_packet.h net/if_shaper.h -sysdep_routines += cmsg_nxthdr +sysdep_routines += cmsg_nxthdr oldrecvmsg oldsendmsg +CFLAGS-recvmsg.c = -fexceptions -fasynchronous-unwind-tables +CFLAGS-sendmsg.c = -fexceptions -fasynchronous-unwind-tables +CFLAGS-oldrecvmsg.c = -fexceptions -fasynchronous-unwind-tables +CFLAGS-oldsendmsg.c = -fexceptions -fasynchronous-unwind-tables endif ifeq ($(subdir),sunrpc) diff --git a/sysdeps/unix/sysv/linux/aarch64/Versions b/sysdeps/unix/sysv/linux/aarch64/Versions index 9bd87fe..ae3742c 100644 --- a/sysdeps/unix/sysv/linux/aarch64/Versions +++ b/sysdeps/unix/sysv/linux/aarch64/Versions @@ -5,6 +5,10 @@ ld { } } libc { + GLIBC_2.24 { + recvmsg; sendmsg; + } + GLIBC_PRIVATE { __vdso_clock_gettime; __vdso_clock_getres; diff --git a/sysdeps/unix/sysv/linux/aarch64/libc.abilist b/sysdeps/unix/sysv/linux/aarch64/libc.abilist index 5799239..c3f2346 100644 --- a/sysdeps/unix/sysv/linux/aarch64/libc.abilist +++ b/sysdeps/unix/sysv/linux/aarch64/libc.abilist @@ -2087,3 +2087,6 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F diff --git a/sysdeps/unix/sysv/linux/alpha/Versions b/sysdeps/unix/sysv/linux/alpha/Versions index 29b82f9..31abb22 100644 --- a/sysdeps/unix/sysv/linux/alpha/Versions +++ b/sysdeps/unix/sysv/linux/alpha/Versions @@ -85,6 +85,9 @@ libc { #errlist-compat 140 _sys_errlist; sys_errlist; _sys_nerr; sys_nerr; } + GLIBC_2.24 { + recvmsg; sendmsg; + } GLIBC_PRIVATE { __libc_alpha_cache_shape; } diff --git a/sysdeps/unix/sysv/linux/alpha/libc.abilist b/sysdeps/unix/sysv/linux/alpha/libc.abilist index 0fa4ee9..7822242 100644 --- a/sysdeps/unix/sysv/linux/alpha/libc.abilist +++ b/sysdeps/unix/sysv/linux/alpha/libc.abilist @@ -1998,6 +1998,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/arm/Versions b/sysdeps/unix/sysv/linux/arm/Versions index 5ff2225..7e5ba53 100644 --- a/sysdeps/unix/sysv/linux/arm/Versions +++ b/sysdeps/unix/sysv/linux/arm/Versions @@ -7,6 +7,9 @@ libc { GLIBC_2.11 { fallocate64; } + GLIBC_2.24 { + recvmsg; sendmsg; + } GLIBC_PRIVATE { # A copy of sigaction lives in libpthread, and needs these. __default_sa_restorer; __default_rt_sa_restorer; diff --git a/sysdeps/unix/sysv/linux/arm/libc.abilist b/sysdeps/unix/sysv/linux/arm/libc.abilist index db9fa35..2b2f9f0 100644 --- a/sysdeps/unix/sysv/linux/arm/libc.abilist +++ b/sysdeps/unix/sysv/linux/arm/libc.abilist @@ -88,6 +88,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.4 GLIBC_2.4 A GLIBC_2.4 _Exit F GLIBC_2.4 _IO_2_1_stderr_ D 0xa0 diff --git a/sysdeps/unix/sysv/linux/bits/socket.h b/sysdeps/unix/sysv/linux/bits/socket.h index 0581c79..9c284a4 100644 --- a/sysdeps/unix/sysv/linux/bits/socket.h +++ b/sysdeps/unix/sysv/linux/bits/socket.h @@ -27,6 +27,8 @@ #include <stddef.h> #include <sys/types.h> +#include <endian.h> +#include <bits/wordsize.h> /* Type for length arguments in socket calls. */ #ifndef __socklen_t_defined @@ -231,13 +233,32 @@ struct msghdr socklen_t msg_namelen; /* Length of address data. */ struct iovec *msg_iov; /* Vector of data to send/receive into. */ - size_t msg_iovlen; /* Number of elements in the vector. */ +#if __WORDSIZE == 64 +# if __BYTE_ORDER == __BIG_ENDIAN + int __glibc_reserved1; /* Pad to adjust Linux size to POSIX defined + size for msg_iovlen. */ + int msg_iovlen; /* Number of elements in the vector. */ +# else + int msg_iovlen; + int __glibc_reserved1; +# endif +#else + int msg_iovlen; +#endif void *msg_control; /* Ancillary data (eg BSD filedesc passing). */ - size_t msg_controllen; /* Ancillary data buffer length. - !! The type should be socklen_t but the - definition of the kernel is incompatible - with this. */ +#if __WORDSIZE == 64 +# if __BYTE_ORDER == __BIG_ENDIAN + int __glibc_reserved2; /* Pad to adjust Linux size to POSIX defined + size for msg_controllen. */ + socklen_t msg_controllen; /* Ancillary data buffer length. */ +# else + socklen_t msg_controllen; + int __glibc_reserved2; +# endif +#else + socklen_t msg_controllen; +#endif int msg_flags; /* Flags on received message. */ }; @@ -245,11 +266,15 @@ struct msghdr /* Structure used for storage of ancillary data object information. */ struct cmsghdr { - size_t cmsg_len; /* Length of data in cmsg_data plus length - of cmsghdr structure. - !! The type should be socklen_t but the - definition of the kernel is incompatible - with this. */ +#if __BYTE_ORDER == __BIG_ENDIAN + int __glibc_reserved1; /* Pad toadjust Linux size to POSIX defined + size for cmsg_len. */ + socklen_t cmsg_len; /* Length of data in cmsg_data plus length + of cmsghdr structure. */ +#else + socklen_t cmsg_len; + int __glibc_reserved1; +#endif int cmsg_level; /* Originating protocol. */ int cmsg_type; /* Protocol specific type. */ #if (!defined __STRICT_ANSI__ && __GNUC__ >= 2) || __STDC_VERSION__ >= 199901L diff --git a/sysdeps/unix/sysv/linux/check_native.c b/sysdeps/unix/sysv/linux/check_native.c index b3cbbe3..a8e447e 100644 --- a/sysdeps/unix/sysv/linux/check_native.c +++ b/sysdeps/unix/sysv/linux/check_native.c @@ -111,10 +111,13 @@ __check_native (uint32_t a1_index, int *a1_native, { struct msghdr msg = { - (void *) &nladdr, sizeof (nladdr), - &iov, 1, - NULL, 0, - 0 + .msg_name = (void *) &nladdr, + .msg_namelen = sizeof (nladdr), + .msg_iov = &iov, + .msg_iovlen = 1, + .msg_control = NULL, + .msg_controllen = 0, + .msg_flags = 0 }; ssize_t read_len = TEMP_FAILURE_RETRY (__recvmsg (fd, &msg, 0)); diff --git a/sysdeps/unix/sysv/linux/check_pf.c b/sysdeps/unix/sysv/linux/check_pf.c index d55953a..89e9031 100644 --- a/sysdeps/unix/sysv/linux/check_pf.c +++ b/sysdeps/unix/sysv/linux/check_pf.c @@ -158,10 +158,13 @@ make_request (int fd, pid_t pid) { struct msghdr msg = { - (void *) &nladdr, sizeof (nladdr), - &iov, 1, - NULL, 0, - 0 + .msg_name = (void *) &nladdr, + .msg_namelen = sizeof (nladdr), + .msg_iov = &iov, + .msg_iovlen = 1, + .msg_control = NULL, + .msg_controllen = 0, + .msg_flags = 0 }; ssize_t read_len = TEMP_FAILURE_RETRY (__recvmsg (fd, &msg, 0)); diff --git a/sysdeps/unix/sysv/linux/hppa/Versions b/sysdeps/unix/sysv/linux/hppa/Versions index b5098b2..895696e 100644 --- a/sysdeps/unix/sysv/linux/hppa/Versions +++ b/sysdeps/unix/sysv/linux/hppa/Versions @@ -35,4 +35,7 @@ libc { GLIBC_2.19 { fanotify_mark; } + GLIBC_2.24 { + recvms; sendmsg; + } } diff --git a/sysdeps/unix/sysv/linux/hppa/libc.abilist b/sysdeps/unix/sysv/linux/hppa/libc.abilist index 1d30644..84e8431 100644 --- a/sysdeps/unix/sysv/linux/hppa/libc.abilist +++ b/sysdeps/unix/sysv/linux/hppa/libc.abilist @@ -1852,6 +1852,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/i386/Versions b/sysdeps/unix/sysv/linux/i386/Versions index f3544ac..55d1277 100644 --- a/sysdeps/unix/sysv/linux/i386/Versions +++ b/sysdeps/unix/sysv/linux/i386/Versions @@ -45,6 +45,9 @@ libc { # f* fallocate64; } + GLIBC_2.24 { + recvms; sendmsg; + } GLIBC_PRIVATE { __modify_ldt; } diff --git a/sysdeps/unix/sysv/linux/i386/libc.abilist b/sysdeps/unix/sysv/linux/i386/libc.abilist index 8f3502d..0229cd6 100644 --- a/sysdeps/unix/sysv/linux/i386/libc.abilist +++ b/sysdeps/unix/sysv/linux/i386/libc.abilist @@ -2010,6 +2010,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/ia64/Versions b/sysdeps/unix/sysv/linux/ia64/Versions index b38d6ef..116f4e8 100644 --- a/sysdeps/unix/sysv/linux/ia64/Versions +++ b/sysdeps/unix/sysv/linux/ia64/Versions @@ -22,6 +22,9 @@ libc { GLIBC_2.2.6 { getunwind; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } libpthread { GLIBC_2.3.3 { diff --git a/sysdeps/unix/sysv/linux/ia64/libc.abilist b/sysdeps/unix/sysv/linux/ia64/libc.abilist index 921ec55..f5739b4 100644 --- a/sysdeps/unix/sysv/linux/ia64/libc.abilist +++ b/sysdeps/unix/sysv/linux/ia64/libc.abilist @@ -1874,6 +1874,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/ifaddrs.c b/sysdeps/unix/sysv/linux/ifaddrs.c index ca38d1a..54f1124 100644 --- a/sysdeps/unix/sysv/linux/ifaddrs.c +++ b/sysdeps/unix/sysv/linux/ifaddrs.c @@ -161,10 +161,13 @@ __netlink_request (struct netlink_handle *h, int type) { struct msghdr msg = { - (void *) &nladdr, sizeof (nladdr), - &iov, 1, - NULL, 0, - 0 + .msg_name = (void *) &nladdr, + .msg_namelen = sizeof (nladdr), + .msg_iov = &iov, + .msg_iovlen = 1, + .msg_control = NULL, + .msg_controllen = 0, + .msg_flags = 0 }; read_len = TEMP_FAILURE_RETRY (__recvmsg (h->fd, &msg, 0)); diff --git a/sysdeps/unix/sysv/linux/m68k/Versions b/sysdeps/unix/sysv/linux/m68k/Versions index 7ecc96e..eceb89a 100644 --- a/sysdeps/unix/sysv/linux/m68k/Versions +++ b/sysdeps/unix/sysv/linux/m68k/Versions @@ -40,6 +40,9 @@ libc { GLIBC_2.12 { __m68k_read_tp; } + GLIBC_2.24 { + recvms; sendmsg; + } GLIBC_PRIVATE { __vdso_atomic_cmpxchg_32; __vdso_atomic_barrier; } diff --git a/sysdeps/unix/sysv/linux/m68k/coldfire/libc.abilist b/sysdeps/unix/sysv/linux/m68k/coldfire/libc.abilist index 019095b..3a498cb 100644 --- a/sysdeps/unix/sysv/linux/m68k/coldfire/libc.abilist +++ b/sysdeps/unix/sysv/linux/m68k/coldfire/libc.abilist @@ -89,6 +89,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.4 GLIBC_2.4 A GLIBC_2.4 _Exit F GLIBC_2.4 _IO_2_1_stderr_ D 0x98 diff --git a/sysdeps/unix/sysv/linux/m68k/m680x0/libc.abilist b/sysdeps/unix/sysv/linux/m68k/m680x0/libc.abilist index a999a48..948b050 100644 --- a/sysdeps/unix/sysv/linux/m68k/m680x0/libc.abilist +++ b/sysdeps/unix/sysv/linux/m68k/m680x0/libc.abilist @@ -1966,6 +1966,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/microblaze/Versions b/sysdeps/unix/sysv/linux/microblaze/Versions index aa48a3c..c2f4505 100644 --- a/sysdeps/unix/sysv/linux/microblaze/Versions +++ b/sysdeps/unix/sysv/linux/microblaze/Versions @@ -2,4 +2,7 @@ libc { GLIBC_2.18 { fallocate64; } + GLIBC_2.24 { + recvms; sendmsg; + } } diff --git a/sysdeps/unix/sysv/linux/microblaze/libc.abilist b/sysdeps/unix/sysv/linux/microblaze/libc.abilist index 0a08bba..d7ba0be 100644 --- a/sysdeps/unix/sysv/linux/microblaze/libc.abilist +++ b/sysdeps/unix/sysv/linux/microblaze/libc.abilist @@ -2087,3 +2087,6 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F diff --git a/sysdeps/unix/sysv/linux/mips/mips32/Versions b/sysdeps/unix/sysv/linux/mips/mips32/Versions index 9621fb5..c4f38d8 100644 --- a/sysdeps/unix/sysv/linux/mips/mips32/Versions +++ b/sysdeps/unix/sysv/linux/mips/mips32/Versions @@ -3,4 +3,7 @@ libc { getrlimit64; setrlimit64; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } diff --git a/sysdeps/unix/sysv/linux/mips/mips32/fpu/libc.abilist b/sysdeps/unix/sysv/linux/mips/mips32/fpu/libc.abilist index 2ab9e94..87bb49b 100644 --- a/sysdeps/unix/sysv/linux/mips/mips32/fpu/libc.abilist +++ b/sysdeps/unix/sysv/linux/mips/mips32/fpu/libc.abilist @@ -1941,6 +1941,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/mips/mips32/nofpu/libc.abilist b/sysdeps/unix/sysv/linux/mips/mips32/nofpu/libc.abilist index b9b4b74..1a415ab 100644 --- a/sysdeps/unix/sysv/linux/mips/mips32/nofpu/libc.abilist +++ b/sysdeps/unix/sysv/linux/mips/mips32/nofpu/libc.abilist @@ -1939,6 +1939,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/mips/mips64/n32/Versions b/sysdeps/unix/sysv/linux/mips/mips64/n32/Versions index 9621fb5..c4f38d8 100644 --- a/sysdeps/unix/sysv/linux/mips/mips64/n32/Versions +++ b/sysdeps/unix/sysv/linux/mips/mips64/n32/Versions @@ -3,4 +3,7 @@ libc { getrlimit64; setrlimit64; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } diff --git a/sysdeps/unix/sysv/linux/mips/mips64/n32/libc.abilist b/sysdeps/unix/sysv/linux/mips/mips64/n32/libc.abilist index 14e1236..949761b 100644 --- a/sysdeps/unix/sysv/linux/mips/mips64/n32/libc.abilist +++ b/sysdeps/unix/sysv/linux/mips/mips64/n32/libc.abilist @@ -1937,6 +1937,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/mips/mips64/n64/Versions b/sysdeps/unix/sysv/linux/mips/mips64/n64/Versions new file mode 100644 index 0000000..517d79a --- /dev/null +++ b/sysdeps/unix/sysv/linux/mips/mips64/n64/Versions @@ -0,0 +1,5 @@ +libc { + GLIBC_2.24 { + recvmsg; sendmsg; + } +} diff --git a/sysdeps/unix/sysv/linux/mips/mips64/n64/libc.abilist b/sysdeps/unix/sysv/linux/mips/mips64/n64/libc.abilist index 53e0c9a..6722f90 100644 --- a/sysdeps/unix/sysv/linux/mips/mips64/n64/libc.abilist +++ b/sysdeps/unix/sysv/linux/mips/mips64/n64/libc.abilist @@ -1932,6 +1932,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/nios2/Versions b/sysdeps/unix/sysv/linux/nios2/Versions index e42c85f..93458f5 100644 --- a/sysdeps/unix/sysv/linux/nios2/Versions +++ b/sysdeps/unix/sysv/linux/nios2/Versions @@ -3,4 +3,7 @@ libc { _flush_cache; cacheflush; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } diff --git a/sysdeps/unix/sysv/linux/nios2/libc.abilist b/sysdeps/unix/sysv/linux/nios2/libc.abilist index dff1ee9..75ef1ab 100644 --- a/sysdeps/unix/sysv/linux/nios2/libc.abilist +++ b/sysdeps/unix/sysv/linux/nios2/libc.abilist @@ -2128,3 +2128,6 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F diff --git a/sysdeps/unix/sysv/linux/oldrecvmsg.c b/sysdeps/unix/sysv/linux/oldrecvmsg.c new file mode 100644 index 0000000..01c596e --- /dev/null +++ b/sysdeps/unix/sysv/linux/oldrecvmsg.c @@ -0,0 +1,40 @@ +/* Compatibility version of recvmsg. + Copyright (C) 2016 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, see + <http://www.gnu.org/licenses/>. */ + +#include <sys/socket.h> +#include <sysdep-cancel.h> +#include <socketcall.h> +#include <shlib-compat.h> + +/* Both libc.so and libpthread.so provides sendmsg, so we need to + provide the compat symbol for both libraries. */ +#if SHLIB_COMPAT (MODULE_NAME, GLIBC_2_0, GLIBC_2_24) + +/* We can use the same struct layout for old symbol version since + size is the same. */ +ssize_t +__old_recvmsg (int fd, struct msghdr *msg, int flags) +{ +# ifdef __ASSUME_RECVMSG_SYSCALL + return SYSCALL_CANCEL (recvmsg, fd, msg, flags); +# else + return SOCKETCALL_CANCEL (recvmsg, fd, msg, flags); +# endif +} +compat_symbol (MODULE_NAME, __old_recvmsg, recvmsg, GLIBC_2_0); +#endif diff --git a/sysdeps/unix/sysv/linux/oldsendmsg.c b/sysdeps/unix/sysv/linux/oldsendmsg.c new file mode 100644 index 0000000..a96790a --- /dev/null +++ b/sysdeps/unix/sysv/linux/oldsendmsg.c @@ -0,0 +1,40 @@ +/* Compatibility implementation of sendmsg. + Copyright (C) 2016 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, see + <http://www.gnu.org/licenses/>. */ + +#include <sys/socket.h> +#include <sysdep-cancel.h> +#include <socketcall.h> +#include <shlib-compat.h> + +/* Both libc.so and libpthread.so provides sendmsg, so we need to + provide the compat symbol for both libraries. */ +#if SHLIB_COMPAT (MODULE_NAME, GLIBC_2_0, GLIBC_2_24) + +/* We can use the same struct layout for old symbol version since + size is the same. */ +ssize_t +__old_sendmsg (int fd, const struct msghdr *msg, int flags) +{ +# ifdef __ASSUME_SENDMSG_SYSCALL + return SYSCALL_CANCEL (sendmsg, fd, msg, flags); +# else + return SOCKETCALL_CANCEL (sendmsg, fd, msg, flags); +# endif +} +compat_symbol (MODULE_NAME, __old_sendmsg, sendmsg, GLIBC_2_0); +#endif diff --git a/sysdeps/unix/sysv/linux/powerpc/Versions b/sysdeps/unix/sysv/linux/powerpc/Versions index 8ebeea1..ab0db57 100644 --- a/sysdeps/unix/sysv/linux/powerpc/Versions +++ b/sysdeps/unix/sysv/linux/powerpc/Versions @@ -5,6 +5,9 @@ ld { } } libc { + GLIBC_2.24 { + recvmsg; sendmsg; + } GLIBC_PRIVATE { __vdso_get_tbfreq; __vdso_clock_gettime; diff --git a/sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist b/sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist index 6861846..5a0890e 100644 --- a/sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist +++ b/sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist @@ -1970,6 +1970,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/libc.abilist b/sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/libc.abilist index fd611aa..adbe736 100644 --- a/sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/libc.abilist +++ b/sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/libc.abilist @@ -1975,6 +1975,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/powerpc/powerpc64/Versions b/sysdeps/unix/sysv/linux/powerpc/powerpc64/Versions index a8e88b8..53e5527 100644 --- a/sysdeps/unix/sysv/linux/powerpc/powerpc64/Versions +++ b/sysdeps/unix/sysv/linux/powerpc/powerpc64/Versions @@ -22,6 +22,9 @@ libc { GLIBC_2.17 { __ppc_get_timebase_freq; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } librt { diff --git a/sysdeps/unix/sysv/linux/powerpc/powerpc64/libc-le.abilist b/sysdeps/unix/sysv/linux/powerpc/powerpc64/libc-le.abilist index a97bd43..7839b5a 100644 --- a/sysdeps/unix/sysv/linux/powerpc/powerpc64/libc-le.abilist +++ b/sysdeps/unix/sysv/linux/powerpc/powerpc64/libc-le.abilist @@ -2175,3 +2175,6 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F diff --git a/sysdeps/unix/sysv/linux/powerpc/powerpc64/libc.abilist b/sysdeps/unix/sysv/linux/powerpc/powerpc64/libc.abilist index 00772cb..20d5a19 100644 --- a/sysdeps/unix/sysv/linux/powerpc/powerpc64/libc.abilist +++ b/sysdeps/unix/sysv/linux/powerpc/powerpc64/libc.abilist @@ -89,6 +89,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 _Exit F GLIBC_2.3 _IO_2_1_stderr_ D 0xe0 diff --git a/sysdeps/unix/sysv/linux/recvmsg.c b/sysdeps/unix/sysv/linux/recvmsg.c index 4caf22e..25a3193 100644 --- a/sysdeps/unix/sysv/linux/recvmsg.c +++ b/sysdeps/unix/sysv/linux/recvmsg.c @@ -15,23 +15,43 @@ License along with the GNU C Library; if not, see <http://www.gnu.org/licenses/>. */ -#include <errno.h> -#include <signal.h> #include <sys/socket.h> - #include <sysdep-cancel.h> #include <socketcall.h> -#include <kernel-features.h> -#include <sys/syscall.h> +#include <shlib-compat.h> ssize_t __libc_recvmsg (int fd, struct msghdr *msg, int flags) { + ssize_t ret; + + /* POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen + to be int and socklen_t respectively. However Linux defines it as + both size_t. So for 64-bit it requires some adjustments by copying to + temporary header and zeroing the pad fields. */ +#if __WORDSIZE == 64 + struct msghdr hdr, *orig = msg; + if (msg != NULL) + { + hdr = *msg; + hdr.__glibc_reserved1 = 0; + hdr.__glibc_reserved2 = 0; + msg = &hdr; + } +#endif + #ifdef __ASSUME_RECVMSG_SYSCALL - return SYSCALL_CANCEL (recvmsg, fd, msg, flags); + ret = SYSCALL_CANCEL (recvmsg, fd, msg, flags); #else - return SOCKETCALL_CANCEL (recvmsg, fd, msg, flags); + ret = SOCKETCALL_CANCEL (recvmsg, fd, msg, flags); #endif + +#if __WORDSIZE == 64 + if (orig != NULL) + *orig = hdr; +#endif + + return ret; } -weak_alias (__libc_recvmsg, recvmsg) weak_alias (__libc_recvmsg, __recvmsg) +versioned_symbol (libc, __libc_recvmsg, recvmsg, GLIBC_2_24); diff --git a/sysdeps/unix/sysv/linux/s390/s390-32/Versions b/sysdeps/unix/sysv/linux/s390/s390-32/Versions index 1c120e8..afcc3fe 100644 --- a/sysdeps/unix/sysv/linux/s390/s390-32/Versions +++ b/sysdeps/unix/sysv/linux/s390/s390-32/Versions @@ -49,6 +49,9 @@ libc { GLIBC_2.11 { fallocate64; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } libutil { diff --git a/sysdeps/unix/sysv/linux/s390/s390-32/libc.abilist b/sysdeps/unix/sysv/linux/s390/s390-32/libc.abilist index 05cb85e..03983df 100644 --- a/sysdeps/unix/sysv/linux/s390/s390-32/libc.abilist +++ b/sysdeps/unix/sysv/linux/s390/s390-32/libc.abilist @@ -1970,6 +1970,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/s390/s390-64/Versions b/sysdeps/unix/sysv/linux/s390/s390-64/Versions index 3f4d960..fde5aee 100644 --- a/sysdeps/unix/sysv/linux/s390/s390-64/Versions +++ b/sysdeps/unix/sysv/linux/s390/s390-64/Versions @@ -4,6 +4,9 @@ libc { __register_frame; __register_frame_table; __deregister_frame; __frame_state_for; __register_frame_info_table; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } librt { diff --git a/sysdeps/unix/sysv/linux/s390/s390-64/libc.abilist b/sysdeps/unix/sysv/linux/s390/s390-64/libc.abilist index 1af185f..5892fcd 100644 --- a/sysdeps/unix/sysv/linux/s390/s390-64/libc.abilist +++ b/sysdeps/unix/sysv/linux/s390/s390-64/libc.abilist @@ -1871,6 +1871,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/sendmsg.c b/sysdeps/unix/sysv/linux/sendmsg.c index 5b2741a..a5ef238 100644 --- a/sysdeps/unix/sysv/linux/sendmsg.c +++ b/sysdeps/unix/sysv/linux/sendmsg.c @@ -15,23 +15,34 @@ License along with the GNU C Library; if not, see <http://www.gnu.org/licenses/>. */ -#include <errno.h> -#include <signal.h> #include <sys/socket.h> - #include <sysdep-cancel.h> #include <socketcall.h> -#include <kernel-features.h> -#include <sys/syscall.h> +#include <shlib-compat.h> ssize_t __libc_sendmsg (int fd, const struct msghdr *msg, int flags) { + /* POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen + to be int and socklen_t respectively. However Linux defines it as + both size_t. So for 64-bit it requires some adjustments by copying to + temporary header and zeroing the pad fields. */ +#if __WORDSIZE == 64 + struct msghdr hdr; + if (msg != NULL) + { + hdr = *msg; + hdr.__glibc_reserved1 = 0; + hdr.__glibc_reserved2 = 0; + msg = &hdr; + } +#endif + #ifdef __ASSUME_SENDMSG_SYSCALL return SYSCALL_CANCEL (sendmsg, fd, msg, flags); #else return SOCKETCALL_CANCEL (sendmsg, fd, msg, flags); #endif } -weak_alias (__libc_sendmsg, sendmsg) weak_alias (__libc_sendmsg, __sendmsg) +versioned_symbol (libc, __libc_sendmsg, sendmsg, GLIBC_2_24); diff --git a/sysdeps/unix/sysv/linux/sh/Versions b/sysdeps/unix/sysv/linux/sh/Versions index e0938c4..ae5a00e 100644 --- a/sysdeps/unix/sysv/linux/sh/Versions +++ b/sysdeps/unix/sysv/linux/sh/Versions @@ -30,4 +30,7 @@ libc { GLIBC_2.16 { fanotify_mark; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } diff --git a/sysdeps/unix/sysv/linux/sh/libc.abilist b/sysdeps/unix/sysv/linux/sh/libc.abilist index e128692..a2d85e6 100644 --- a/sysdeps/unix/sysv/linux/sh/libc.abilist +++ b/sysdeps/unix/sysv/linux/sh/libc.abilist @@ -1856,6 +1856,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/sparc/Versions b/sysdeps/unix/sysv/linux/sparc/Versions index 4dc1cd7..adbdec5 100644 --- a/sysdeps/unix/sysv/linux/sparc/Versions +++ b/sysdeps/unix/sysv/linux/sparc/Versions @@ -29,6 +29,9 @@ libc { __getshmlba; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } libpthread { diff --git a/sysdeps/unix/sysv/linux/sparc/sparc32/libc.abilist b/sysdeps/unix/sysv/linux/sparc/sparc32/libc.abilist index eb14113..c51e790 100644 --- a/sysdeps/unix/sysv/linux/sparc/sparc32/libc.abilist +++ b/sysdeps/unix/sysv/linux/sparc/sparc32/libc.abilist @@ -1962,6 +1962,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/sparc/sparc64/Versions b/sysdeps/unix/sysv/linux/sparc/sparc64/Versions index fbea1bb..f950070 100644 --- a/sysdeps/unix/sysv/linux/sparc/sparc64/Versions +++ b/sysdeps/unix/sysv/linux/sparc/sparc64/Versions @@ -8,6 +8,9 @@ libc { # w* wordexp; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } librt { diff --git a/sysdeps/unix/sysv/linux/sparc/sparc64/libc.abilist b/sysdeps/unix/sysv/linux/sparc/sparc64/libc.abilist index 91b97ef..015a2f1 100644 --- a/sysdeps/unix/sysv/linux/sparc/sparc64/libc.abilist +++ b/sysdeps/unix/sysv/linux/sparc/sparc64/libc.abilist @@ -1900,6 +1900,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/tile/Versions b/sysdeps/unix/sysv/linux/tile/Versions index 13da68f..a68e181 100644 --- a/sysdeps/unix/sysv/linux/tile/Versions +++ b/sysdeps/unix/sysv/linux/tile/Versions @@ -11,6 +11,9 @@ libc { fallocate64; set_dataplane; } + GLIBC_2.24 { + recvmsg; sendmsg; + } GLIBC_PRIVATE { __syscall_error; __vdso_clock_gettime; diff --git a/sysdeps/unix/sysv/linux/tile/tilegx/tilegx32/libc.abilist b/sysdeps/unix/sysv/linux/tile/tilegx/tilegx32/libc.abilist index ffcc4a0..cd48be1 100644 --- a/sysdeps/unix/sysv/linux/tile/tilegx/tilegx32/libc.abilist +++ b/sysdeps/unix/sysv/linux/tile/tilegx/tilegx32/libc.abilist @@ -2094,3 +2094,6 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F diff --git a/sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/Versions b/sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/Versions new file mode 100644 index 0000000..517d79a --- /dev/null +++ b/sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/Versions @@ -0,0 +1,5 @@ +libc { + GLIBC_2.24 { + recvmsg; sendmsg; + } +} diff --git a/sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/libc.abilist b/sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/libc.abilist index a66e8ec..1e160bd 100644 --- a/sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/libc.abilist +++ b/sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/libc.abilist @@ -2094,3 +2094,6 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F diff --git a/sysdeps/unix/sysv/linux/tile/tilepro/libc.abilist b/sysdeps/unix/sysv/linux/tile/tilepro/libc.abilist index ffcc4a0..cd48be1 100644 --- a/sysdeps/unix/sysv/linux/tile/tilepro/libc.abilist +++ b/sysdeps/unix/sysv/linux/tile/tilepro/libc.abilist @@ -2094,3 +2094,6 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F diff --git a/sysdeps/unix/sysv/linux/x86_64/64/Versions b/sysdeps/unix/sysv/linux/x86_64/64/Versions new file mode 100644 index 0000000..517d79a --- /dev/null +++ b/sysdeps/unix/sysv/linux/x86_64/64/Versions @@ -0,0 +1,5 @@ +libc { + GLIBC_2.24 { + recvmsg; sendmsg; + } +} diff --git a/sysdeps/unix/sysv/linux/x86_64/64/libc.abilist b/sysdeps/unix/sysv/linux/x86_64/64/libc.abilist index c6e3cd4..175339e 100644 --- a/sysdeps/unix/sysv/linux/x86_64/64/libc.abilist +++ b/sysdeps/unix/sysv/linux/x86_64/64/libc.abilist @@ -1851,6 +1851,9 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F GLIBC_2.3 GLIBC_2.3 A GLIBC_2.3 __ctype_b_loc F GLIBC_2.3 __ctype_tolower_loc F diff --git a/sysdeps/unix/sysv/linux/x86_64/Versions b/sysdeps/unix/sysv/linux/x86_64/Versions index 2a7ed28..bbef7e0 100644 --- a/sysdeps/unix/sysv/linux/x86_64/Versions +++ b/sysdeps/unix/sysv/linux/x86_64/Versions @@ -6,6 +6,9 @@ libc { modify_ldt; } + GLIBC_2.24 { + recvmsg; sendmsg; + } } librt { diff --git a/sysdeps/unix/sysv/linux/x86_64/x32/libc.abilist b/sysdeps/unix/sysv/linux/x86_64/x32/libc.abilist index 04dc8e4..4f52e2e 100644 --- a/sysdeps/unix/sysv/linux/x86_64/x32/libc.abilist +++ b/sysdeps/unix/sysv/linux/x86_64/x32/libc.abilist @@ -2094,3 +2094,6 @@ GLIBC_2.23 fts64_close F GLIBC_2.23 fts64_open F GLIBC_2.23 fts64_read F GLIBC_2.23 fts64_set F +GLIBC_2.24 GLIBC_2.24 A +GLIBC_2.24 recvmsg F +GLIBC_2.24 sendmsg F