From owner-freebsd-threads@freebsd.org Sun Jan 24 05:06:52 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 804FBA8ED00 for ; Sun, 24 Jan 2016 05:06:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 63F941561 for ; Sun, 24 Jan 2016 05:06:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 60E18A8ECFF; Sun, 24 Jan 2016 05:06:52 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46750A8ECFA; Sun, 24 Jan 2016 05:06:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFF4D1560; Sun, 24 Jan 2016 05:06:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0O56ZtF015586 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 24 Jan 2016 07:06:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0O56ZtF015586 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0O56Yr5015548; Sun, 24 Jan 2016 07:06:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Jan 2016 07:06:34 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: Bruce Evans , threads@freebsd.org, Jilles Tjoelker , net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160124050634.GS3942@kib.kiev.ua> References: <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Yia77v5a8fyVHJSl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 05:06:52 -0000 --Yia77v5a8fyVHJSl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Overall, the patch starts taking the committable shape, I only have small notes about it. On Fri, Jan 22, 2016 at 11:15:18AM +0200, Boris Astardzhiev wrote: > be>None of the above. Plain recvmsg() returns ssize_t and its len arg has > be>type size_t. That is excessively typedefed and excessively large with > be>64-bit ssize_t, but it is silly for the multiple-message variant to use > be>smaller types. > be> > be>Otherwise, all the integer types should be int. >=20 > It seems logical. I'll convert the ret easily to ssize_t and the vector > length > to size_t. Now it differs from the Linux prototype but I guess it's okay. Lets try. I do think that the change is for good. >=20 > be>The errno method (and not checking ret at all) is best if for syscalls > that > be>return -1 for a non-error. It is not needed here. >=20 > Fixing it. >=20 > kb> I do not see any sense in making the functions with signature or > semantic > kb> different from Linux version. Right now, the goal of including the > patch > kb> is compatibility. >=20 > Regarding recvmmsg() - > I tried to implement MSG_WAITFORONE and the timeout stuff using > pselect(2) due to the timespec structure. I could have used ppoll and > I'm not sure which of these two is more appropriate or maybe there's > another approach? Now it has timeout just as in the Linux prototype. > Comments are welcomed. You defer to ppoll() and pselect() due to the struct timespec type of the argument, am I right ? > > See patch. > diff --git a/lib/libc/include/namespace.h b/lib/libc/include/namespace.h > index 739d7b1..c95829e 100644 > --- a/lib/libc/include/namespace.h > +++ b/lib/libc/include/namespace.h > @@ -208,6 +208,7 @@ > #define readv _readv > #define recvfrom _recvfrom > #define recvmsg _recvmsg > +#define recvmmsg _recvmmsg > #define select _select > #define sem_close _sem_close > #define sem_destroy _sem_destroy > @@ -220,6 +221,7 @@ > #define sem_unlink _sem_unlink > #define sem_wait _sem_wait > #define sendmsg _sendmsg > +#define sendmmsg _sendmmsg > #define sendto _sendto > #define setsockopt _setsockopt > /*#define sigaction _sigaction*/ > diff --git a/lib/libc/include/un-namespace.h b/lib/libc/include/un-namesp= ace.h > index f31fa7a..0233348 100644 > --- a/lib/libc/include/un-namespace.h > +++ b/lib/libc/include/un-namespace.h > @@ -189,6 +189,7 @@ > #undef readv > #undef recvfrom > #undef recvmsg > +#undef recvmmsg > #undef select > #undef sem_close > #undef sem_destroy > @@ -201,6 +202,7 @@ > #undef sem_unlink > #undef sem_wait > #undef sendmsg > +#undef sendmmsg > #undef sendto > #undef setsockopt > #undef sigaction > diff --git a/lib/libc/sys/Makefile.inc b/lib/libc/sys/Makefile.inc > index e4fe1b2..5f8b699 100644 > --- a/lib/libc/sys/Makefile.inc > +++ b/lib/libc/sys/Makefile.inc > @@ -28,6 +28,8 @@ SRCS+=3D futimens.c utimensat.c > NOASM+=3D futimens.o utimensat.o > PSEUDO+=3D _futimens.o _utimensat.o > =20 > +SRCS+=3D recvmmsg.c sendmmsg.c > + BTW, just noted, I think the functions should live in libc/gen. > INTERPOSED =3D \ > accept \ > accept4 \ > diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map > index 7b3257c..dc2ed0e 100644 > --- a/lib/libc/sys/Symbol.map > +++ b/lib/libc/sys/Symbol.map > @@ -399,6 +399,8 @@ FBSD_1.4 { > utimensat; > numa_setaffinity; > numa_getaffinity; > + sendmmsg; > + recvmmsg; > }; > =20 > FBSDprivate_1.0 { > diff --git a/lib/libc/sys/recv.2 b/lib/libc/sys/recv.2 > index 326e7ff..fd2b2a1 100644 > --- a/lib/libc/sys/recv.2 > +++ b/lib/libc/sys/recv.2 > @@ -34,8 +34,9 @@ > .Sh NAME > .Nm recv , > .Nm recvfrom , > -.Nm recvmsg > -.Nd receive a message from a socket > +.Nm recvmsg , > +.Nm recvmmsg > +.Nd receive message(s) from a socket > .Sh LIBRARY > .Lb libc > .Sh SYNOPSIS > @@ -47,11 +48,15 @@ > .Fn recvfrom "int s" "void *buf" "size_t len" "int flags" "struct sockad= dr * restrict from" "socklen_t * restrict fromlen" > .Ft ssize_t > .Fn recvmsg "int s" "struct msghdr *msg" "int flags" > +.Ft ssize_t > +.Fn recvmmsg "int s" "struct mmsghdr *msgvec" "size_t vlen" "int flags" = "const struct timespec *timeout" > .Sh DESCRIPTION > The > .Fn recvfrom > and > .Fn recvmsg > +and > +.Fn recvmmsg > system calls > are used to receive messages from a socket, > and may be used to receive data on a socket whether or not > @@ -84,8 +89,30 @@ null pointer passed as its > .Fa from > argument. > .Pp > -All three routines return the length of the message on successful > -completion. > +The > +.Fn recvmmsg > +function is used to receive multiple > +messages at a call. > +Their number > +is supplied by > +.Fa vlen . > +The messages are placed in the > +.Fa msgvec > +vector after reception. > +The size of each received message is placed in the > +.Fa msg_len > +field of each element of the vector. > +If > +.Fa timeout > +is NULL the call will normally block. Otherwise it will wait for data > +for the specified amount of time. If the timeout expires and there is > +no data received a value of 0 is returned. pselect(2) is used for the > +implementation of the timeout mechanism. Put each sentence on new line. > +.Pp > +The first three routines return the length of the message on successful > +completion whereas > +.Fn recvmmsg > +returns the number of received messages. > If a message is too long to fit in the supplied buffer, > excess bytes may be discarded depending on the type of socket > the message is received from (see > @@ -100,7 +127,9 @@ in which case the value > .Va errno > is set to > .Er EAGAIN . > -The receive calls normally return any data available, > +The receive calls except > +.Fn recvmmsg > +normally return any data available, > up to the requested amount, > rather than waiting for receipt of the full amount requested; > this behavior is affected by the socket-level options > @@ -127,6 +156,9 @@ one or more of the values: > .It Dv MSG_WAITALL Ta wait for full request or error > .It Dv MSG_DONTWAIT Ta do not block > .It Dv MSG_CMSG_CLOEXEC Ta set received fds close-on-exec > +.It Dv MSG_WAITFORONE Ta do not block after receiving the first message > +(relevant only for > +.Fn recvmmsg ) > .El > .Pp > The > @@ -158,6 +190,11 @@ is set to > This flag is not available in strict > .Tn ANSI > or C99 compilation mode. > +The > +.Dv MSG_WAITFORONE > +flag sets MSG_DONTWAIT after the first message has been received. This f= lag > +is only relevant for > +.Fn recvmmsg . > .Pp > The > .Fn recvmsg > @@ -290,9 +327,34 @@ control data were discarded due to lack of space in = the buffer > for ancillary data. > .Dv MSG_OOB > is returned to indicate that expedited or out-of-band data were received. > +.Pp > +The > +.Fn recvmmsg > +system call uses the > +.Fa mmsghdr > +structure. Its form is as follows, as defined in > +.In sys/socket.h : > +.Bd -literal > +struct mmsghdr { > + struct msghdr msg_hdr; /* message header */ > + unsigned int msg_len; /* message length */ > +}; > +.Ed > +.Pp > +For > +.Fa msg_hdr > +see above. On data reception the > +.Fa msg_len > +field is updated to the length of the received message. On > +data transmission it is updated to the number of > +characters sent. > .Sh RETURN VALUES > -These calls return the number of bytes received, or -1 > -if an error occurred. > +These calls except > +.Fn recvmmsg > +return the number of bytes received. > +.Fn recvmmsg > +returns the number of messages received. > +A value of -1 is returned if an error occurred. > .Sh ERRORS > The calls fail if: > .Bl -tag -width Er > diff --git a/lib/libc/sys/recvmmsg.c b/lib/libc/sys/recvmmsg.c > new file mode 100644 > index 0000000..19a937b > --- /dev/null > +++ b/lib/libc/sys/recvmmsg.c > @@ -0,0 +1,96 @@ > +/* > + * Copyright (c) 2016 Boris Astardzhiev, Smartcom-Bulgaria AD > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice(s), this list of conditions and the following disclaimer as > + * the first lines of this file unmodified other than the possible > + * addition of one or more copyright notices. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice(s), this list of conditions and the following disclaimer in > + * the documentation and/or other materials provided with the > + * distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ``AS IS'' AND ANY > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR > + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, > + * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE > + * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, > + * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > +__FBSDID("$FreeBSD$"); > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include "libc_private.h" > + > +#define CMTR(s, timeout) \ > + do { \ > + fd_set fds; \ > + int res; \ > + \ > + FD_ZERO(&fds); \ > + FD_SET((s), &fds); \ > + res =3D __sys_pselect((s)+1, &fds, NULL, NULL, (timeout), NULL);\ Why do you need the syscall there ? Cancellation before any data was received is fine, since cancellation would not result in data loss. > + if (res =3D=3D -1 || res =3D=3D 0) \ > + return (res); \ > + if (!FD_ISSET((s), &fds)) \ > + return (-1); \ > + } while (0); > + > +ssize_t > +recvmmsg(int s, struct mmsghdr *msgvec, size_t vlen, int flags, > + const struct timespec *timeout) > +{ > + size_t i, rcvd; > + ssize_t ret; > + > + if (timeout !=3D NULL) > + CMTR(s, timeout); The CMTR define is only used once. I do not see why not inline it, and get rid of the staircase of backslashes. > + > + ret =3D __sys_recvmsg(s, &msgvec[0].msg_hdr, flags); > + if (ret =3D=3D -1) > + return (ret); > + > + /* Check initially for the presence of MSG_WAITFORONE. > + * Turn on MSG_DONTWAIT if set. */ > + if (flags & MSG_WAITFORONE) { > + flags |=3D MSG_DONTWAIT; > + /* The kernel doesn't need to know about this flag. */ > + flags &=3D ~MSG_WAITFORONE; > + } > + > + rcvd =3D 1; > + for (i =3D rcvd; i < vlen; i++) { i =3D rcvd =3D 1; ... i++, rcvd++ ? > + ret =3D __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > + if (ret =3D=3D -1) { > + if (rcvd !=3D 0) { > + /* We've received messages. Let caller know. */ > + return (rcvd); > + } > + return (ret); > + } > + > + /* Save received bytes */ > + msgvec[i].msg_len =3D ret; > + rcvd++; > + } > + > + return (rcvd); > +} > + > +#undef CMTR > diff --git a/lib/libc/sys/send.2 b/lib/libc/sys/send.2 > index 8fa2c64..33fa58d 100644 > --- a/lib/libc/sys/send.2 > +++ b/lib/libc/sys/send.2 > @@ -34,8 +34,9 @@ > .Sh NAME > .Nm send , > .Nm sendto , > -.Nm sendmsg > -.Nd send a message from a socket > +.Nm sendmsg , > +.Nm sendmmsg > +.Nd send message(s) from a socket > .Sh LIBRARY > .Lb libc > .Sh SYNOPSIS > @@ -47,6 +48,8 @@ > .Fn sendto "int s" "const void *msg" "size_t len" "int flags" "const str= uct sockaddr *to" "socklen_t tolen" > .Ft ssize_t > .Fn sendmsg "int s" "const struct msghdr *msg" "int flags" > +.Ft ssize_t > +.Fn sendmmsg "int s" "struct mmsghdr *msgvec" "size_t vlen" "int flags" > .Sh DESCRIPTION > The > .Fn send > @@ -55,8 +58,10 @@ and > .Fn sendto > and > .Fn sendmsg > +and > +.Fn sendmmsg > system calls > -are used to transmit a message to another socket. > +are used to transmit one or multiple messages (with the latter call) to = another socket. > The > .Fn send > function > @@ -66,6 +71,8 @@ state, while > .Fn sendto > and > .Fn sendmsg > +and > +.Fn sendmmsg > may be used at any time. > .Pp > The address of the target is given by > @@ -81,6 +88,18 @@ underlying protocol, the error > is returned, and > the message is not transmitted. > .Pp > +The > +.Fn sendmmsg > +function sends multiple messages at a call. > +They are given by the > +.Fa msgvec > +vector along with > +.Fa vlen > +specifying its size. The number of > +characters sent per each message is placed in the > +.Fa msg_len > +field of each element of the vector after transmission. > +.Pp > No indication of failure to deliver is implicit in a > .Fn send . > Locally detected errors are indicated by a return value of -1. > @@ -138,10 +157,16 @@ See > .Xr recv 2 > for a description of the > .Fa msghdr > +structure and the > +.Fa mmsghdr > structure. > .Sh RETURN VALUES > -The call returns the number of characters sent, or -1 > -if an error occurred. > +All calls except > +.Fn sendmmsg > +return the number of characters sent. The > +.Fn sendmmsg > +call returns the number of messages sent. > +If an error occurred a value of -1 is returned. > .Sh ERRORS > The > .Fn send > @@ -149,6 +174,8 @@ function and > .Fn sendto > and > .Fn sendmsg > +and > +.Fn sendmmsg > system calls > fail if: > .Bl -tag -width Er > diff --git a/lib/libc/sys/sendmmsg.c b/lib/libc/sys/sendmmsg.c > new file mode 100644 > index 0000000..cef35a3 > --- /dev/null > +++ b/lib/libc/sys/sendmmsg.c > @@ -0,0 +1,63 @@ > +/* > + * Copyright (c) 2016 Boris Astardzhiev, Smartcom-Bulgaria AD > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice(s), this list of conditions and the following disclaimer as > + * the first lines of this file unmodified other than the possible > + * addition of one or more copyright notices. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice(s), this list of conditions and the following disclaimer in > + * the documentation and/or other materials provided with the > + * distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ``AS IS'' AND ANY > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR > + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, > + * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE > + * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, > + * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > +__FBSDID("$FreeBSD$"); > + > +#include > +#include > +#include > +#include > +#include > +#include "libc_private.h" > + > +ssize_t > +sendmmsg(int s, struct mmsghdr *msgvec, size_t vlen, int flags) > +{ > + size_t i, sent; > + ssize_t ret; > + > + sent =3D 0; > + for (i =3D 0; i < vlen; i++) { sent =3D i =3D 0; ... i++, sent++ > + ret =3D __sys_sendmsg(s, &msgvec[i].msg_hdr, flags); > + if (ret =3D=3D -1) { > + if (sent !=3D 0) { > + /* We have sent messages. Let caller know. */ > + return (sent); > + } > + return (ret); > + } > + > + /* Save sent bytes */ > + msgvec[i].msg_len =3D ret; > + sent++; > + } > + > + return (sent); > +} > diff --git a/sys/sys/socket.h b/sys/sys/socket.h > index 18e2de1..d95f29e 100644 > --- a/sys/sys/socket.h > +++ b/sys/sys/socket.h > @@ -435,6 +435,11 @@ struct msghdr { > #ifdef _KERNEL > #define MSG_SOCALLBCK 0x10000 /* for use by socket callbacks - sorece= ive (TCP) */ > #endif > +#ifndef _KERNEL > +#ifdef __BSD_VISIBLE > +#define MSG_WAITFORONE 0x100000 /* used in recvmmsg() */ Move the define to the previous __BSD_VISIBLE block, which ends with CMSG_CLOEXEC. Also, it seems that the next unused bit is 0x80000. Replace the comment by 'for recvmmsg()', the MSG_COMPAT is something private. > +#endif /* __BSD_VISIBLE */ > +#endif /* !_KERNEL */ > =20 > /* > * Header for ancillary data objects in msg_control buffer. > @@ -595,6 +600,18 @@ struct sf_hdtr { > #endif /* _KERNEL */ > #endif /* __BSD_VISIBLE */ > =20 > +#ifndef _KERNEL > +#ifdef __BSD_VISIBLE > +/* > + * Send/recvmmsg specific structure(s) > + */ > +struct mmsghdr { > + struct msghdr msg_hdr; /* message header */ > + unsigned int msg_len; /* message length */ Still int for msg_len ? > +}; > +#endif /* __BSD_VISIBLE */ > +#endif /* !_KERNEL */ > + > #ifndef _KERNEL > =20 > #include > @@ -615,11 +632,19 @@ int listen(int, int); > ssize_t recv(int, void *, size_t, int); > ssize_t recvfrom(int, void *, size_t, int, struct sockaddr * __restrict,= socklen_t * __restrict); > ssize_t recvmsg(int, struct msghdr *, int); > +#if __BSD_VISIBLE > +struct timespec; > +ssize_t recvmmsg(int, struct mmsghdr *, size_t, int, > + const struct timespec *); It probably makes sense to mark pointers with __restrict. > +#endif > ssize_t send(int, const void *, size_t, int); > ssize_t sendto(int, const void *, > size_t, int, const struct sockaddr *, socklen_t); > ssize_t sendmsg(int, const struct msghdr *, int); > #if __BSD_VISIBLE > +ssize_t sendmmsg(int, struct mmsghdr *, size_t, int); > +#endif > +#if __BSD_VISIBLE > int sendfile(int, int, off_t, size_t, struct sf_hdtr *, off_t *, int); > int setfib(int); > #endif --Yia77v5a8fyVHJSl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWpFvaAAoJEJDCuSvBvK1BKkUP/RC49EX9QKT2M+PdUeg2Z1de W0BEzTgE00z6AcksRzBNXVhdDW7D1/oJub23x3qdPXuMju3npf2FE41Hzm2+0BmC pKKURku90CZfRX6sIQZgU1jZbjSzMhRfYc9T6QeJQq0cQqOY3wM+V4hrE5LxVmJK 2TlKafvGubrImoEQx5doWOrgdBEG9vQ0Zbko/SNnmU4BWFQYniS3Hk0R5/OtuFbH VqvxOToMpzL54EOqNsV0Toi//7TiAlfPXFZfxoKFTLUHwpm1EGYEUFEdGU9NcLM3 5ER5MiFpYCuo/za+uqzJjuWsmZs6uIRj4EgUPHvR4BOR5Tc/HgYYGVbsKHn0cYVK 0mNfWsABrbb4G2bsCI2Air/QPGGWrol52LDljt/Qf3JtveAIN1PIVBTkAomEp0bH Xw+N4IzTPWufJUuzKRH5z9FJY39sLqRHU02B27kHQnFQ71C6d6r1EZvQQ0sgWBdc 2DJKH4Y4vwYAWRj12h8MPqfdAv0CGlb1tMLjF8iQnrHwV7VvOgC47NMjIZ8HhtiJ CIohLIH4D4qijcl/0JwQlUNSNl3YapmKH7UQtYcnGIbmlAgNK7Aedk5UDal9AL28 F1M4Fs4IboBakD7aiXIOb4IPZJ8luUmqF65KJHhwtvRizm9aX7jbAcixVHjlb+Qx HwQ7jX9Um2CqqHrW6MMs =QCkz -----END PGP SIGNATURE----- --Yia77v5a8fyVHJSl-- From owner-freebsd-threads@freebsd.org Sun Jan 24 09:07:52 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39C0EA8FD2E for ; Sun, 24 Jan 2016 09:07:52 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 117AD1ED2 for ; Sun, 24 Jan 2016 09:07:52 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0DD98A8FD2C; Sun, 24 Jan 2016 09:07:52 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E64E5A8FD2A; Sun, 24 Jan 2016 09:07:51 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 764581ED0; Sun, 24 Jan 2016 09:07:51 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id n5so38515813wmn.0; Sun, 24 Jan 2016 01:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=ftgCuFcYSMnB6fuySuMbNckj06Pk0AgBG2W8kZzZtk4=; b=s4ewxpHOPi6DxQxbR2j4sivSOc6LL9Mwck1jDtHcQs3Qs/9M43VegwjGe0deQ1O6IP dI2KLTLilkNLV8oxBDuI1spQhuMqKR6ZMsjy5uh7OPP+pFSusCCWpPBw5JacIykRn0i/ RkHmUgn1MqGeRBVzQ8PxuCFSBP0uFf7M9TguR8w4HrQFRIjR4gt65BJDS0HGqRYMGKPA yo+Qjs/lkTYg0B6BQtLz/h/DoCr7ay5iPj716U3yLPO5BIf3t0NLanfvSrqHcxPKcQpe FMRKhF/YNrRtOBjuVYbin0+AlR/8aF+Fjvj6uHGEZAGkYYbT7GitC3b2lyBoRGbb7xe7 wxAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-type :content-transfer-encoding; bh=ftgCuFcYSMnB6fuySuMbNckj06Pk0AgBG2W8kZzZtk4=; b=MQ0e4F4dumpKOvRACidgGt81X7BrwXjHBoW/4Mu/wCKxJssYAtRM+rdThlA0BKiGYO 2HMqDpdFFqcw6vYJuFHAIAOwBDttQHkUi1NHNuC5afs1nA078lJLHGb03QobKKtB7GFT PJ4/UgA5ocy//oV/SsqL+DxSekynlYcLzozXp5MWfCXjamwqQafQQD4AWhZ9eXo0/+pB CWBNcB1n5KXxzlvCri40GI1RAK0lJmpb6V+anHQLQ+mEuAeIIO4WKdDBDy+hlQNnppfv FE+hcM0D+immi62wviqoWIeJEgkbtmf/izls14/LZdpE2YL2lRCVKVQDrcOUpGGwaJAo /CxA== X-Gm-Message-State: AG10YORKQ9nr4JSO4oEWQ2U9nIuRnWO6iKuxLP5kEjCoYbQ+CHSt+u+9cphanKZUNQWgeA== X-Received: by 10.28.215.136 with SMTP id o130mr11996775wmg.33.1453626469665; Sun, 24 Jan 2016 01:07:49 -0800 (PST) Received: from ernst.home (p4FCA7FB6.dip0.t-ipconnect.de. [79.202.127.182]) by smtp.gmail.com with ESMTPSA id b127sm10631818wmh.9.2016.01.24.01.07.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jan 2016 01:07:49 -0800 (PST) Date: Sun, 24 Jan 2016 10:07:47 +0100 From: Gary Jennejohn To: Konstantin Belousov Cc: Boris Astardzhiev , threads@freebsd.org, Bruce Evans , net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160124100747.551f8e3f@ernst.home> In-Reply-To: <20160124050634.GS3942@kib.kiev.ua> References: <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 09:07:52 -0000 On Sun, 24 Jan 2016 07:06:34 +0200 Konstantin Belousov wrote: [delete irrelevant parts of the patch] > > + rcvd = 1; > > + for (i = rcvd; i < vlen; i++) { > i = rcvd = 1; ... i++, rcvd++ ? > > > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > > + if (ret == -1) { > > + if (rcvd != 0) { > > + /* We've received messages. Let caller know. */ > > + return (rcvd); > > + } > > + return (ret); > > + } > > + This seems wrong. rcvd is initialized to 1 so that the check for rcvd != 0 can never be false. We already successfully called __sys_recvmsg() just above the loop, so why not simplify the code by doing if (ret == -1) return (rcvd); -- Gary Jennejohn (gj@) From owner-freebsd-threads@freebsd.org Mon Jan 25 09:22:16 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2065A3145E for ; Mon, 25 Jan 2016 09:22:16 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9D247B1A for ; Mon, 25 Jan 2016 09:22:16 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9A039A3145B; Mon, 25 Jan 2016 09:22:16 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 810E2A31459; Mon, 25 Jan 2016 09:22:16 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 066F5B17; Mon, 25 Jan 2016 09:22:16 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id r129so55543748wmr.0; Mon, 25 Jan 2016 01:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CcFkVN47pIQ5OVbrQHvURyT9WAvjP32Z9OoYuQbifsc=; b=HFi4le++96JrxICuvWWBRZd1XkvrUlU8QvX/PbV5mE6yoA1+uw8u7UIm3gZ8MGhu+V 7HeUsfor3WJ14e7MgvByblCKywcXmKqg/92t0KF6N4yMd9EtUtcGw31tyUfFMSXIBuwz xEasjvjewA2w34JwR+ELpVdjeen5i9+EfOY3JcPKcHpxyx3qSMvpiircQZjjRwK7iyus dArtKEqqQMFPM7ixRPiWg8uO4onW28CGSFEzV6YEKfZA9zWfD8GD/CCkaYpyYaFJmHKp kFKRV9CGcuLan7bcxdpKGYXS+DQ200R1HVU6N3BHNRyIYA8g99GIqzv/Zz2ImDbIr+E3 yjTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CcFkVN47pIQ5OVbrQHvURyT9WAvjP32Z9OoYuQbifsc=; b=WH7K9hQFF1SZBkZ8OBb/P+aRkFo8yryEfNJQIWb5f0SszPbc57YwPqLk0P59GdFL2c KldN60pUcD/PLGvbuIVQcqeKaFGbj0a5Y+CaASbscDxWi27TVsuYW0gWdTeaZ351NwkE TEhCXg23ajBHlfPkEugiDvbGVUS2xU9f3qFEQcTH/XRZTGRWFw4j7RWVLIJvvdPawEfq TucVecKusLgL/JbHVIhmCQZ5mMtK4IN+UmLwiwXLz3pY1At2A+rA4XnHLZd0JkXv+0jD lgwk2OOvhPjod7Ol3hG656h7eIC/e8vtFjkDKbQ6oWpbQSfctfLnSEKzdibalG2t3SVm WTaQ== X-Gm-Message-State: AG10YORd7M5AZD14AYitsxJtZ7n1lXZQpgXmp6XlI7qSUtf2AsHTkvdHSUBlIvgXLVrFe/ayZUEGmuyKbAxhPQ== MIME-Version: 1.0 X-Received: by 10.194.78.175 with SMTP id c15mr16420727wjx.16.1453713733992; Mon, 25 Jan 2016 01:22:13 -0800 (PST) Received: by 10.28.136.148 with HTTP; Mon, 25 Jan 2016 01:22:13 -0800 (PST) In-Reply-To: <20160124100747.551f8e3f@ernst.home> References: <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> Date: Mon, 25 Jan 2016 11:22:13 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: gljennjohn@gmail.com Cc: Konstantin Belousov , threads@freebsd.org, Bruce Evans , net@freebsd.org Content-Type: multipart/mixed; boundary=047d7bfcf874b8bfce052a251a15 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 09:22:16 -0000 --047d7bfcf874b8bfce052a251a15 Content-Type: text/plain; charset=UTF-8 kb>You defer to ppoll() and pselect() due to the struct timespec type of kb>the argument, am I right ? Yes. kb>BTW, just noted, I think the functions should live in libc/gen. Okay. Moving them. kb>Put each sentence on new line Done. kb>The CMTR define is only used once. I do not see why not inline it, and kb>get rid of the staircase of backslashes. Initially I wrote two CMTRs - one using pselect and the other using ppoll. I left it this way to easily switch between these and that's why I have this macro. I'll inline the code as suggested. kb>Also, it seems that the next unused bit is 0x80000. I noticed that as well and fixed it. kb>Still int for msg_len ? I'll convert it to ssize_t. kb>It probably makes sense to mark pointers with __restrict. Done. gj>This seems wrong. rcvd is initialized to 1 so that the check for gj>rcvd != 0 can never be false. We already successfully called gj>__sys_recvmsg() just above the loop, so why not simplify the gj>code by doing gj> gj> if (ret == -1) gj> return (rcvd); Fixed. On Sun, Jan 24, 2016 at 11:07 AM, Gary Jennejohn wrote: > On Sun, 24 Jan 2016 07:06:34 +0200 > Konstantin Belousov wrote: > > [delete irrelevant parts of the patch] > > > > + rcvd = 1; > > > + for (i = rcvd; i < vlen; i++) { > > i = rcvd = 1; ... i++, rcvd++ ? > > > > > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > > > + if (ret == -1) { > > > + if (rcvd != 0) { > > > + /* We've received messages. Let caller > know. */ > > > > + return (rcvd); > > > + } > > > + return (ret); > > > + } > > > + > > This seems wrong. rcvd is initialized to 1 so that the check for > rcvd != 0 can never be false. We already successfully called > __sys_recvmsg() just above the loop, so why not simplify the > code by doing > > if (ret == -1) > return (rcvd); > > -- > Gary Jennejohn (gj@) > --047d7bfcf874b8bfce052a251a15 Content-Type: text/plain; charset=US-ASCII; name="sendrecvmmsg-libconly5.diff" Content-Disposition: attachment; filename="sendrecvmmsg-libconly5.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ijtrkzeo0 ZGlmZiAtLWdpdCBhL2xpYi9saWJjL2dlbi9NYWtlZmlsZS5pbmMgYi9saWIvbGliYy9nZW4vTWFr ZWZpbGUuaW5jCmluZGV4IGI0NDg0NjEuLmY5ZDJmOGEgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL2dl bi9NYWtlZmlsZS5pbmMKKysrIGIvbGliL2xpYmMvZ2VuL01ha2VmaWxlLmluYwpAQCAtOTksMTEg Kzk5LDEzIEBAIFNSQ1MrPQlfX2dldG9zcmVsZGF0ZS5jIFwKIAlyYWlzZS5jIFwKIAlyZWFkZGly LmMgXAogCXJlYWRwYXNzcGhyYXNlLmMgXAorCXJlY3ZtbXNnLmMgXAogCXJld2luZGRpci5jIFwK IAlzY2FuZGlyLmMgXAogCXNlZWQ0OC5jIFwKIAlzZWVrZGlyLmMgXAogCXNlbWN0bC5jIFwKKwlz ZW5kbW1zZy5jIFwKIAlzZXRkb21haW5uYW1lLmMgXAogCXNldGhvc3RuYW1lLmMgXAogCXNldGpt cGVyci5jIFwKZGlmZiAtLWdpdCBhL2xpYi9saWJjL2dlbi9yZWN2bW1zZy5jIGIvbGliL2xpYmMv Z2VuL3JlY3ZtbXNnLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uOTg4MzVi YQotLS0gL2Rldi9udWxsCisrKyBiL2xpYi9saWJjL2dlbi9yZWN2bW1zZy5jCkBAIC0wLDAgKzEs ODYgQEAKKy8qCisgKiBDb3B5cmlnaHQgKGMpIDIwMTYgQm9yaXMgQXN0YXJkemhpZXYsIFNtYXJ0 Y29tLUJ1bGdhcmlhIEFECisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJp YnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91 dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxv d2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNv dXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZShz KSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBh cworICogICAgdGhlIGZpcnN0IGxpbmVzIG9mIHRoaXMgZmlsZSB1bm1vZGlmaWVkIG90aGVyIHRo YW4gdGhlIHBvc3NpYmxlCisgKiAgICBhZGRpdGlvbiBvZiBvbmUgb3IgbW9yZSBjb3B5cmlnaHQg bm90aWNlcy4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJv ZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UocyksIHRoaXMgbGlzdCBvZiBj b25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4KKyAqICAgIHRoZSBkb2N1 bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUKKyAqICAg IGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBD T1BZUklHSFQgSE9MREVSKFMpIGBgQVMgSVMnJyBBTkQgQU5ZCisgKiBFWFBSRVNTIE9SIElNUExJ RUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1Q TElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSCisgKiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhF IENPUFlSSUdIVCBIT0xERVIoUykgQkUKKyAqIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJF Q1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IKKyAqIENPTlNFUVVFTlRJQUwg REFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GCisg KiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJP RklUUzsgT1IKKyAqIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9O IEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLAorICogV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNU IExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UKKyAqIE9SIE9USEVSV0lT RSkgQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsCisg KiBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgorICov CisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQiKTsKKworI2lu Y2x1ZGUgPGVycm5vLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3N5 c2NhbGwuaD4KKyNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CisjaW5jbHVkZSA8c3lzL3NlbGVjdC5o PgorI2luY2x1ZGUgPHB0aHJlYWQuaD4KKyNpbmNsdWRlICJsaWJjX3ByaXZhdGUuaCIKKworc3Np emVfdAorcmVjdm1tc2coaW50IHMsIHN0cnVjdCBtbXNnaGRyICpfX3Jlc3RyaWN0IG1zZ3ZlYywg c2l6ZV90IHZsZW4sIGludCBmbGFncywKKyAgICBjb25zdCBzdHJ1Y3QgdGltZXNwZWMgKl9fcmVz dHJpY3QgdGltZW91dCkKK3sKKwlzaXplX3QgaSwgcmN2ZDsKKwlzc2l6ZV90IHJldDsKKworCWlm ICh0aW1lb3V0ICE9IE5VTEwpIHsKKwkJZmRfc2V0IGZkczsKKwkJaW50IHJlczsKKworCQlGRF9a RVJPKCZmZHMpOworCQlGRF9TRVQocywgJmZkcyk7CisJCXJlcyA9IF9fc3lzX3BzZWxlY3QocyAr IDEsICZmZHMsIE5VTEwsIE5VTEwsIHRpbWVvdXQsIE5VTEwpOworCQlpZiAocmVzID09IC0xIHx8 IHJlcyA9PSAwKQorCQkJcmV0dXJuIChyZXMpOworCQlpZiAoIUZEX0lTU0VUKHMsICZmZHMpKQor CQkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0ID0gX19zeXNfcmVjdm1zZyhzLCAmbXNndmVjWzBd Lm1zZ19oZHIsIGZsYWdzKTsKKwlpZiAocmV0ID09IC0xKQorCQlyZXR1cm4gKHJldCk7CisKKwkv KiBDaGVjayBpbml0aWFsbHkgZm9yIHRoZSBwcmVzZW5jZSBvZiBNU0dfV0FJVEZPUk9ORS4KKwkg KiBUdXJuIG9uIE1TR19ET05UV0FJVCBpZiBzZXQuICovCisJaWYgKGZsYWdzICYgTVNHX1dBSVRG T1JPTkUpIHsKKwkJZmxhZ3MgfD0gTVNHX0RPTlRXQUlUOworCQkvKiBUaGUga2VybmVsIGRvZXNu J3QgbmVlZCB0byBrbm93IGFib3V0IHRoaXMgZmxhZy4gKi8KKwkJZmxhZ3MgJj0gfk1TR19XQUlU Rk9ST05FOworCX0KKworCXJjdmQgPSAxOworCWZvciAoaSA9IHJjdmQ7IGkgPCB2bGVuOyBpKyss IHJjdmQrKykgeworCQlyZXQgPSBfX3N5c19yZWN2bXNnKHMsICZtc2d2ZWNbaV0ubXNnX2hkciwg ZmxhZ3MpOworCQlpZiAocmV0ID09IC0xKSB7CisJCQkvKiBXZSBoYXZlIHJlY2VpdmVkIG1lc3Nh Z2VzLiBMZXQgY2FsbGVyIGtub3cuICovCisJCQlyZXR1cm4gKHJjdmQpOworCQl9CisKKwkJLyog U2F2ZSByZWNlaXZlZCBieXRlcyAqLworCQltc2d2ZWNbaV0ubXNnX2xlbiA9IHJldDsKKwl9CisK KwlyZXR1cm4gKHJjdmQpOworfQpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvZ2VuL3NlbmRtbXNnLmMg Yi9saWIvbGliYy9nZW4vc2VuZG1tc2cuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAw MDAwLi5lNGU2MmE0Ci0tLSAvZGV2L251bGwKKysrIGIvbGliL2xpYmMvZ2VuL3NlbmRtbXNnLmMK QEAgLTAsMCArMSw2MiBAQAorLyoKKyAqIENvcHlyaWdodCAoYykgMjAxNiBCb3JpcyBBc3RhcmR6 aGlldiwgU21hcnRjb20tQnVsZ2FyaWEgQUQKKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgor ICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0 aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhh dCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1 dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICog ICAgbm90aWNlKHMpLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBk aXNjbGFpbWVyIGFzCisgKiAgICB0aGUgZmlyc3QgbGluZXMgb2YgdGhpcyBmaWxlIHVubW9kaWZp ZWQgb3RoZXIgdGhhbiB0aGUgcG9zc2libGUKKyAqICAgIGFkZGl0aW9uIG9mIG9uZSBvciBtb3Jl IGNvcHlyaWdodCBub3RpY2VzLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3Jt IG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZShzKSwgdGhp cyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbgorICog ICAgdGhlIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRo IHRoZQorICogICAgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklE RUQgQlkgVEhFIENPUFlSSUdIVCBIT0xERVIoUykgYGBBUyBJUycnIEFORCBBTlkKKyAqIEVYUFJF U1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywg VEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNT IEZPUiBBIFBBUlRJQ1VMQVIKKyAqIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVO VCBTSEFMTCBUSEUgQ09QWVJJR0hUIEhPTERFUihTKSBCRQorICogTElBQkxFIEZPUiBBTlkgRElS RUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUgorICogQ09O U0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VS RU1FTlQgT0YKKyAqIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBE QVRBLCBPUiBQUk9GSVRTOyBPUgorICogQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENB VVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksCisgKiBXSEVUSEVSIElOIENPTlRS QUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRQorICog T1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBT T0ZUV0FSRSwKKyAqIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBE QU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNE JCIpOworCisjaW5jbHVkZSA8ZXJybm8uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNs dWRlIDxzeXMvc3lzY2FsbC5oPgorI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRlIDxw dGhyZWFkLmg+CisjaW5jbHVkZSAibGliY19wcml2YXRlLmgiCisKK3NzaXplX3QKK3NlbmRtbXNn KGludCBzLCBzdHJ1Y3QgbW1zZ2hkciAqX19yZXN0cmljdCBtc2d2ZWMsIHNpemVfdCB2bGVuLCBp bnQgZmxhZ3MpCit7CisJc2l6ZV90IGksIHNlbnQ7CisJc3NpemVfdCByZXQ7CisKKwlzZW50ID0g MDsKKwlmb3IgKGkgPSAwOyBpIDwgdmxlbjsgaSsrLCBzZW50KyspIHsKKwkJcmV0ID0gX19zeXNf c2VuZG1zZyhzLCAmbXNndmVjW2ldLm1zZ19oZHIsIGZsYWdzKTsKKwkJaWYgKHJldCA9PSAtMSkg eworCQkJaWYgKHNlbnQgIT0gMCkgeworCQkJCS8qIFdlIGhhdmUgc2VudCBtZXNzYWdlcy4gTGV0 IGNhbGxlciBrbm93LiAqLworCQkJCXJldHVybiAoc2VudCk7CisJCQl9CisJCQlyZXR1cm4gKHJl dCk7CisJCX0KKworCQkvKiBTYXZlIHNlbnQgYnl0ZXMgKi8KKwkJbXNndmVjW2ldLm1zZ19sZW4g PSByZXQ7CisJfQorCisJcmV0dXJuIChzZW50KTsKK30KZGlmZiAtLWdpdCBhL2xpYi9saWJjL2lu Y2x1ZGUvbmFtZXNwYWNlLmggYi9saWIvbGliYy9pbmNsdWRlL25hbWVzcGFjZS5oCmluZGV4IDcz OWQ3YjEuLmM5NTgyOWUgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL2luY2x1ZGUvbmFtZXNwYWNlLmgK KysrIGIvbGliL2xpYmMvaW5jbHVkZS9uYW1lc3BhY2UuaApAQCAtMjA4LDYgKzIwOCw3IEBACiAj ZGVmaW5lCQlyZWFkdgkJCQlfcmVhZHYKICNkZWZpbmUJCXJlY3Zmcm9tCQkJX3JlY3Zmcm9tCiAj ZGVmaW5lCQlyZWN2bXNnCQkJCV9yZWN2bXNnCisjZGVmaW5lCQlyZWN2bW1zZwkJCV9yZWN2bW1z ZwogI2RlZmluZQkJc2VsZWN0CQkJCV9zZWxlY3QKICNkZWZpbmUJCXNlbV9jbG9zZQkJCV9zZW1f Y2xvc2UKICNkZWZpbmUJCXNlbV9kZXN0cm95CQkJX3NlbV9kZXN0cm95CkBAIC0yMjAsNiArMjIx LDcgQEAKICNkZWZpbmUJCXNlbV91bmxpbmsJCQlfc2VtX3VubGluawogI2RlZmluZQkJc2VtX3dh aXQJCQlfc2VtX3dhaXQKICNkZWZpbmUJCXNlbmRtc2cJCQkJX3NlbmRtc2cKKyNkZWZpbmUJCXNl bmRtbXNnCQkJX3NlbmRtbXNnCiAjZGVmaW5lCQlzZW5kdG8JCQkJX3NlbmR0bwogI2RlZmluZQkJ c2V0c29ja29wdAkJCV9zZXRzb2Nrb3B0CiAvKiNkZWZpbmUJCXNpZ2FjdGlvbgkJCV9zaWdhY3Rp b24qLwpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvaW5jbHVkZS91bi1uYW1lc3BhY2UuaCBiL2xpYi9s aWJjL2luY2x1ZGUvdW4tbmFtZXNwYWNlLmgKaW5kZXggZjMxZmE3YS4uMDIzMzM0OCAxMDA2NDQK LS0tIGEvbGliL2xpYmMvaW5jbHVkZS91bi1uYW1lc3BhY2UuaAorKysgYi9saWIvbGliYy9pbmNs dWRlL3VuLW5hbWVzcGFjZS5oCkBAIC0xODksNiArMTg5LDcgQEAKICN1bmRlZgkJcmVhZHYKICN1 bmRlZgkJcmVjdmZyb20KICN1bmRlZgkJcmVjdm1zZworI3VuZGVmCQlyZWN2bW1zZwogI3VuZGVm CQlzZWxlY3QKICN1bmRlZgkJc2VtX2Nsb3NlCiAjdW5kZWYJCXNlbV9kZXN0cm95CkBAIC0yMDEs NiArMjAyLDcgQEAKICN1bmRlZgkJc2VtX3VubGluawogI3VuZGVmCQlzZW1fd2FpdAogI3VuZGVm CQlzZW5kbXNnCisjdW5kZWYJCXNlbmRtbXNnCiAjdW5kZWYJCXNlbmR0bwogI3VuZGVmCQlzZXRz b2Nrb3B0CiAjdW5kZWYJCXNpZ2FjdGlvbgpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvc3lzL1N5bWJv bC5tYXAgYi9saWIvbGliYy9zeXMvU3ltYm9sLm1hcAppbmRleCA3YjMyNTdjLi5kYzJlZDBlIDEw MDY0NAotLS0gYS9saWIvbGliYy9zeXMvU3ltYm9sLm1hcAorKysgYi9saWIvbGliYy9zeXMvU3lt Ym9sLm1hcApAQCAtMzk5LDYgKzM5OSw4IEBAIEZCU0RfMS40IHsKIAl1dGltZW5zYXQ7CiAJbnVt YV9zZXRhZmZpbml0eTsKIAludW1hX2dldGFmZmluaXR5OworCXNlbmRtbXNnOworCXJlY3ZtbXNn OwogfTsKIAogRkJTRHByaXZhdGVfMS4wIHsKZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5cy9yZWN2 LjIgYi9saWIvbGliYy9zeXMvcmVjdi4yCmluZGV4IDMyNmU3ZmYuLmU5NDAzNjQgMTAwNjQ0Ci0t LSBhL2xpYi9saWJjL3N5cy9yZWN2LjIKKysrIGIvbGliL2xpYmMvc3lzL3JlY3YuMgpAQCAtMzQs OCArMzQsOSBAQAogLlNoIE5BTUUKIC5ObSByZWN2ICwKIC5ObSByZWN2ZnJvbSAsCi0uTm0gcmVj dm1zZwotLk5kIHJlY2VpdmUgYSBtZXNzYWdlIGZyb20gYSBzb2NrZXQKKy5ObSByZWN2bXNnICwK Ky5ObSByZWN2bW1zZworLk5kIHJlY2VpdmUgbWVzc2FnZShzKSBmcm9tIGEgc29ja2V0CiAuU2gg TElCUkFSWQogLkxiIGxpYmMKIC5TaCBTWU5PUFNJUwpAQCAtNDcsMTEgKzQ4LDE1IEBACiAuRm4g cmVjdmZyb20gImludCBzIiAidm9pZCAqYnVmIiAic2l6ZV90IGxlbiIgImludCBmbGFncyIgInN0 cnVjdCBzb2NrYWRkciAqIHJlc3RyaWN0IGZyb20iICJzb2NrbGVuX3QgKiByZXN0cmljdCBmcm9t bGVuIgogLkZ0IHNzaXplX3QKIC5GbiByZWN2bXNnICJpbnQgcyIgInN0cnVjdCBtc2doZHIgKm1z ZyIgImludCBmbGFncyIKKy5GdCBzc2l6ZV90CisuRm4gcmVjdm1tc2cgImludCBzIiAic3RydWN0 IG1tc2doZHIgKiByZXN0cmljdCBtc2d2ZWMiICJzaXplX3QgdmxlbiIgImludCBmbGFncyIgImNv bnN0IHN0cnVjdCB0aW1lc3BlYyAqIHJlc3RyaWN0IHRpbWVvdXQiCiAuU2ggREVTQ1JJUFRJT04K IFRoZQogLkZuIHJlY3Zmcm9tCiBhbmQKIC5GbiByZWN2bXNnCithbmQKKy5GbiByZWN2bW1zZwog c3lzdGVtIGNhbGxzCiBhcmUgdXNlZCB0byByZWNlaXZlIG1lc3NhZ2VzIGZyb20gYSBzb2NrZXQs CiBhbmQgbWF5IGJlIHVzZWQgdG8gcmVjZWl2ZSBkYXRhIG9uIGEgc29ja2V0IHdoZXRoZXIgb3Ig bm90CkBAIC04NCw4ICs4OSwyOSBAQCBudWxsIHBvaW50ZXIgcGFzc2VkIGFzIGl0cwogLkZhIGZy b20KIGFyZ3VtZW50LgogLlBwCi1BbGwgdGhyZWUgcm91dGluZXMgcmV0dXJuIHRoZSBsZW5ndGgg b2YgdGhlIG1lc3NhZ2Ugb24gc3VjY2Vzc2Z1bAotY29tcGxldGlvbi4KK1RoZQorLkZuIHJlY3Zt bXNnCitmdW5jdGlvbiBpcyB1c2VkIHRvIHJlY2VpdmUgbXVsdGlwbGUKK21lc3NhZ2VzIGF0IGEg Y2FsbC4KK1RoZWlyIG51bWJlciBpcyBzdXBwbGllZCBieQorLkZhIHZsZW4gLgorVGhlIG1lc3Nh Z2VzIGFyZSBwbGFjZWQgaW4gdGhlCisuRmEgbXNndmVjCit2ZWN0b3IgYWZ0ZXIgcmVjZXB0aW9u LgorVGhlIHNpemUgb2YgZWFjaCByZWNlaXZlZCBtZXNzYWdlIGlzIHBsYWNlZCBpbiB0aGUKKy5G YSBtc2dfbGVuCitmaWVsZCBvZiBlYWNoIGVsZW1lbnQgb2YgdGhlIHZlY3Rvci4KK0lmCisuRmEg dGltZW91dAoraXMgTlVMTCB0aGUgY2FsbCB3aWxsIG5vcm1hbGx5IGJsb2NrLgorT3RoZXJ3aXNl IGl0IHdpbGwgd2FpdCBmb3IgZGF0YSBmb3IgdGhlIHNwZWNpZmllZCBhbW91bnQgb2YgdGltZS4K K0lmIHRoZSB0aW1lb3V0IGV4cGlyZXMgYW5kIHRoZXJlIGlzIG5vIGRhdGEgcmVjZWl2ZWQgYSB2 YWx1ZSBvZiAwIGlzIHJldHVybmVkLgorcHNlbGVjdCgyKSBpcyB1c2VkIGZvciB0aGUgaW1wbGVt ZW50YXRpb24gb2YgdGhlIHRpbWVvdXQgbWVjaGFuaXNtLgorLlBwCitUaGUgZmlyc3QgdGhyZWUg cm91dGluZXMgcmV0dXJuIHRoZSBsZW5ndGggb2YgdGhlIG1lc3NhZ2Ugb24gc3VjY2Vzc2Z1bAor Y29tcGxldGlvbiB3aGVyZWFzCisuRm4gcmVjdm1tc2cKK3JldHVybnMgdGhlIG51bWJlciBvZiBy ZWNlaXZlZCBtZXNzYWdlcy4KIElmIGEgbWVzc2FnZSBpcyB0b28gbG9uZyB0byBmaXQgaW4gdGhl IHN1cHBsaWVkIGJ1ZmZlciwKIGV4Y2VzcyBieXRlcyBtYXkgYmUgZGlzY2FyZGVkIGRlcGVuZGlu ZyBvbiB0aGUgdHlwZSBvZiBzb2NrZXQKIHRoZSBtZXNzYWdlIGlzIHJlY2VpdmVkIGZyb20gKHNl ZQpAQCAtMTAwLDcgKzEyNiw5IEBAIGluIHdoaWNoIGNhc2UgdGhlIHZhbHVlCiAuVmEgZXJybm8K IGlzIHNldCB0bwogLkVyIEVBR0FJTiAuCi1UaGUgcmVjZWl2ZSBjYWxscyBub3JtYWxseSByZXR1 cm4gYW55IGRhdGEgYXZhaWxhYmxlLAorVGhlIHJlY2VpdmUgY2FsbHMgZXhjZXB0CisuRm4gcmVj dm1tc2cKK25vcm1hbGx5IHJldHVybiBhbnkgZGF0YSBhdmFpbGFibGUsCiB1cCB0byB0aGUgcmVx dWVzdGVkIGFtb3VudCwKIHJhdGhlciB0aGFuIHdhaXRpbmcgZm9yIHJlY2VpcHQgb2YgdGhlIGZ1 bGwgYW1vdW50IHJlcXVlc3RlZDsKIHRoaXMgYmVoYXZpb3IgaXMgYWZmZWN0ZWQgYnkgdGhlIHNv Y2tldC1sZXZlbCBvcHRpb25zCkBAIC0xMjcsNiArMTU1LDkgQEAgb25lIG9yIG1vcmUgb2YgdGhl IHZhbHVlczoKIC5JdCBEdiBNU0dfV0FJVEFMTCBUYSB3YWl0IGZvciBmdWxsIHJlcXVlc3Qgb3Ig ZXJyb3IKIC5JdCBEdiBNU0dfRE9OVFdBSVQgVGEgZG8gbm90IGJsb2NrCiAuSXQgRHYgTVNHX0NN U0dfQ0xPRVhFQyBUYSBzZXQgcmVjZWl2ZWQgZmRzIGNsb3NlLW9uLWV4ZWMKKy5JdCBEdiBNU0df V0FJVEZPUk9ORSBUYSBkbyBub3QgYmxvY2sgYWZ0ZXIgcmVjZWl2aW5nIHRoZSBmaXJzdCBtZXNz YWdlCisocmVsZXZhbnQgb25seSBmb3IKKy5GbiByZWN2bW1zZyApCiAuRWwKIC5QcAogVGhlCkBA IC0xNTgsNiArMTg5LDExIEBAIGlzIHNldCB0bwogVGhpcyBmbGFnIGlzIG5vdCBhdmFpbGFibGUg aW4gc3RyaWN0CiAuVG4gQU5TSQogb3IgQzk5IGNvbXBpbGF0aW9uIG1vZGUuCitUaGUKKy5EdiBN U0dfV0FJVEZPUk9ORQorZmxhZyBzZXRzIE1TR19ET05UV0FJVCBhZnRlciB0aGUgZmlyc3QgbWVz c2FnZSBoYXMgYmVlbiByZWNlaXZlZC4KK1RoaXMgZmxhZyBpcyBvbmx5IHJlbGV2YW50IGZvcgor LkZuIHJlY3ZtbXNnIC4KIC5QcAogVGhlCiAuRm4gcmVjdm1zZwpAQCAtMjkwLDkgKzMyNiwzMyBA QCBjb250cm9sIGRhdGEgd2VyZSBkaXNjYXJkZWQgZHVlIHRvIGxhY2sgb2Ygc3BhY2UgaW4gdGhl IGJ1ZmZlcgogZm9yIGFuY2lsbGFyeSBkYXRhLgogLkR2IE1TR19PT0IKIGlzIHJldHVybmVkIHRv IGluZGljYXRlIHRoYXQgZXhwZWRpdGVkIG9yIG91dC1vZi1iYW5kIGRhdGEgd2VyZSByZWNlaXZl ZC4KKy5QcAorVGhlCisuRm4gcmVjdm1tc2cKK3N5c3RlbSBjYWxsIHVzZXMgdGhlCisuRmEgbW1z Z2hkcgorc3RydWN0dXJlLiBJdHMgZm9ybSBpcyBhcyBmb2xsb3dzLCBhcyBkZWZpbmVkIGluCisu SW4gc3lzL3NvY2tldC5oIDoKKy5CZCAtbGl0ZXJhbAorc3RydWN0IG1tc2doZHIgeworCXN0cnVj dCBtc2doZHIJIG1zZ19oZHI7CS8qIG1lc3NhZ2UgaGVhZGVyICovCisJc3NpemVfdAkJIG1zZ19s ZW47CS8qIG1lc3NhZ2UgbGVuZ3RoICovCit9OworLkVkCisuUHAKK0ZvcgorLkZhIG1zZ19oZHIK K3NlZSBhYm92ZS4gT24gZGF0YSByZWNlcHRpb24gdGhlCisuRmEgbXNnX2xlbgorZmllbGQgaXMg dXBkYXRlZCB0byB0aGUgbGVuZ3RoIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdlLgorT24gZGF0YSB0 cmFuc21pc3Npb24gaXQgaXMgdXBkYXRlZCB0byB0aGUgbnVtYmVyIG9mIGNoYXJhY3RlcnMgc2Vu dC4KIC5TaCBSRVRVUk4gVkFMVUVTCi1UaGVzZSBjYWxscyByZXR1cm4gdGhlIG51bWJlciBvZiBi eXRlcyByZWNlaXZlZCwgb3IgLTEKLWlmIGFuIGVycm9yIG9jY3VycmVkLgorVGhlc2UgY2FsbHMg ZXhjZXB0CisuRm4gcmVjdm1tc2cKK3JldHVybiB0aGUgbnVtYmVyIG9mIGJ5dGVzIHJlY2VpdmVk LgorLkZuIHJlY3ZtbXNnCityZXR1cm5zIHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgcmVjZWl2ZWQu CitBIHZhbHVlIG9mIC0xIGlzIHJldHVybmVkIGlmIGFuIGVycm9yIG9jY3VycmVkLgogLlNoIEVS Uk9SUwogVGhlIGNhbGxzIGZhaWwgaWY6CiAuQmwgLXRhZyAtd2lkdGggRXIKZGlmZiAtLWdpdCBh L2xpYi9saWJjL3N5cy9zZW5kLjIgYi9saWIvbGliYy9zeXMvc2VuZC4yCmluZGV4IDhmYTJjNjQu Ljk4MTBhY2UgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL3N5cy9zZW5kLjIKKysrIGIvbGliL2xpYmMv c3lzL3NlbmQuMgpAQCAtMzQsOCArMzQsOSBAQAogLlNoIE5BTUUKIC5ObSBzZW5kICwKIC5ObSBz ZW5kdG8gLAotLk5tIHNlbmRtc2cKLS5OZCBzZW5kIGEgbWVzc2FnZSBmcm9tIGEgc29ja2V0Cisu Tm0gc2VuZG1zZyAsCisuTm0gc2VuZG1tc2cKKy5OZCBzZW5kIG1lc3NhZ2UocykgZnJvbSBhIHNv Y2tldAogLlNoIExJQlJBUlkKIC5MYiBsaWJjCiAuU2ggU1lOT1BTSVMKQEAgLTQ3LDYgKzQ4LDgg QEAKIC5GbiBzZW5kdG8gImludCBzIiAiY29uc3Qgdm9pZCAqbXNnIiAic2l6ZV90IGxlbiIgImlu dCBmbGFncyIgImNvbnN0IHN0cnVjdCBzb2NrYWRkciAqdG8iICJzb2NrbGVuX3QgdG9sZW4iCiAu RnQgc3NpemVfdAogLkZuIHNlbmRtc2cgImludCBzIiAiY29uc3Qgc3RydWN0IG1zZ2hkciAqbXNn IiAiaW50IGZsYWdzIgorLkZ0IHNzaXplX3QKKy5GbiBzZW5kbW1zZyAiaW50IHMiICJzdHJ1Y3Qg bW1zZ2hkciAqIHJlc3RyaWN0IG1zZ3ZlYyIgInNpemVfdCB2bGVuIiAiaW50IGZsYWdzIgogLlNo IERFU0NSSVBUSU9OCiBUaGUKIC5GbiBzZW5kCkBAIC01NSw4ICs1OCwxMSBAQCBhbmQKIC5GbiBz ZW5kdG8KIGFuZAogLkZuIHNlbmRtc2cKK2FuZAorLkZuIHNlbmRtbXNnCiBzeXN0ZW0gY2FsbHMK LWFyZSB1c2VkIHRvIHRyYW5zbWl0IGEgbWVzc2FnZSB0byBhbm90aGVyIHNvY2tldC4KK2FyZSB1 c2VkIHRvIHRyYW5zbWl0IG9uZSBvciBtdWx0aXBsZSBtZXNzYWdlcyAod2l0aCB0aGUgbGF0dGVy IGNhbGwpIHRvCithbm90aGVyIHNvY2tldC4KIFRoZQogLkZuIHNlbmQKIGZ1bmN0aW9uCkBAIC02 Niw2ICs3Miw4IEBAIHN0YXRlLCB3aGlsZQogLkZuIHNlbmR0bwogYW5kCiAuRm4gc2VuZG1zZwor YW5kCisuRm4gc2VuZG1tc2cKIG1heSBiZSB1c2VkIGF0IGFueSB0aW1lLgogLlBwCiBUaGUgYWRk cmVzcyBvZiB0aGUgdGFyZ2V0IGlzIGdpdmVuIGJ5CkBAIC04MSw2ICs4OSwxOCBAQCB1bmRlcmx5 aW5nIHByb3RvY29sLCB0aGUgZXJyb3IKIGlzIHJldHVybmVkLCBhbmQKIHRoZSBtZXNzYWdlIGlz IG5vdCB0cmFuc21pdHRlZC4KIC5QcAorVGhlCisuRm4gc2VuZG1tc2cKK2Z1bmN0aW9uIHNlbmRz IG11bHRpcGxlIG1lc3NhZ2VzIGF0IGEgY2FsbC4KK1RoZXkgYXJlIGdpdmVuIGJ5IHRoZQorLkZh IG1zZ3ZlYwordmVjdG9yIGFsb25nIHdpdGgKKy5GYSB2bGVuCitzcGVjaWZ5aW5nIGl0cyBzaXpl LgorVGhlIG51bWJlciBvZiBjaGFyYWN0ZXJzIHNlbnQgcGVyIGVhY2ggbWVzc2FnZSBpcyBwbGFj ZWQgaW4gdGhlCisuRmEgbXNnX2xlbgorZmllbGQgb2YgZWFjaCBlbGVtZW50IG9mIHRoZSB2ZWN0 b3IgYWZ0ZXIgdHJhbnNtaXNzaW9uLgorLlBwCiBObyBpbmRpY2F0aW9uIG9mIGZhaWx1cmUgdG8g ZGVsaXZlciBpcyBpbXBsaWNpdCBpbiBhCiAuRm4gc2VuZCAuCiBMb2NhbGx5IGRldGVjdGVkIGVy cm9ycyBhcmUgaW5kaWNhdGVkIGJ5IGEgcmV0dXJuIHZhbHVlIG9mIC0xLgpAQCAtMTM4LDEwICsx NTgsMTYgQEAgU2VlCiAuWHIgcmVjdiAyCiBmb3IgYSBkZXNjcmlwdGlvbiBvZiB0aGUKIC5GYSBt c2doZHIKK3N0cnVjdHVyZSBhbmQgdGhlCisuRmEgbW1zZ2hkcgogc3RydWN0dXJlLgogLlNoIFJF VFVSTiBWQUxVRVMKLVRoZSBjYWxsIHJldHVybnMgdGhlIG51bWJlciBvZiBjaGFyYWN0ZXJzIHNl bnQsIG9yIC0xCi1pZiBhbiBlcnJvciBvY2N1cnJlZC4KK0FsbCBjYWxscyBleGNlcHQKKy5GbiBz ZW5kbW1zZworcmV0dXJuIHRoZSBudW1iZXIgb2YgY2hhcmFjdGVycyBzZW50LiBUaGUKKy5GbiBz ZW5kbW1zZworY2FsbCByZXR1cm5zIHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgc2VudC4KK0lmIGFu IGVycm9yIG9jY3VycmVkIGEgdmFsdWUgb2YgLTEgaXMgcmV0dXJuZWQuCiAuU2ggRVJST1JTCiBU aGUKIC5GbiBzZW5kCkBAIC0xNDksNiArMTc1LDggQEAgZnVuY3Rpb24gYW5kCiAuRm4gc2VuZHRv CiBhbmQKIC5GbiBzZW5kbXNnCithbmQKKy5GbiBzZW5kbW1zZwogc3lzdGVtIGNhbGxzCiBmYWls IGlmOgogLkJsIC10YWcgLXdpZHRoIEVyCmRpZmYgLS1naXQgYS9zeXMvc3lzL3NvY2tldC5oIGIv c3lzL3N5cy9zb2NrZXQuaAppbmRleCAxOGUyZGUxLi5jN2EyMWNjIDEwMDY0NAotLS0gYS9zeXMv c3lzL3NvY2tldC5oCisrKyBiL3N5cy9zeXMvc29ja2V0LmgKQEAgLTQzMSw2ICs0MzEsOSBAQCBz dHJ1Y3QgbXNnaGRyIHsKICNkZWZpbmUJTVNHX05CSU8JMHg0MDAwCQkvKiBGSU9OQklPIG1vZGUs IHVzZWQgYnkgZmlmb2ZzICovCiAjZGVmaW5lCU1TR19DT01QQVQgICAgICAweDgwMDAJCS8qIHVz ZWQgaW4gc2VuZGl0KCkgKi8KICNkZWZpbmUJTVNHX0NNU0dfQ0xPRVhFQyAweDQwMDAwCS8qIG1h a2UgcmVjZWl2ZWQgZmRzIGNsb3NlLW9uLWV4ZWMgKi8KKyNpZm5kZWYgX0tFUk5FTAorI2RlZmlu ZSBNU0dfV0FJVEZPUk9ORQkweDgwMDAwCQkvKiBmb3IgcmVjdm1tc2coKSAqLworI2VuZGlmIC8q ICFfS0VSTkVMICovCiAjZW5kaWYKICNpZmRlZiBfS0VSTkVMCiAjZGVmaW5lCU1TR19TT0NBTExC Q0sgICAweDEwMDAwCQkvKiBmb3IgdXNlIGJ5IHNvY2tldCBjYWxsYmFja3MgLSBzb3JlY2VpdmUg KFRDUCkgKi8KQEAgLTU5NSw2ICs1OTgsMTggQEAgc3RydWN0IHNmX2hkdHIgewogI2VuZGlmIC8q IF9LRVJORUwgKi8KICNlbmRpZiAvKiBfX0JTRF9WSVNJQkxFICovCiAKKyNpZm5kZWYgX0tFUk5F TAorI2lmZGVmIF9fQlNEX1ZJU0lCTEUKKy8qCisgKiBTZW5kL3JlY3ZtbXNnIHNwZWNpZmljIHN0 cnVjdHVyZShzKQorICovCitzdHJ1Y3QgbW1zZ2hkciB7CisJc3RydWN0IG1zZ2hkcgltc2dfaGRy OwkJLyogbWVzc2FnZSBoZWFkZXIgKi8KKwlzc2l6ZV90CQltc2dfbGVuOwkJLyogbWVzc2FnZSBs ZW5ndGggKi8KK307CisjZW5kaWYgLyogX19CU0RfVklTSUJMRSAqLworI2VuZGlmIC8qICFfS0VS TkVMICovCisKICNpZm5kZWYJX0tFUk5FTAogCiAjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CkBAIC02 MTUsMTEgKzYzMCwxOSBAQCBpbnQJbGlzdGVuKGludCwgaW50KTsKIHNzaXplX3QJcmVjdihpbnQs IHZvaWQgKiwgc2l6ZV90LCBpbnQpOwogc3NpemVfdAlyZWN2ZnJvbShpbnQsIHZvaWQgKiwgc2l6 ZV90LCBpbnQsIHN0cnVjdCBzb2NrYWRkciAqIF9fcmVzdHJpY3QsIHNvY2tsZW5fdCAqIF9fcmVz dHJpY3QpOwogc3NpemVfdAlyZWN2bXNnKGludCwgc3RydWN0IG1zZ2hkciAqLCBpbnQpOworI2lm IF9fQlNEX1ZJU0lCTEUKK3N0cnVjdCB0aW1lc3BlYzsKK3NzaXplX3QJcmVjdm1tc2coaW50LCBz dHJ1Y3QgbW1zZ2hkciAqIF9fcmVzdHJpY3QsIHNpemVfdCwgaW50LAorICAgIGNvbnN0IHN0cnVj dCB0aW1lc3BlYyAqIF9fcmVzdHJpY3QpOworI2VuZGlmCiBzc2l6ZV90CXNlbmQoaW50LCBjb25z dCB2b2lkICosIHNpemVfdCwgaW50KTsKIHNzaXplX3QJc2VuZHRvKGludCwgY29uc3Qgdm9pZCAq LAogCSAgICBzaXplX3QsIGludCwgY29uc3Qgc3RydWN0IHNvY2thZGRyICosIHNvY2tsZW5fdCk7 CiBzc2l6ZV90CXNlbmRtc2coaW50LCBjb25zdCBzdHJ1Y3QgbXNnaGRyICosIGludCk7CiAjaWYg X19CU0RfVklTSUJMRQorc3NpemVfdAlzZW5kbW1zZyhpbnQsIHN0cnVjdCBtbXNnaGRyICogX19y ZXN0cmljdCwgc2l6ZV90LCBpbnQpOworI2VuZGlmCisjaWYgX19CU0RfVklTSUJMRQogaW50CXNl bmRmaWxlKGludCwgaW50LCBvZmZfdCwgc2l6ZV90LCBzdHJ1Y3Qgc2ZfaGR0ciAqLCBvZmZfdCAq LCBpbnQpOwogaW50CXNldGZpYihpbnQpOwogI2VuZGlmCg== --047d7bfcf874b8bfce052a251a15-- From owner-freebsd-threads@freebsd.org Mon Jan 25 12:00:58 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86469A459C6 for ; Mon, 25 Jan 2016 12:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6815D8FE for ; Mon, 25 Jan 2016 12:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0PC0wYo090531 for ; Mon, 25 Jan 2016 12:00:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Mon, 25 Jan 2016 12:00:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 12:00:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #6 from rblayzor@inoc.net --- GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `dovecot'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/dovecot/libdovecot.so.0...done. Loaded symbols for /usr/local/lib/dovecot/libdovecot.so.0 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000000000040db76 in service_process_create (service=3DCannot access m= emory at address 0x7fffffffb0c0 ) at service-process.c:313 313 service-process.c: No such file or directory. in service-process.c (gdb) bt full #0 0x000000000040db76 in service_process_create (service=3DCannot access m= emory at address 0x7fffffffb0c0 ) at service-process.c:313 uid_counter =3D 73470 process =3D (struct service_process *) Cannot access memory at addr= ess 0x7fffffffb0b8 Current language: auto; currently minimal (gdb) x/i $rip 0x40db76 : mov %eax,0x20(%rcx) (gdb) info registers rax 0x11efe 73470 rbx 0x0 0 rcx 0x8014b1040 34381434944 rdx 0x0 0 rsi 0x40d5e0 4249056 rdi 0x0 0 rbp 0x7fffffffb0d0 0x7fffffffb0d0 rsp 0x7fffffffb090 0x7fffffffb090 r8 0x2 2 r9 0x3 3 r10 0x2710 10000 r11 0x202 514 r12 0x7fffffffb328 140737488335656 r13 0x7fffffffb350 140737488335696 r14 0x7fffffffb330 140737488335664 r15 0x3 3 rip 0x40db76 0x40db76 eflags 0x10202 66050 cs 0x43 67 ss 0x3b 59 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Mon Jan 25 12:06:14 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49176A45E37 for ; Mon, 25 Jan 2016 12:06:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22211D76 for ; Mon, 25 Jan 2016 12:06:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0PC6E5P093393 for ; Mon, 25 Jan 2016 12:06:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Mon, 25 Jan 2016 12:06:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 12:06:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #7 from rblayzor@inoc.net --- GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `dovecot'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/dovecot/libdovecot.so.0...done. Loaded symbols for /usr/local/lib/dovecot/libdovecot.so.0 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000008006226bc in _rtld_is_dlopened () from /libexec/ld-elf.so.1 (gdb) x/i $rip 0x8006226bc <_rtld_is_dlopened+15468>: mov %edi,0x213236(%rip) # 0x8008358f8 <_rtld_atfork_post+2174= 936> (gdb) info registers rax 0x0 0 rbx 0x800835b50 34368346960 rcx 0x8014b1310 34381435664 rdx 0x8014b13d0 34381435856 rsi 0x7fffffffaf08 140737488334600 rdi 0x1 1 rbp 0x7fffffffaed0 0x7fffffffaed0 rsp 0x7fffffffaed0 0x7fffffffaed0 r8 0x103 259 r9 0x8080808080808080 -9187201950435737472 r10 0x1 1 r11 0x801406e30 34380738096 r12 0x7fffffffb328 140737488335656 r13 0x7fffffffb350 140737488335696 r14 0x7fffffffaf08 140737488334600 r15 0x800834850 34368342096 rip 0x8006226bc 0x8006226bc <_rtld_is_dlopened+15468> eflags 0x10202 66050 cs 0x43 67 ss 0x3b 59 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Mon Jan 25 12:09:49 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7EFFA45F1C for ; Mon, 25 Jan 2016 12:09:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 991D2E15 for ; Mon, 25 Jan 2016 12:09:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0PC9nZh006537 for ; Mon, 25 Jan 2016 12:09:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Mon, 25 Jan 2016 12:09:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 12:09:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #8 from rblayzor@inoc.net --- If it makes any difference at all, these are "diskless" booted VM servers w= ith read-only mounted NFS_ROOT. The only sysctl knobs turned are below. This is still happening even after a fresh build of 10.2-p10 kern.corefile=3D/var/spool/tmp/%N.core kern.timecounter.hardware=3DACPI-fast kern.ipc.maxsockbuf=3D2097152 kern.ipc.somaxconn=3D2048 kern.maxfiles=3D65536 kern.maxfilesperproc=3D16384 net.inet.tcp.sendspace=3D131072 net.inet.tcp.recvspace=3D131072 net.inet.udp.recvspace=3D131072 net.inet.udp.maxdgram=3D16384 net.inet.tcp.msl=3D7500 net.inet.tcp.fast_finwait2_recycle=3D1 net.inet.icmp.log_redirect=3D0 net.inet.icmp.drop_redirect=3D1 net.inet.tcp.delayed_ack=3D0 net.inet.ip.redirect=3D0 net.inet6.ip6.redirect=3D0 net.link.ether.inet.log_arp_wrong_iface=3D0 kern.sugid_coredump=3D1 net.inet.tcp.keepidle=3D60000 net.inet.tcp.keepintvl=3D10000 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Tue Jan 26 12:52:05 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65F0DA6E831 for ; Tue, 26 Jan 2016 12:52:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56248E88 for ; Tue, 26 Jan 2016 12:52:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0QCq5Dm071158 for ; Tue, 26 Jan 2016 12:52:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Tue, 26 Jan 2016 12:52:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 12:52:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #9 from rblayzor@inoc.net --- And a recent Exim crash under 10.2 as well..=20 Core was generated by `exim'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...do= ne. Loaded symbols for /lib/libcrypt.so.5 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...don= e. Loaded symbols for /lib/libutil.so.9 Reading symbols from /usr/local/lib/libspf2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libspf2.so.2 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /usr/local/lib/libpq.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpq.so.5 Reading symbols from /usr/local/lib/perl5/5.22/mach/CORE/libperl.so.5.22...= (no debugging symbols found)...done. Loaded symbols for /usr/local/lib/perl5/5.22/mach/CORE/libperl.so.5.22 Reading symbols from /usr/lib/libssl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.7 Reading symbols from /lib/libcrypto.so.7...(no debugging symbols found)...d= one. Loaded symbols for /lib/libcrypto.so.7 Reading symbols from /usr/local/lib/libpcre.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpcre.so.1 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libintl.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000000080119e4b6 in pthread_suspend_all_np () from /lib/libthr.so.3 [New Thread 803006400 (LWP 100084/)] (gdb) bt full #0 0x000000080119e4b6 in pthread_suspend_all_np () from /lib/libthr.so.3 No symbol table info available. #1 0x00000008011a126a in pthread_getspecific () from /lib/libthr.so.3 No symbol table info available. #2 0x00000008011a5c96 in __pthread_cxa_finalize () from /lib/libthr.so.3 No symbol table info available. #3 0x0000000000423536 in daemon_go () No symbol table info available. #4 0x0000000000438ee9 in main () No symbol table info available. (gdb) x/i $rip 0x80119e4b6 : lock cmpxchg %ecx,(%rdi) (gdb) info registers rax 0x1 1 rbx 0x0 0 rcx 0x0 0 rdx 0x1 1 rsi 0x8011a833c 34378253116 rdi 0x8013b4480 34380399744 rbp 0x7fffffffd440 0x7fffffffd440 rsp 0x7fffffffd440 0x7fffffffd440 r8 0x2 2 r9 0x3 3 r10 0x2710 10000 r11 0x246 582 r12 0x803006400 34410095616 r13 0x709b50 7379792 r14 0x8013b4460 34380399712 r15 0x0 0 rip 0x80119e4b6 0x80119e4b6 eflags 0x10246 66118 cs 0x43 67 ss 0x3b 59 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Tue Jan 26 13:40:12 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77F83A46CC4 for ; Tue, 26 Jan 2016 13:40:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5E295116B for ; Tue, 26 Jan 2016 13:40:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5C439A46CC2; Tue, 26 Jan 2016 13:40:12 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A80DA46CC0; Tue, 26 Jan 2016 13:40:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAB131169; Tue, 26 Jan 2016 13:40:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0QDe65E082213 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Jan 2016 15:40:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0QDe65E082213 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0QDe5Y8082210; Tue, 26 Jan 2016 15:40:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 26 Jan 2016 15:40:05 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: gljennjohn@gmail.com, threads@freebsd.org, Bruce Evans , net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160126134005.GD3942@kib.kiev.ua> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 13:40:12 -0000 On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: > +ssize_t > +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, > + const struct timespec *__restrict timeout) > +{ > + size_t i, rcvd; > + ssize_t ret; > + > + if (timeout != NULL) { > + fd_set fds; > + int res; Please move all local definitions to the beginning of the function. > + > + FD_ZERO(&fds); > + FD_SET(s, &fds); > + res = __sys_pselect(s + 1, &fds, NULL, NULL, timeout, NULL); So why is this __sys_pselect() and not pselect() ? Note that ppoll() is immune to the issue of s > FD_SETSIZE. > + if (res == -1 || res == 0) > + return (res); > + if (!FD_ISSET(s, &fds)) > + return (-1); > + } > + > + ret = __sys_recvmsg(s, &msgvec[0].msg_hdr, flags); > + if (ret == -1) > + return (ret); > + > + /* Check initially for the presence of MSG_WAITFORONE. > + * Turn on MSG_DONTWAIT if set. */ The style-conformant multi-line comment is /* * Text. * More text. */ > + if (flags & MSG_WAITFORONE) { > + flags |= MSG_DONTWAIT; > + /* The kernel doesn't need to know about this flag. */ > + flags &= ~MSG_WAITFORONE; You clear MSG_WAITFORONE flag in the calls to recvmsg(), but not at the first recvmsg() incantation. I think the flag should be just kept alone. > + } > + > + rcvd = 1; > + for (i = rcvd; i < vlen; i++, rcvd++) { > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > + if (ret == -1) { > + /* We have received messages. Let caller know. */ > + return (rcvd); > + } > + > + /* Save received bytes */ > + msgvec[i].msg_len = ret; > + } > + > + return (rcvd); > +} > diff --git a/sys/sys/socket.h b/sys/sys/socket.h > index 18e2de1..c7a21cc 100644 > --- a/sys/sys/socket.h > +++ b/sys/sys/socket.h > @@ -431,6 +431,9 @@ struct msghdr { > #define MSG_NBIO 0x4000 /* FIONBIO mode, used by fifofs */ > #define MSG_COMPAT 0x8000 /* used in sendit() */ > #define MSG_CMSG_CLOEXEC 0x40000 /* make received fds close-on-exec */ > +#ifndef _KERNEL Why is the !KERNEL protection for the definition needed ? > +#define MSG_WAITFORONE 0x80000 /* for recvmmsg() */ > +#endif /* !_KERNEL */ > #endif > #ifdef _KERNEL > #define MSG_SOCALLBCK 0x10000 /* for use by socket callbacks - soreceive (TCP) */ > @@ -595,6 +598,18 @@ struct sf_hdtr { > #endif /* _KERNEL */ > #endif /* __BSD_VISIBLE */ > > +#ifndef _KERNEL Why is the !KERNEL protection for the definition needed ? > +#ifdef __BSD_VISIBLE > +/* > + * Send/recvmmsg specific structure(s) > + */ > +struct mmsghdr { > + struct msghdr msg_hdr; /* message header */ > + ssize_t msg_len; /* message length */ > +}; > +#endif /* __BSD_VISIBLE */ > +#endif /* !_KERNEL */ > + > #ifndef _KERNEL > > #include > @@ -615,11 +630,19 @@ int listen(int, int); > ssize_t recv(int, void *, size_t, int); > ssize_t recvfrom(int, void *, size_t, int, struct sockaddr * __restrict, socklen_t * __restrict); > ssize_t recvmsg(int, struct msghdr *, int); > +#if __BSD_VISIBLE > +struct timespec; > +ssize_t recvmmsg(int, struct mmsghdr * __restrict, size_t, int, > + const struct timespec * __restrict); > +#endif > ssize_t send(int, const void *, size_t, int); > ssize_t sendto(int, const void *, > size_t, int, const struct sockaddr *, socklen_t); > ssize_t sendmsg(int, const struct msghdr *, int); > #if __BSD_VISIBLE > +ssize_t sendmmsg(int, struct mmsghdr * __restrict, size_t, int); > +#endif > +#if __BSD_VISIBLE Again, there is no use in closing __BSD_VISIBLE block only to open it again on the next line. > int sendfile(int, int, off_t, size_t, struct sf_hdtr *, off_t *, int); > int setfib(int); > #endif From owner-freebsd-threads@freebsd.org Tue Jan 26 17:06:42 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B04AA46285 for ; Tue, 26 Jan 2016 17:06:42 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2A13EE4C for ; Tue, 26 Jan 2016 17:06:42 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 24899A46282; Tue, 26 Jan 2016 17:06:42 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09EEDA4627F; Tue, 26 Jan 2016 17:06:42 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 836B8E4A; Tue, 26 Jan 2016 17:06:41 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22e.google.com with SMTP id 17so109370043lfz.1; Tue, 26 Jan 2016 09:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=T7mn27yqF1atfSp+7ckzRpZa1zBwI1gOyutZKeWlmxM=; b=q2EMl8waQS58+2uOklBQUv/pPLsmiv/ND6egaeORCqxZpWDgI4FzI62D3SlNh3l/Jy JVNrfq2KloZ4McIOAG7JzD+SMsEjwO79rA8BtErUlrfvSjkOdpcxVuDLUZYpxzNwlvZ1 MfEvZadIiO1BKzPvJdqD0QKuZIcMm3ovPARY/0lxJvc1avhoxIpYqx6rKpm32eMHKfMb gB/2CHzp8dJlQ5ZwU+K+KPLx7koipm2pFFDBgvpLPHhYMfumE+n46WZTMP98cEF03Q5P GRVNLOF9/wCtWM/1QrDHccVA5BWZ1jvhOUx0tDQaIj6buUTrviY7k+L8EkJW4mO/dewc mPYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T7mn27yqF1atfSp+7ckzRpZa1zBwI1gOyutZKeWlmxM=; b=kUonTYDVpi5CYCSRd9osfXX7rXbCcPoYxykrTf1Fn6o/AvmU7IaMHltKtLr/q5cVjG 72MJ6AUt+z1N/+XXFsq0oblr3SfTydqNV4LaJ2J8WgQ8TvJaySovtwjNYmynL7HgTvoZ tIQqYvA8cnJkSW6RmGegbtT8cegi/b36vbRd76wpz3LxNhxSRq7mreNLEub002nliJi1 rX+2qsAp7+KWeSVGecE1J/ID/OOAZX3VfWvjI5BipoJh1kYLPIQSM1bxOSJC1zLixitq XlcjyvkR6uG+doPWUkSw+KT8uGKLtu+wZzw/jpMOij5j7lhavg0DYTn7hiAhsXnLiz/s 0DtA== X-Gm-Message-State: AG10YOQswa6q9quMRmrPqqWENeML38KIKViD2gR/0R+wYLFBwZgeYevcDGJ0l3vJbw3AI7sEvRYaZZMFqJ4ngQ== MIME-Version: 1.0 X-Received: by 10.25.209.138 with SMTP id i132mr9091992lfg.4.1453827999702; Tue, 26 Jan 2016 09:06:39 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Tue, 26 Jan 2016 09:06:39 -0800 (PST) In-Reply-To: <20160126134005.GD3942@kib.kiev.ua> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> Date: Tue, 26 Jan 2016 09:06:39 -0800 X-Google-Sender-Auth: Sd4U1kUTBPHiWaXKnzx4nXOeCtk Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: Konstantin Belousov Cc: Boris Astardzhiev , threads@freebsd.org, gljennjohn@gmail.com, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:06:42 -0000 On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov wrote: > On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >> +ssize_t >> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >> + const struct timespec *__restrict timeout) >> +{ >> + size_t i, rcvd; >> + ssize_t ret; >> + >> + if (timeout != NULL) { >> + fd_set fds; >> + int res; > Please move all local definitions to the beginning of the function. This style recommendation was from 30 years ago and is bad programming practice, as it tends to complicate analysis for the human and increase the chance of improper usage of variables. We should move away from this for new code. cheers luigi From owner-freebsd-threads@freebsd.org Tue Jan 26 17:25:49 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BAFCA46DA6 for ; Tue, 26 Jan 2016 17:25:49 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 274E21ACD for ; Tue, 26 Jan 2016 17:25:49 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2434FA46DA4; Tue, 26 Jan 2016 17:25:49 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 098C7A46DA1; Tue, 26 Jan 2016 17:25:49 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91D251AC6; Tue, 26 Jan 2016 17:25:48 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id b14so142511573wmb.1; Tue, 26 Jan 2016 09:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=8XIw2Nll9Ro6yeMO3HrnJVLdR/wuR5XxJEjlFlClc0I=; b=oi+IQZr3W9GlbszJVZ7+MX8Wsz5ZtU5FiMtZxDfhioTKqG8p3lWmwQz/ra5UFx7aT7 DucMBem1qSODsde0nZ8vjUEKJ6c/kLyLbjpL7AbOPTodWXFPR3JIFUKdaqwQHQt4Jdvw rdtwG6BrfgsPh7XzWGmZ0qt0LkXvxSFwggswbK1uKMjQgtIlSCLDLFmQruU0Zw8sYOOz K6LuLakCwL7o8tlNzclYZayYxO2c+XVr2KotUh5QYwKZZGWH2U36wcvLb3NL/4GqdJNt UBxbLmGvj2hixVQ4xKfeFtcTxNpPyAYKJ5uEMPA/N/96Jlj63UiRAXIVaIzxYqiAU6KG BAVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-type :content-transfer-encoding; bh=8XIw2Nll9Ro6yeMO3HrnJVLdR/wuR5XxJEjlFlClc0I=; b=P4JQNnYgPCBnBnoxdWcDP+UADVwspUkDCLiYwapdWxKKpxOERHtuwHwzIY1Jintpva CMKNMlyPhSCeWRL67c8dJdjsG3uyQO5+vXVxTQRXRBImXz7QvZDTW3xwU3Fg1zQGbmdC xj+Afrwn3IVUPdSaq7MzGC8O51yji69JdidzL2aD63H2io3bqq8E2i9aIVZQozTLLtsg xX8hUgJ9ogxiGYvHOR0zse8WRWwnS/Kt1z303irZoYkDZXHeFeZ7FClGAE1XDg4ZiaKf U7PdopkXPPPganVMvenG7Zd5Qw9rTPHRUkIfV4wSYElYQWKVq8KL3ZTjPpwfo1KlPSaJ oRKg== X-Gm-Message-State: AG10YOTDDKZQ57UzBXs+OvpBkLcQHUcgeehm2xqxkFn1JMxEvdkjTywpRrp/w72gBNaTZg== X-Received: by 10.194.95.34 with SMTP id dh2mr23779246wjb.63.1453829147025; Tue, 26 Jan 2016 09:25:47 -0800 (PST) Received: from ernst.home (p4FCA7371.dip0.t-ipconnect.de. [79.202.115.113]) by smtp.gmail.com with ESMTPSA id js8sm2351923wjc.37.2016.01.26.09.25.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jan 2016 09:25:45 -0800 (PST) Date: Tue, 26 Jan 2016 18:25:43 +0100 From: Gary Jennejohn To: Luigi Rizzo Cc: Konstantin Belousov , Boris Astardzhiev , threads@freebsd.org, "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160126182543.64050678@ernst.home> In-Reply-To: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:25:49 -0000 On Tue, 26 Jan 2016 09:06:39 -0800 Luigi Rizzo wrote: > On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov > wrote: > > On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: > >> +ssize_t > >> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, > >> + const struct timespec *__restrict timeout) > >> +{ > >> + size_t i, rcvd; > >> + ssize_t ret; > >> + > >> + if (timeout != NULL) { > >> + fd_set fds; > >> + int res; > > Please move all local definitions to the beginning of the function. > > This style recommendation was from 30 years ago and is > bad programming practice, as it tends to complicate analysis > for the human and increase the chance of improper usage of > variables. > > We should move away from this for new code. > Really? I personally find having all variables grouped together much easier to understand. Stumbling across declarations in the middle of the code in a for-loop, for example, takes me by surprise. I also greatly dislike initializing variables in their declarations. Maybe I'm just old fashioned since I have been writing C-code for more than 30 years. -- Gary Jennejohn From owner-freebsd-threads@freebsd.org Tue Jan 26 18:14:26 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 966B1A46089 for ; Tue, 26 Jan 2016 18:14:26 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7415915F4 for ; Tue, 26 Jan 2016 18:14:26 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 70F20A46084; Tue, 26 Jan 2016 18:14:26 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70606A46083; Tue, 26 Jan 2016 18:14:26 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9D2E15F3; Tue, 26 Jan 2016 18:14:25 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id h129so111622398lfh.3; Tue, 26 Jan 2016 10:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hTvcC4x4nkGZQkTbFcNmtsBXR1OfB93MFgFMljHxXKU=; b=t3iYSgh47O+EvP8w7zQrJFwm9b1vHBgUA4BEBjezASflmuVSJI6gBd275zmwVThcoj KhZN7Z2xnnTtdTMG79cH4A6IDGfdpfCm9FxZpr3ZdYUIX0HTlSrEXp8+zFwugK32p545 hOylvtpuHa5aXw50JzGiDoDjATmbjWD/OVUjW0XukSAO+4kAuotFlvSOxEAhHD8eda2d JigciaZfEWTt+bAMB6oAGINUF7rUsfBlNT7/o/5QQ6fulH3YnOUd64SP2+q62SQVL/SJ 36Y3y8l1A8kCbOTQOwGXA1p0dfqnZs7Gkdt+zviQiD6ACrbihcWMy8AMc7JIsIBp5w5o ydaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hTvcC4x4nkGZQkTbFcNmtsBXR1OfB93MFgFMljHxXKU=; b=jkshdC8l7KjNAJpK0ZyaA7Z4UmjipdpcteE4/2KC7wOU5GgoV4ErhwJfEva5jq8buB psP1ZAdBdBVOlF8izSsQ43ry7O7X/XENTNqKkdss3WxSEXIAP4cYfOcnRaKwJ3lRwWZz Nbv+03AgET9eUxv+MPkwS8a8IcC7puj9dilylo9onUqznerMOFTNL9B/3FRjQyQrJjLR kXCcWDEtqD9SWCUnPibXFbCRcffSmC7zimKh1n4pzZp8bGldYYgapKlepjf8IjDpzy/a tp/KRhWYHmm8GUxcr9OWvQ0X9T1vaLH4CNXTK2FL/+XLs0xa8D3bdxciOhnASNm3X7HY NiOw== X-Gm-Message-State: AG10YORxKQagliDE4PVmiFK/07dZohlRJ2egC10+fTO7SKAZgknBlZ3qTHekpuLF+lbMVizBd26xAnvOu3MPrg== MIME-Version: 1.0 X-Received: by 10.25.158.136 with SMTP id h130mr9138909lfe.136.1453832063990; Tue, 26 Jan 2016 10:14:23 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Tue, 26 Jan 2016 10:14:23 -0800 (PST) In-Reply-To: <20160126182543.64050678@ernst.home> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> Date: Tue, 26 Jan 2016 10:14:23 -0800 X-Google-Sender-Auth: TjSAZi3JKdgjk9-9NQ8aEuFCRPk Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: gljennjohn@gmail.com Cc: Konstantin Belousov , Boris Astardzhiev , threads@freebsd.org, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 18:14:26 -0000 On Tue, Jan 26, 2016 at 9:25 AM, Gary Jennejohn wrote: > On Tue, 26 Jan 2016 09:06:39 -0800 > Luigi Rizzo wrote: > >> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >> wrote: >> > On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >> >> +ssize_t >> >> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >> >> + const struct timespec *__restrict timeout) >> >> +{ >> >> + size_t i, rcvd; >> >> + ssize_t ret; >> >> + >> >> + if (timeout != NULL) { >> >> + fd_set fds; >> >> + int res; >> > Please move all local definitions to the beginning of the function. >> >> This style recommendation was from 30 years ago and is >> bad programming practice, as it tends to complicate analysis >> for the human and increase the chance of improper usage of >> variables. >> >> We should move away from this for new code. >> > > Really? I personally find having all variables grouped together > much easier to understand. Stumbling across declarations in the > middle of the code in a for-loop, for example, takes me by surprise. > > I also greatly dislike initializing variables in their declarations. > > Maybe I'm just old fashioned since I have been writing C-code for > more than 30 years. (sorry for the digression) I am in the same ballpark in terms of coding age, but systems have become a lot more complex in that time window, code size generally exploded, and compilers are smarter so they do not need hints from the programmer on when to do initializations, or stack reuse or register allocations. I find that reducing the scope of variables helps a lot understanding third party code (e.g. where information belongs to) and reduces the chance of misuse (such as, leaking information from the body of a loop). About initializers in declarations, I think the rule should be "use good judgement and privilege readability". E.g., do postpone initialization if the first use is 20 lines down, so that it is clear what the value is by the time you use the variable; or when there is some complex condition to check, as writing it as a conditional expression may be ugly and cause code duplication and lead to poor error handling. But when the first use is close to the declaration, splitting the initialization is just unnecessary source bloat. cheers luigi > > -- > Gary Jennejohn -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-threads@freebsd.org Tue Jan 26 18:40:52 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C178FA46BEC for ; Tue, 26 Jan 2016 18:40:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B29D5CC for ; Tue, 26 Jan 2016 18:40:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0QIeqD4089439 for ; Tue, 26 Jan 2016 18:40:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Tue, 26 Jan 2016 18:40:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 18:40:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #10 from John Baldwin --- So far I don't see anything unusual to suggest that these are anything other than crashes due to application bugs. Is this the exact same exim / dovecot binaries you were using on 10.1 or did you also recompile those against 10.2 (and/or upgrade to newer versions)? One thing that might help with debugging these is building the user librari= es with debug symbols. If you are building your own worlds, just add 'WITH_DEBUG_FILES=3Dyes' to /etc/src.conf and build a new world. Note that= this will install debug symbols for all binaries and libraries in the base syste= m to /usr/lib/debug/. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Tue Jan 26 18:51:59 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E580FA6E2C9 for ; Tue, 26 Jan 2016 18:51:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD84A9E4 for ; Tue, 26 Jan 2016 18:51:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0QIpxoF015042 for ; Tue, 26 Jan 2016 18:51:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Tue, 26 Jan 2016 18:51:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 18:52:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #11 from rblayzor@inoc.net --- Since we're using a FreeBSD diskless boot and NFS_ROOT I normally buildworld (and kernel) from sources and install in a new NFS_ROOT path, then boot the diskless servers with the new root path. Before booting however, I will also force rebuild (portupgrade -af) everyth= ing against the new version of FreeBSD (kernel/userland, libs, etc). So the binaries that are crashing *are* being rebuilt under FreeBSD 10.2. We never experienced this in 10.1 and in fact, we even rolled back and boot= ed one of the diskless servers using an old NFS_ROOT path with 10.1 (same vers= ions of Exim and Dovecot) and those have not crashed. Usually I will experience these types of seg faults on every VM server at least once a week. (current= ly these servers are lightly loaded because of this issue). Normally I would have no problem believing this is an application but since= it does not appear to happen on 10.1 and only on 10.2, coupled with the fact I= 'm seeing similar crashes on two different applications that were otherwise running fine is very suspect.=20 The applications are compiled with debugging symbols, but the crash always happens in a system library. I've contacted both Dovecot and Exim teams on these crashes and both agreed that it seemed to be some type of system libr= ary issue. I'm not ruling out that it may be something with our install, but it's fair= ly straight forward FreeBSD diskless install. Running out of places to look. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Tue Jan 26 19:56:57 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88BCDA46A3B for ; Tue, 26 Jan 2016 19:56:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79B9FA68 for ; Tue, 26 Jan 2016 19:56:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0QJuvYc071913 for ; Tue, 26 Jan 2016 19:56:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Tue, 26 Jan 2016 19:56:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 19:56:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #12 from John Baldwin --- Adding WITH_DEBUG_SYMBOLS so we get debugging symbols in the system librari= es would still be useful. Is it possible to grab the binaries from a 10.1 VM = and run them in a 10.2 VM (I realize that might be a bit hacky, but if it's feasible it might help narrow down what change is causing the regression)? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Tue Jan 26 20:06:52 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE7CEA46DDE for ; Tue, 26 Jan 2016 20:06:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF8AAF79 for ; Tue, 26 Jan 2016 20:06:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0QK6qwE012126 for ; Tue, 26 Jan 2016 20:06:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Tue, 26 Jan 2016 20:06:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 20:06:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #13 from rblayzor@inoc.net --- I am building world with DEBUG SYMBOLS now and will stage a new root and bo= ot a few VM's into that as well as make sure DEBUG symbols are compiled with both Exim and Dovecot. Once that's done hopefully we'll get a bit more out of the debugger. As for the binaries, that might be possible with Exim, but Dovecot has a sl= ew of associated libraries and other binary depends.=20 Lets start with the DEBUG symbols and see if it reveals more of whats going= on. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Tue Jan 26 21:36:27 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D42EA6FD2D for ; Tue, 26 Jan 2016 21:36:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F27261A67 for ; Tue, 26 Jan 2016 21:36:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0QLaQhQ062995 for ; Tue, 26 Jan 2016 21:36:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Tue, 26 Jan 2016 21:36:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: julian@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 21:36:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 Julian Elischer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julian@FreeBSD.org --- Comment #14 from Julian Elischer --- (In reply to rblayzor from comment #13) Don't forget you can run with a new kernel and old system to help isolate i= t, and also don't forget that you can replace libraries one at a time or in gr= oups using /etc/libmap.conf (man libmap.conf) so for example you can make all the system use the new libraries but just o= ne application use the old ones. or you can even make just one instance of the app use differnet libries by starting it from a different binary or giving a differnt path to it.. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Tue Jan 26 22:47:00 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AEE8A6E6B8 for ; Tue, 26 Jan 2016 22:47:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0FC4F19FE for ; Tue, 26 Jan 2016 22:47:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0ABD3A6E6B4; Tue, 26 Jan 2016 22:47:00 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09033A6E6B2; Tue, 26 Jan 2016 22:47:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4E6219FC; Tue, 26 Jan 2016 22:46:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u0QMkqI1036585; Tue, 26 Jan 2016 17:46:52 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 26 Jan 2016 17:46:52 -0500 (EST) Date: Tue, 26 Jan 2016 17:46:52 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Gary Jennejohn cc: Luigi Rizzo , threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <20160126182543.64050678@ernst.home> Message-ID: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 22:47:00 -0000 On Tue, 26 Jan 2016, Gary Jennejohn wrote: > On Tue, 26 Jan 2016 09:06:39 -0800 > Luigi Rizzo wrote: > >> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >> wrote: >>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>> +ssize_t >>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >>>> + const struct timespec *__restrict timeout) >>>> +{ >>>> + size_t i, rcvd; >>>> + ssize_t ret; >>>> + >>>> + if (timeout != NULL) { >>>> + fd_set fds; >>>> + int res; >>> Please move all local definitions to the beginning of the function. >> >> This style recommendation was from 30 years ago and is >> bad programming practice, as it tends to complicate analysis >> for the human and increase the chance of improper usage of >> variables. >> >> We should move away from this for new code. >> > > Really? I personally find having all variables grouped together > much easier to understand. Stumbling across declarations in the > middle of the code in a for-loop, for example, takes me by surprise. > > I also greatly dislike initializing variables in their declarations. > > Maybe I'm just old fashioned since I have been writing C-code for > more than 30 years. +1 Probably should be discouraged, but allowed on a case-by-case basis. One could argue that if you need to declaration blocks in the middle of code, then that code is too complex and should be broken out into a separate function. -- DE From owner-freebsd-threads@freebsd.org Wed Jan 27 00:31:50 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9049EA46E5E for ; Wed, 27 Jan 2016 00:31:50 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0D28C6 for ; Wed, 27 Jan 2016 00:31:50 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 67F84A46E5A; Wed, 27 Jan 2016 00:31:50 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67249A46E58; Wed, 27 Jan 2016 00:31:50 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFA138C0; Wed, 27 Jan 2016 00:31:49 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id 123so128782531wmz.0; Tue, 26 Jan 2016 16:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=ZzH014obF/8i1r5IKZEJSesGYA6PlJd3h/jxXXAQRiE=; b=VgTQT4mGpKcuOX57pIdt8lTRUM0oqfjAUztGFqTuFtGi80I3S08Gn2VjeBeprn6ZLG SMNeVMaQRb3+kmV1I4tx/Csm7WiOW0l4yWz3ZXAU0oRMh2JjC61sxuCsref/SooY9Oed qsZkiM/IP6gXdHO1KXo/JtjRUgjL/aolkFO9lZEIWu23puhW+WxVyEgUQdRnQ8ey7HNL vSn2mqnEIvzpS1nG5hgpTY7r/tSbABdHyVPZOrVTB9uhawa9h1I7P4l/YSumVAJY34IX yqFD71jHtOsfn1qY9O68dWuuCN6h+fg5EySgIgmdE6GSw1vzEkkEjcc2QPV7Of3DJ06V aWPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-type :content-transfer-encoding; bh=ZzH014obF/8i1r5IKZEJSesGYA6PlJd3h/jxXXAQRiE=; b=SMDL9iWAH5fe4lVjzRYxdctdSU+6bwHEYXAQlp8XJtlhskiApuuNpkeNtxrwgomB65 OKpeNITA16+FthKn919sfPdUYnDfgH6TeJb59C9GtCG45bmCRsPChxegj1YvTgYz9OcI IjbO9yw/IC8uZwBTXLKcLc5rdGs7Mp1bt82sfsRPZIeJwQ5ZtrweDn8F794dtlTL/B+R kX171V0qXcCV4wFNGTEpOdjew9I6NyLrsvg+XUL8hchiSILSGBZIWuPRxtCmjHjGNzNd oIZVTbrcgm/tzzRiFS7lO2EkD+LpX2wQwOkcl8pZbjYey7bNYDKO9eCVXVtjKaHulOL/ Qrhw== X-Gm-Message-State: AG10YOQTPiuXvZqBwx88dLE6GzGCttmExaEjTbKrqjxoegzyE8vauDzFu+azEyovnjDnmw== X-Received: by 10.28.212.9 with SMTP id l9mr28452579wmg.75.1453854708534; Tue, 26 Jan 2016 16:31:48 -0800 (PST) Received: from ernst.home (p4FCA7371.dip0.t-ipconnect.de. [79.202.115.113]) by smtp.gmail.com with ESMTPSA id e198sm5129102wmd.0.2016.01.26.16.31.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jan 2016 16:31:47 -0800 (PST) Date: Wed, 27 Jan 2016 01:31:45 +0100 From: Gary Jennejohn To: Daniel Eischen Cc: Luigi Rizzo , threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160127013145.36f2aaef@ernst.home> In-Reply-To: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 00:31:50 -0000 On Tue, 26 Jan 2016 17:46:52 -0500 (EST) Daniel Eischen wrote: > On Tue, 26 Jan 2016, Gary Jennejohn wrote: > > > On Tue, 26 Jan 2016 09:06:39 -0800 > > Luigi Rizzo wrote: > > > >> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov > >> wrote: > >>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: > >>>> +ssize_t > >>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, > >>>> + const struct timespec *__restrict timeout) > >>>> +{ > >>>> + size_t i, rcvd; > >>>> + ssize_t ret; > >>>> + > >>>> + if (timeout != NULL) { > >>>> + fd_set fds; > >>>> + int res; > >>> Please move all local definitions to the beginning of the function. > >> > >> This style recommendation was from 30 years ago and is > >> bad programming practice, as it tends to complicate analysis > >> for the human and increase the chance of improper usage of > >> variables. > >> > >> We should move away from this for new code. > >> > > > > Really? I personally find having all variables grouped together > > much easier to understand. Stumbling across declarations in the > > middle of the code in a for-loop, for example, takes me by surprise. > > > > I also greatly dislike initializing variables in their declarations. > > > > Maybe I'm just old fashioned since I have been writing C-code for > > more than 30 years. > > +1 > > Probably should be discouraged, but allowed on a case-by-case > basis. One could argue that if you need to declaration blocks > in the middle of code, then that code is too complex and should > be broken out into a separate function. > Right. And code like this int func(void) { int baz, zot; [some more code] if (zot < 5) { int baz = 3; [more code] } [some more code] } is even worse. The compiler (clang) seems to consider this to merely be a reinitialization of baz, but a human might be confused. Something like for (int i = 0; i < 2; i++) is IMHO OK. -- Gary Jennejohn From owner-freebsd-threads@freebsd.org Wed Jan 27 00:39:04 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B631A6E456 for ; Wed, 27 Jan 2016 00:39:04 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 697CCC4F for ; Wed, 27 Jan 2016 00:39:04 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 673FCA6E454; Wed, 27 Jan 2016 00:39:04 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66B94A6E453; Wed, 27 Jan 2016 00:39:04 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF80FC4E; Wed, 27 Jan 2016 00:39:03 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id c192so116460603lfe.2; Tue, 26 Jan 2016 16:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=unqjzdiAU3Lsv07QAgQ5QKIqrqRb1aw8ueSz/wDpd84=; b=ondHbLGcP9dPXaJymV9/irHTjUER4wXCO4PKmemxXpWVqQavwS8TA23QY5ynOKliKf U4wy5VXO21h29dAREHqIzbzIj6GuU9DwM3ioLlzB+womDG7OOk8bKIR4mVdTdTtV41dW Mi5Pd/MnWH2OyQ/iGQw/HIGqvZDiuO0V63E/CQo1fO1oPF+M8jTCISxhTEMXyZZD0mmY XdHXErZoTBFTaPvzCiHmz0DsbP73n8gHRjGTxys6HBGyEJgTfi7avlebZI/PpUH6hSR1 cedSP1qu2sTD1T8v0jv0KL3iAM2XH7C7PQ8JicyaxAlC4EF2S1il54TV9hzXPOOc7DQa sd7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=unqjzdiAU3Lsv07QAgQ5QKIqrqRb1aw8ueSz/wDpd84=; b=kzAbwNsfTUB1l+SaHz/qVQebP1oyhYoWzlA80EUFpLuO8qKnRyuedNe1JXN4dFIFws TunWn6Q+LRNAOY/C25VRs6TA1tuc8ojeYqd6/iYV/MMpLQs0xR54iNqzq7qRwYDaPyp+ cm/vs/BJYFUGRr34i+nioXDFrGlSgmtLWJFZoBZlaDLpzA9aiTsC81SS45G9FNknFyMz V8M3SuKwS/vU4w4PkwUoCxI+ttiX5Fqz4i+xBHJ1q+lQTmTwSxj0iiOfsOGZ/5CAWPJQ BEy8UQ000s/k7eAPSJkhU5Z16RT+gHV+lO7vZaVdKMr2bZTc2aXfnJae2Wao14O6bUJ8 +CaQ== X-Gm-Message-State: AG10YOTuYBVZKRfYZzatbxIM+RP2K9kJjX7OkkcihNK3N8ZnrmhAB9+yZIIYrdOzvIkkHr24AUrMAw3ikJXTZQ== MIME-Version: 1.0 X-Received: by 10.25.21.208 with SMTP id 77mr9813445lfv.96.1453855140698; Tue, 26 Jan 2016 16:39:00 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Tue, 26 Jan 2016 16:39:00 -0800 (PST) In-Reply-To: <20160127013145.36f2aaef@ernst.home> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> Date: Tue, 26 Jan 2016 16:39:00 -0800 X-Google-Sender-Auth: k4LwQVdu9Ah7Qo0jNU6CBodhdSw Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: gljennjohn@gmail.com Cc: Daniel Eischen , threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 00:39:04 -0000 On Tue, Jan 26, 2016 at 4:31 PM, Gary Jennejohn wrote: > On Tue, 26 Jan 2016 17:46:52 -0500 (EST) > Daniel Eischen wrote: > >> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >> >> > On Tue, 26 Jan 2016 09:06:39 -0800 >> > Luigi Rizzo wrote: >> > >> >> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >> >> wrote: >> >>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >> >>>> +ssize_t >> >>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >> >>>> + const struct timespec *__restrict timeout) >> >>>> +{ >> >>>> + size_t i, rcvd; >> >>>> + ssize_t ret; >> >>>> + >> >>>> + if (timeout != NULL) { >> >>>> + fd_set fds; >> >>>> + int res; >> >>> Please move all local definitions to the beginning of the function. >> >> >> >> This style recommendation was from 30 years ago and is >> >> bad programming practice, as it tends to complicate analysis >> >> for the human and increase the chance of improper usage of >> >> variables. >> >> >> >> We should move away from this for new code. >> >> >> > >> > Really? I personally find having all variables grouped together >> > much easier to understand. Stumbling across declarations in the >> > middle of the code in a for-loop, for example, takes me by surprise. >> > >> > I also greatly dislike initializing variables in their declarations. >> > >> > Maybe I'm just old fashioned since I have been writing C-code for >> > more than 30 years. >> >> +1 >> >> Probably should be discouraged, but allowed on a case-by-case >> basis. One could argue that if you need to declaration blocks >> in the middle of code, then that code is too complex and should >> be broken out into a separate function. >> > > Right. > > And code like this > > int func(void) > { > int baz, zot; > [some more code] > if (zot < 5) > { > int baz = 3; > [more code] > } > [some more code] > } > > is even worse. The compiler (clang) seems to consider this to > merely be a reinitialization of baz, but a human might be confused. oh please... :) This is simply an inner variable shadowing the outer one (which is another poor practice, flagged with -Wshadow ). When you exit the scope you get the external variable with its value, as you can see from the following code. #include int main(int ac, char *av[]) { int baz = 5; printf("1 baz %d\n", baz); { int baz = 3; printf("2 baz %d\n", baz); } printf("3 baz %d\n", baz); return 0; } cheers luigi From owner-freebsd-threads@freebsd.org Wed Jan 27 03:04:39 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9D42A6F80C for ; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9D5D4C10 for ; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 9999BA6F808; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98C62A6F806; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 44004C0C; Wed, 27 Jan 2016 03:04:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 1C54342C5BF; Wed, 27 Jan 2016 14:04:30 +1100 (AEDT) Date: Wed, 27 Jan 2016 14:04:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Gary Jennejohn cc: Daniel Eischen , Boris Astardzhiev , threads@freebsd.org, Luigi Rizzo , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <20160127013145.36f2aaef@ernst.home> Message-ID: <20160127132558.W985@besplex.bde.org> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=PfoC/XVd c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=0JCmQBZd7s8qsGVShdUA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 03:04:39 -0000 On Wed, 27 Jan 2016, Gary Jennejohn wrote: > On Tue, 26 Jan 2016 17:46:52 -0500 (EST) > Daniel Eischen wrote: > >> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >> >>> On Tue, 26 Jan 2016 09:06:39 -0800 >>> Luigi Rizzo wrote: >>> >>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>> wrote: >>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>> +ssize_t >>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >>>>>> + const struct timespec *__restrict timeout) >>>>>> +{ >>>>>> + size_t i, rcvd; >>>>>> + ssize_t ret; >>>>>> + >>>>>> + if (timeout != NULL) { >>>>>> + fd_set fds; >>>>>> + int res; >>>>> Please move all local definitions to the beginning of the function. >>>> >>>> This style recommendation was from 30 years ago and is >>>> bad programming practice, as it tends to complicate analysis >>>> for the human and increase the chance of improper usage of >>>> variables. >>>> >>>> We should move away from this for new code. >>> >>> Really? I personally find having all variables grouped together >>> much easier to understand. Stumbling across declarations in the >>> middle of the code in a for-loop, for example, takes me by surprise. +1 I used to program in a strict version of the "new" style 25-30 years ago, but learned better. In the strict version, every variable must have minimal scope, so squillions of inner blocks are needed to limit the scopes. Some deeply nested of course. This is a good obfuscation. It even breaks -Wshadow by letting you have unrelated variables named 'i' that don't shadow each other because their scope is limited. Such variables are good in separate functions but not in the same function. Understanding the code to see that the variables are actually unrelated requires counting more braces than usual. If you don't do this strictly then you get a random style with some variables declared at the top and some in inner blocks for mostly historical reasons. A strict style with all of the variables at the top is much easier to write and read. >>> I also greatly dislike initializing variables in their declarations. >>> >>> Maybe I'm just old fashioned since I have been writing C-code for >>> more than 30 years. >> >> +1 >> >> Probably should be discouraged, but allowed on a case-by-case >> basis. One could argue that if you need to declaration blocks >> in the middle of code, then that code is too complex and should >> be broken out into a separate function. > > Right. Lots of inner blocks are good for both making simple code look complex and making it easier to write the complex code in the same function, at least if you use a tiny indentation so that you can have 40 levels of indentation without needing a 500-column terminal. > And code like this > > int func(void) > { > int baz, zot; > [some more code] > if (zot < 5) > { > int baz = 3; > [more code] > } > [some more code] > } > > is even worse. The compiler (clang) seems to consider this to > merely be a reinitialization of baz, but a human might be confused. No, that is a different baz, and is warned about by Wshadow. > Something like for (int i = 0; i < 2; i++) is IMHO OK. Except it is C++ style which is so forbidden that style(9) doesn't know that it needs a rule to forbid it. The worst is C++ style that doesn't limit the scope -- a bunch of variables at the top and then somewhere in the middle of the function another variable is needed and it is declared at top level of the function scope. I sometimes do this when in a hurry. The strict K&R-C90 style requires opening an inner block to do little more than hold the declaration and then (re)indenting and (re)formatting all the code in the inner block. The C++ style reduces writability and readability in a different way. It doesn't cause excessive indentation but it doesn't limit the scope much differently than putting all the declarations at the top. At least the reader can find the declarations easily when they are at the top. Bruce From owner-freebsd-threads@freebsd.org Wed Jan 27 04:07:46 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96F4EA6EE3C for ; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA501181 for ; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6C829A6EE3A; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B8C2A6EE38; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28A12117E; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ob0-x233.google.com with SMTP id is5so158664792obc.0; Tue, 26 Jan 2016 20:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8c8cFMzpu1Eo5kd5Vi84Y1/ndIb2zqmERWEkC0iSDPo=; b=I703BzXsF4pQPHe1Ko8m/B2TJpxs3/dXcHbiRIKhC3rbXIe7sMaew6PHGaFL1f77d0 1AeCRVs0NStlQKqJ+Fz+nphp1Lh1e6EmoEeMpUdwce0YYJ0C3EfqF65haYlsequDAVKL mT7VEcqluhHK1p52WSMVEic8UIULeDCw/L2D7fONWoRzTv9p9GgXEfJi7S5fyG87Xibi lKpWxbSNmVPPPdC0AuKMbvPqGEr6L0IRnIl3wOO60Tn5D2lmMbuMZjrV4PUQi0AMS96o 6iE1PSPP/soewfXWcWCu8V4PFi4BKI9AOcIEC9iCxTOP5YL/pPiUbFQzSpH6Ge5ml4BP gn7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8c8cFMzpu1Eo5kd5Vi84Y1/ndIb2zqmERWEkC0iSDPo=; b=C0raulsV0wlAt6FMYXxitYMBC7Lfy86eX1Ajtc/5aTnqLg3F9hVcvEOARRjhU5Oz9D RyfXxL8soQUnOFtmWQtJ4AGxbnSjD9jnRDwbu7Uk0HhjMTvfdK4KJk0G1tehBwcU9fKv 2NxG9fKLfYbGm/wP9HREMC4pT8NNjNnKP1LMOwOqk6VRMZyQ+IFqs1k6/p5ZIflDOVLu sGL+zB+0WMdBOvH6coSPh+1WfKBAALBQPtG4pLsu3NOdDRVxbb1lD6T10ENzxMzi0hpE ZnC4fdj54eXkOkOcf4TmeePwxX/Wa5XbAx+3d6thlQ5FX58vvuYxR/TvAQYP7aPcEKpi 42ww== X-Gm-Message-State: AG10YOQCe7wMUIifo18SJbDGjGhA1kTrb6l3VYnOKYEU8jVMqaUO1tgZ3qXGzJVCcXdzTv6Px1j7oDWeXWbAIA== MIME-Version: 1.0 X-Received: by 10.182.116.200 with SMTP id jy8mr21254020obb.35.1453867665444; Tue, 26 Jan 2016 20:07:45 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.202.89.130 with HTTP; Tue, 26 Jan 2016 20:07:45 -0800 (PST) In-Reply-To: <20160127132558.W985@besplex.bde.org> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <20160127132558.W985@besplex.bde.org> Date: Tue, 26 Jan 2016 20:07:45 -0800 X-Google-Sender-Auth: bF99goyZzGwjIdS4teqKAUU-7Kg Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Kevin Oberman To: Bruce Evans Cc: Gary Jennejohn , Daniel Eischen , threads@freebsd.org, Boris Astardzhiev , Luigi Rizzo , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 04:07:46 -0000 Since this has become a debate on programming style, it seem appropriate to mention that Edward Yourdan passed away last Tuesday. For those too young to recognize the name, he was the developer of modern structured programming. He did recognize the style rules are important, but not iron-clad. Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans wrote: > On Wed, 27 Jan 2016, Gary Jennejohn wrote: > > On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >> Daniel Eischen wrote: >> >> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>> >>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>> Luigi Rizzo wrote: >>>> >>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>> wrote: >>>>> >>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>> >>>>>>> +ssize_t >>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int >>>>>>> flags, >>>>>>> + const struct timespec *__restrict timeout) >>>>>>> +{ >>>>>>> + size_t i, rcvd; >>>>>>> + ssize_t ret; >>>>>>> + >>>>>>> + if (timeout != NULL) { >>>>>>> + fd_set fds; >>>>>>> + int res; >>>>>>> >>>>>> Please move all local definitions to the beginning of the function. >>>>>> >>>>> >>>>> This style recommendation was from 30 years ago and is >>>>> bad programming practice, as it tends to complicate analysis >>>>> for the human and increase the chance of improper usage of >>>>> variables. >>>>> >>>>> We should move away from this for new code. >>>>> >>>> >>>> Really? I personally find having all variables grouped together >>>> much easier to understand. Stumbling across declarations in the >>>> middle of the code in a for-loop, for example, takes me by surprise. >>>> >>> > +1 > > I used to program in a strict version of the "new" style 25-30 years > ago, but learned better. In the strict version, every variable must > have minimal scope, so squillions of inner blocks are needed to limit > the scopes. Some deeply nested of course. This is a good obfuscation. > It even breaks -Wshadow by letting you have unrelated variables named > 'i' that don't shadow each other because their scope is limited. Such > variables are good in separate functions but not in the same function. > Understanding the code to see that the variables are actually unrelated > requires counting more braces than usual. If you don't do this > strictly then you get a random style with some variables declared at > the top and some in inner blocks for mostly historical reasons. A > strict style with all of the variables at the top is much easier to > write and read. > > I also greatly dislike initializing variables in their declarations. >>>> >>>> Maybe I'm just old fashioned since I have been writing C-code for >>>> more than 30 years. >>>> >>> >>> +1 >>> >>> Probably should be discouraged, but allowed on a case-by-case >>> basis. One could argue that if you need to declaration blocks >>> in the middle of code, then that code is too complex and should >>> be broken out into a separate function. >>> >> >> Right. >> > > Lots of inner blocks are good for both making simple code look complex > and making it easier to write the complex code in the same function, > at least if you use a tiny indentation so that you can have 40 levels > of indentation without needing a 500-column terminal. > > And code like this >> >> int func(void) >> { >> int baz, zot; >> [some more code] >> if (zot < 5) >> { >> int baz = 3; >> [more code] >> } >> [some more code] >> } >> >> is even worse. The compiler (clang) seems to consider this to >> merely be a reinitialization of baz, but a human might be confused. >> > > No, that is a different baz, and is warned about by Wshadow. > > Something like for (int i = 0; i < 2; i++) is IMHO OK. >> > > Except it is C++ style which is so forbidden that style(9) doesn't > know that it needs a rule to forbid it. > > The worst is C++ style that doesn't limit the scope -- a bunch of > variables at the top and then somewhere in the middle of the function > another variable is needed and it is declared at top level of the > function scope. I sometimes do this when in a hurry. The strict > K&R-C90 style requires opening an inner block to do little more than > hold the declaration and then (re)indenting and (re)formatting all > the code in the inner block. The C++ style reduces writability and > readability in a different way. It doesn't cause excessive indentation > but it doesn't limit the scope much differently than putting all the > declarations at the top. At least the reader can find the declarations > easily when they are at the top. > > Bruce > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-threads@freebsd.org Wed Jan 27 10:14:05 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F29CA6F205 for ; Wed, 27 Jan 2016 10:14:05 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 67F4D1D97 for ; Wed, 27 Jan 2016 10:14:05 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 61BDBA6F202; Wed, 27 Jan 2016 10:14:05 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60C3DA6F200; Wed, 27 Jan 2016 10:14:05 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6A581D93; Wed, 27 Jan 2016 10:14:04 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id 123so144666581wmz.0; Wed, 27 Jan 2016 02:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=me8kynz4UqlTFaowtYMjeDL/5ucMxemlJz9/vVLp0WQ=; b=WUyqrsAoPXdE8NGnT3mwyKDjUdx33iY+1rfYVHaff6LdMYndvNWU2Ojrjd/Et5tQrd 7Zn5ojkzGt4ZsKFvHUtuHM/iAqrJ7fqDoEFOwS53af2YlfEoIqMsj6GDxk2QdQpa/T0W jH2ASCaw48m8h/jK1KhwvORg+RhSlqmYPIywgw/FscLyVvKbPhgMPjmUGOYNqezdnFdl wlU2RSLBUgrYzuSbQTkDLe3A+TQbfrPNWlihKRqcmDqChjIS/7PxyCUf1SGb+2/lDFVH xdVUhKs6w/PZHf5R5LPbfHZMX/6yEQe1d1yNCyedutL0qppJmeVlAv5sHsG41piOj76q E/KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=me8kynz4UqlTFaowtYMjeDL/5ucMxemlJz9/vVLp0WQ=; b=XAdmcLO89byVOKqXtNuSyUGhRizK+fCo9HoinzU0n2HGuRXnn1FLcUPPoqFlpWTKPH hCFyfOL0z7eCXm/M4aWcEwRrH2hpLbRG0nPUONYyC1jhlV9b1PzSUsa689BGYQQU416W 33yWuumdfUI1WnV1axZ9rvq1GbBazowX6tbSXo/hTbqV5iXCTe/JIFmqp0+ZuHzmo7aN aZvLe7BxplDvUtBnLyTKKKvpSHflesq/UIrhEcgtRi5bT5lWM7IT+H/Oo7Xbiej2jNVw 5efI9QeEj69JOjv/Lgo7nS7+SpwhISQ1c0Jmxa4O5jRF7+tYsn/xVA2RCugKTKfgCnNT khgw== X-Gm-Message-State: AG10YOSC7pmaDmqxlvbGo3Vr6AGr50vMEYDqbQjgfErOKUhdF+ATWIiunfYQcFedIc7fE+fDVzgPuwz2rbRebQ== MIME-Version: 1.0 X-Received: by 10.194.243.103 with SMTP id wx7mr31668722wjc.136.1453889643178; Wed, 27 Jan 2016 02:14:03 -0800 (PST) Received: by 10.28.136.148 with HTTP; Wed, 27 Jan 2016 02:14:02 -0800 (PST) In-Reply-To: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <20160127132558.W985@besplex.bde.org> Date: Wed, 27 Jan 2016 12:14:02 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Kevin Oberman Cc: Bruce Evans , Gary Jennejohn , Daniel Eischen , threads@freebsd.org, Luigi Rizzo , "freebsd-net@freebsd.org" Content-Type: multipart/mixed; boundary=089e01493c12b9cea1052a4e0f84 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 10:14:05 -0000 --089e01493c12b9cea1052a4e0f84 Content-Type: text/plain; charset=UTF-8 Hello, I've made a few changes in the patch as recommended here starting with the switch to ppoll(). I have a question since it's not quite clear to me as written in the manpage. Is it possible that ppoll() doesn't return an error and yet revents have set either POLLERR or POLLHUP or POLLNVAL? See patch and comments are again welcomed. On Wed, Jan 27, 2016 at 6:07 AM, Kevin Oberman wrote: > Since this has become a debate on programming style, it seem appropriate > to mention that Edward Yourdan passed away last Tuesday. For those too > young to recognize the name, he was the developer of modern structured > programming. He did recognize the style rules are important, but not > iron-clad. > > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans wrote: > >> On Wed, 27 Jan 2016, Gary Jennejohn wrote: >> >> On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >>> Daniel Eischen wrote: >>> >>> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>>> >>>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>>> Luigi Rizzo wrote: >>>>> >>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>>> wrote: >>>>>> >>>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>>> >>>>>>>> +ssize_t >>>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, >>>>>>>> int flags, >>>>>>>> + const struct timespec *__restrict timeout) >>>>>>>> +{ >>>>>>>> + size_t i, rcvd; >>>>>>>> + ssize_t ret; >>>>>>>> + >>>>>>>> + if (timeout != NULL) { >>>>>>>> + fd_set fds; >>>>>>>> + int res; >>>>>>>> >>>>>>> Please move all local definitions to the beginning of the function. >>>>>>> >>>>>> >>>>>> This style recommendation was from 30 years ago and is >>>>>> bad programming practice, as it tends to complicate analysis >>>>>> for the human and increase the chance of improper usage of >>>>>> variables. >>>>>> >>>>>> We should move away from this for new code. >>>>>> >>>>> >>>>> Really? I personally find having all variables grouped together >>>>> much easier to understand. Stumbling across declarations in the >>>>> middle of the code in a for-loop, for example, takes me by surprise. >>>>> >>>> >> +1 >> >> I used to program in a strict version of the "new" style 25-30 years >> ago, but learned better. In the strict version, every variable must >> have minimal scope, so squillions of inner blocks are needed to limit >> the scopes. Some deeply nested of course. This is a good obfuscation. >> It even breaks -Wshadow by letting you have unrelated variables named >> 'i' that don't shadow each other because their scope is limited. Such >> variables are good in separate functions but not in the same function. >> Understanding the code to see that the variables are actually unrelated >> requires counting more braces than usual. If you don't do this >> strictly then you get a random style with some variables declared at >> the top and some in inner blocks for mostly historical reasons. A >> strict style with all of the variables at the top is much easier to >> write and read. >> >> I also greatly dislike initializing variables in their declarations. >>>>> >>>>> Maybe I'm just old fashioned since I have been writing C-code for >>>>> more than 30 years. >>>>> >>>> >>>> +1 >>>> >>>> Probably should be discouraged, but allowed on a case-by-case >>>> basis. One could argue that if you need to declaration blocks >>>> in the middle of code, then that code is too complex and should >>>> be broken out into a separate function. >>>> >>> >>> Right. >>> >> >> Lots of inner blocks are good for both making simple code look complex >> and making it easier to write the complex code in the same function, >> at least if you use a tiny indentation so that you can have 40 levels >> of indentation without needing a 500-column terminal. >> >> And code like this >>> >>> int func(void) >>> { >>> int baz, zot; >>> [some more code] >>> if (zot < 5) >>> { >>> int baz = 3; >>> [more code] >>> } >>> [some more code] >>> } >>> >>> is even worse. The compiler (clang) seems to consider this to >>> merely be a reinitialization of baz, but a human might be confused. >>> >> >> No, that is a different baz, and is warned about by Wshadow. >> >> Something like for (int i = 0; i < 2; i++) is IMHO OK. >>> >> >> Except it is C++ style which is so forbidden that style(9) doesn't >> know that it needs a rule to forbid it. >> >> The worst is C++ style that doesn't limit the scope -- a bunch of >> variables at the top and then somewhere in the middle of the function >> another variable is needed and it is declared at top level of the >> function scope. I sometimes do this when in a hurry. The strict >> K&R-C90 style requires opening an inner block to do little more than >> hold the declaration and then (re)indenting and (re)formatting all >> the code in the inner block. The C++ style reduces writability and >> readability in a different way. It doesn't cause excessive indentation >> but it doesn't limit the scope much differently than putting all the >> declarations at the top. At least the reader can find the declarations >> easily when they are at the top. >> >> Bruce >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > --089e01493c12b9cea1052a4e0f84 Content-Type: text/plain; charset=US-ASCII; name="sendrecvmmsg-libconly6.diff" Content-Disposition: attachment; filename="sendrecvmmsg-libconly6.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ijwo52uv0 ZGlmZiAtLWdpdCBhL2xpYi9saWJjL2dlbi9NYWtlZmlsZS5pbmMgYi9saWIvbGliYy9nZW4vTWFr ZWZpbGUuaW5jCmluZGV4IGI0NDg0NjEuLjdkZThjZTMgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL2dl bi9NYWtlZmlsZS5pbmMKKysrIGIvbGliL2xpYmMvZ2VuL01ha2VmaWxlLmluYwpAQCAtOTksMTEg Kzk5LDEzIEBAIFNSQ1MrPQlfX2dldG9zcmVsZGF0ZS5jIFwKIAlyYWlzZS5jIFwKIAlyZWFkZGly LmMgXAogCXJlYWRwYXNzcGhyYXNlLmMgXAorCXJlY3ZtbXNnLmMgXAogCXJld2luZGRpci5jIFwK IAlzY2FuZGlyLmMgXAogCXNlZWQ0OC5jIFwKIAlzZWVrZGlyLmMgXAogCXNlbWN0bC5jIFwKKwlz ZW5kbW1zZy5jIFwKIAlzZXRkb21haW5uYW1lLmMgXAogCXNldGhvc3RuYW1lLmMgXAogCXNldGpt cGVyci5jIFwKQEAgLTQ1MSwxMCArNDUzLDEyIEBAIE1MSU5LUys9cmFuZDQ4LjMgX3JhbmQ0OC4z IFwKIAlyYW5kNDguMyBucmFuZDQ4LjMgXAogCXJhbmQ0OC4zIHNlZWQ0OC4zIFwKIAlyYW5kNDgu MyBzcmFuZDQ4LjMKK01MSU5LUys9cmVjdi4yIHJlY3ZtbXNnLjIKIE1MSU5LUys9c2NhbmRpci4z IGFscGhhc29ydC4zCiBNTElOS1MrPXNlbV9vcGVuLjMgc2VtX2Nsb3NlLjMgXAogCXNlbV9vcGVu LjMgc2VtX3VubGluay4zCiBNTElOS1MrPXNlbV93YWl0LjMgc2VtX3RyeXdhaXQuMworTUxJTktT Kz1zZW5kLjIgc2VuZG1tc2cuMgogTUxJTktTKz1zZXRqbXAuMyBfbG9uZ2ptcC4zIFwKIAlzZXRq bXAuMyBfc2V0am1wLjMgXAogCXNldGptcC4zIGxvbmdqbXAuMyBcCmRpZmYgLS1naXQgYS9saWIv bGliYy9nZW4vcmVjdm1tc2cuYyBiL2xpYi9saWJjL2dlbi9yZWN2bW1zZy5jCm5ldyBmaWxlIG1v ZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjQzMjAwOGYKLS0tIC9kZXYvbnVsbAorKysgYi9saWIv bGliYy9nZW4vcmVjdm1tc2cuYwpAQCAtMCwwICsxLDg3IEBACisvKgorICogQ29weXJpZ2h0IChj KSAyMDE2IEJvcmlzIEFzdGFyZHpoaWV2LCBTbWFydGNvbS1CdWxnYXJpYSBBRAorICogQWxsIHJp Z2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBh bmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBl cm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1l dDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUg YWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UocyksIHRoaXMgbGlzdCBvZiBjb25kaXRpb25z IGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgYXMKKyAqICAgIHRoZSBmaXJzdCBsaW5lcyBv ZiB0aGlzIGZpbGUgdW5tb2RpZmllZCBvdGhlciB0aGFuIHRoZSBwb3NzaWJsZQorICogICAgYWRk aXRpb24gb2Ygb25lIG9yIG1vcmUgY29weXJpZ2h0IG5vdGljZXMuCisgKiAyLiBSZWRpc3RyaWJ1 dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAor ICogICAgbm90aWNlKHMpLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2lu ZyBkaXNjbGFpbWVyIGluCisgKiAgICB0aGUgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0 ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCisgKiAgICBkaXN0cmlidXRpb24uCisgKgorICogVEhJ UyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQ09QWVJJR0hUIEhPTERFUihTKSBgYEFTIElT JycgQU5EIEFOWQorICogRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywg QlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFO VEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUgorICogUFVSUE9TRSBBUkUgRElT Q0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBDT1BZUklHSFQgSE9MREVSKFMpIEJFCisg KiBMSUFCTEUgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBF WEVNUExBUlksIE9SCisgKiBDT05TRVFVRU5USUFMIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5P VCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRgorICogU1VCU1RJVFVURSBHT09EUyBPUiBTRVJW SUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SCisgKiBCVVNJTkVTUyBJTlRF UlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwK KyAqIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xV RElORyBORUdMSUdFTkNFCisgKiBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQg T0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLAorICogRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQ T1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2NkZWZzLmg+ CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNs dWRlIDxzeXMvc29ja2V0Lmg+CisjaW5jbHVkZSA8c3lzL3BvbGwuaD4KKyNpbmNsdWRlIDxzeXMv c3RkZGVmLmg+CisjaW5jbHVkZSAibGliY19wcml2YXRlLmgiCisKKyNkZWZpbmUgUE9MTE1BU0sg KFBPTExJTiB8IFBPTExSRE5PUk0gfCBQT0xMUkRCQU5EIHwgUE9MTFBSSSkKKyNkZWZpbmUgRVBP TExNQVNLIChQT0xMRVJSIHwgUE9MTEhVUCB8IFBPTExOVkFMKQorCitzc2l6ZV90CityZWN2bW1z ZyhpbnQgcywgc3RydWN0IG1tc2doZHIgKl9fcmVzdHJpY3QgbXNndmVjLCBzaXplX3Qgdmxlbiwg aW50IGZsYWdzLAorICAgIGNvbnN0IHN0cnVjdCB0aW1lc3BlYyAqX19yZXN0cmljdCB0aW1lb3V0 KQoreworCXN0cnVjdCBwb2xsZmQgcGZkWzFdOworCXNpemVfdCBpLCByY3ZkOworCXNzaXplX3Qg cmV0OworCWludCByZXM7CisKKwlpZiAodGltZW91dCAhPSBOVUxMKSB7CisJCXBmZFswXS5mZCA9 IHM7CisJCXBmZFswXS5ldmVudHMgPSBQT0xMTUFTSzsKKwkJcGZkWzBdLnJldmVudHMgPSAwOwor CQlyZXMgPSBwcG9sbCgmcGZkWzBdLCAxLCB0aW1lb3V0LCBOVUxMKTsKKwkJaWYgKHJlcyA9PSAt MSB8fCByZXMgPT0gMCkKKwkJCXJldHVybiAocmVzKTsKKwkJaWYgKHBmZFswXS5yZXZlbnRzICYg RVBPTExNQVNLIHx8CisJCSAgICAocGZkWzBdLnJldmVudHMgJiBQT0xMTUFTSykgPT0gMCkKKwkJ CXJldHVybiAoLTEpOworCX0KKworCXJldCA9IF9fc3lzX3JlY3Ztc2cocywgJm1zZ3ZlY1swXS5t c2dfaGRyLCBmbGFncyk7CisJaWYgKHJldCA9PSAtMSkKKwkJcmV0dXJuIChyZXQpOworCisJLyog VHVybiBvbiBET05UV0FJVCBpZiBXQUlURk9ST05FIGlzIHNldC4gKi8KKwlpZiAoZmxhZ3MgJiBN U0dfV0FJVEZPUk9ORSkKKwkJZmxhZ3MgfD0gTVNHX0RPTlRXQUlUOworCisJcmN2ZCA9IDE7CisJ Zm9yIChpID0gcmN2ZDsgaSA8IHZsZW47IGkrKywgcmN2ZCsrKSB7CisJCXJldCA9IF9fc3lzX3Jl Y3Ztc2cocywgJm1zZ3ZlY1tpXS5tc2dfaGRyLCBmbGFncyk7CisJCWlmIChyZXQgPT0gLTEpIHsK KwkJCS8qIFdlIGhhdmUgcmVjZWl2ZWQgbWVzc2FnZXMuIExldCBjYWxsZXIga25vdy4gKi8KKwkJ CXJldHVybiAocmN2ZCk7CisJCX0KKworCQkvKiBTYXZlIHJlY2VpdmVkIGJ5dGVzICovCisJCW1z Z3ZlY1tpXS5tc2dfbGVuID0gcmV0OworCX0KKworCXJldHVybiAocmN2ZCk7Cit9CisKKyN1bmRl ZiBQT0xMTUFTSworI3VuZGVmIEVQT0xMTUFTSwpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvZ2VuL3Nl bmRtbXNnLmMgYi9saWIvbGliYy9nZW4vc2VuZG1tc2cuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NApp bmRleCAwMDAwMDAwLi4zZDkxZWUyCi0tLSAvZGV2L251bGwKKysrIGIvbGliL2xpYmMvZ2VuL3Nl bmRtbXNnLmMKQEAgLTAsMCArMSw1OSBAQAorLyoKKyAqIENvcHlyaWdodCAoYykgMjAxNiBCb3Jp cyBBc3RhcmR6aGlldiwgU21hcnRjb20tQnVsZ2FyaWEgQUQKKyAqIEFsbCByaWdodHMgcmVzZXJ2 ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBm b3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJv dmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBS ZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHly aWdodAorICogICAgbm90aWNlKHMpLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZv bGxvd2luZyBkaXNjbGFpbWVyIGFzCisgKiAgICB0aGUgZmlyc3QgbGluZXMgb2YgdGhpcyBmaWxl IHVubW9kaWZpZWQgb3RoZXIgdGhhbiB0aGUgcG9zc2libGUKKyAqICAgIGFkZGl0aW9uIG9mIG9u ZSBvciBtb3JlIGNvcHlyaWdodCBub3RpY2VzLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJp bmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGlj ZShzKSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ciBpbgorICogICAgdGhlIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92 aWRlZCB3aXRoIHRoZQorICogICAgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUg SVMgUFJPVklERUQgQlkgVEhFIENPUFlSSUdIVCBIT0xERVIoUykgYGBBUyBJUycnIEFORCBBTlkK KyAqIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElN SVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFO RCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIKKyAqIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuICBJ TiBOTyBFVkVOVCBTSEFMTCBUSEUgQ09QWVJJR0hUIEhPTERFUihTKSBCRQorICogTElBQkxFIEZP UiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBP UgorICogQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBU TywgUFJPQ1VSRU1FTlQgT0YKKyAqIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1Mg T0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUgorICogQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBI T1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksCisgKiBXSEVUSEVS IElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElH RU5DRQorICogT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0Ug T0YgVEhJUyBTT0ZUV0FSRSwKKyAqIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkg T0YgU1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQo IiRGcmVlQlNEJCIpOworCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3Nv Y2tldC5oPgorI2luY2x1ZGUgImxpYmNfcHJpdmF0ZS5oIgorCitzc2l6ZV90CitzZW5kbW1zZyhp bnQgcywgc3RydWN0IG1tc2doZHIgKl9fcmVzdHJpY3QgbXNndmVjLCBzaXplX3QgdmxlbiwgaW50 IGZsYWdzKQoreworCXNpemVfdCBpLCBzZW50OworCXNzaXplX3QgcmV0OworCisJc2VudCA9IDA7 CisJZm9yIChpID0gMDsgaSA8IHZsZW47IGkrKywgc2VudCsrKSB7CisJCXJldCA9IF9fc3lzX3Nl bmRtc2cocywgJm1zZ3ZlY1tpXS5tc2dfaGRyLCBmbGFncyk7CisJCWlmIChyZXQgPT0gLTEpIHsK KwkJCWlmIChzZW50ICE9IDApIHsKKwkJCQkvKiBXZSBoYXZlIHNlbnQgbWVzc2FnZXMuIExldCBj YWxsZXIga25vdy4gKi8KKwkJCQlyZXR1cm4gKHNlbnQpOworCQkJfQorCQkJcmV0dXJuIChyZXQp OworCQl9CisKKwkJLyogU2F2ZSBzZW50IGJ5dGVzICovCisJCW1zZ3ZlY1tpXS5tc2dfbGVuID0g cmV0OworCX0KKworCXJldHVybiAoc2VudCk7Cit9CmRpZmYgLS1naXQgYS9saWIvbGliYy9pbmNs dWRlL25hbWVzcGFjZS5oIGIvbGliL2xpYmMvaW5jbHVkZS9uYW1lc3BhY2UuaAppbmRleCA3Mzlk N2IxLi5jOTU4MjllIDEwMDY0NAotLS0gYS9saWIvbGliYy9pbmNsdWRlL25hbWVzcGFjZS5oCisr KyBiL2xpYi9saWJjL2luY2x1ZGUvbmFtZXNwYWNlLmgKQEAgLTIwOCw2ICsyMDgsNyBAQAogI2Rl ZmluZQkJcmVhZHYJCQkJX3JlYWR2CiAjZGVmaW5lCQlyZWN2ZnJvbQkJCV9yZWN2ZnJvbQogI2Rl ZmluZQkJcmVjdm1zZwkJCQlfcmVjdm1zZworI2RlZmluZQkJcmVjdm1tc2cJCQlfcmVjdm1tc2cK ICNkZWZpbmUJCXNlbGVjdAkJCQlfc2VsZWN0CiAjZGVmaW5lCQlzZW1fY2xvc2UJCQlfc2VtX2Ns b3NlCiAjZGVmaW5lCQlzZW1fZGVzdHJveQkJCV9zZW1fZGVzdHJveQpAQCAtMjIwLDYgKzIyMSw3 IEBACiAjZGVmaW5lCQlzZW1fdW5saW5rCQkJX3NlbV91bmxpbmsKICNkZWZpbmUJCXNlbV93YWl0 CQkJX3NlbV93YWl0CiAjZGVmaW5lCQlzZW5kbXNnCQkJCV9zZW5kbXNnCisjZGVmaW5lCQlzZW5k bW1zZwkJCV9zZW5kbW1zZwogI2RlZmluZQkJc2VuZHRvCQkJCV9zZW5kdG8KICNkZWZpbmUJCXNl dHNvY2tvcHQJCQlfc2V0c29ja29wdAogLyojZGVmaW5lCQlzaWdhY3Rpb24JCQlfc2lnYWN0aW9u Ki8KZGlmZiAtLWdpdCBhL2xpYi9saWJjL2luY2x1ZGUvdW4tbmFtZXNwYWNlLmggYi9saWIvbGli Yy9pbmNsdWRlL3VuLW5hbWVzcGFjZS5oCmluZGV4IGYzMWZhN2EuLjAyMzMzNDggMTAwNjQ0Ci0t LSBhL2xpYi9saWJjL2luY2x1ZGUvdW4tbmFtZXNwYWNlLmgKKysrIGIvbGliL2xpYmMvaW5jbHVk ZS91bi1uYW1lc3BhY2UuaApAQCAtMTg5LDYgKzE4OSw3IEBACiAjdW5kZWYJCXJlYWR2CiAjdW5k ZWYJCXJlY3Zmcm9tCiAjdW5kZWYJCXJlY3Ztc2cKKyN1bmRlZgkJcmVjdm1tc2cKICN1bmRlZgkJ c2VsZWN0CiAjdW5kZWYJCXNlbV9jbG9zZQogI3VuZGVmCQlzZW1fZGVzdHJveQpAQCAtMjAxLDYg KzIwMiw3IEBACiAjdW5kZWYJCXNlbV91bmxpbmsKICN1bmRlZgkJc2VtX3dhaXQKICN1bmRlZgkJ c2VuZG1zZworI3VuZGVmCQlzZW5kbW1zZwogI3VuZGVmCQlzZW5kdG8KICN1bmRlZgkJc2V0c29j a29wdAogI3VuZGVmCQlzaWdhY3Rpb24KZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5cy9TeW1ib2wu bWFwIGIvbGliL2xpYmMvc3lzL1N5bWJvbC5tYXAKaW5kZXggN2IzMjU3Yy4uZGMyZWQwZSAxMDA2 NDQKLS0tIGEvbGliL2xpYmMvc3lzL1N5bWJvbC5tYXAKKysrIGIvbGliL2xpYmMvc3lzL1N5bWJv bC5tYXAKQEAgLTM5OSw2ICszOTksOCBAQCBGQlNEXzEuNCB7CiAJdXRpbWVuc2F0OwogCW51bWFf c2V0YWZmaW5pdHk7CiAJbnVtYV9nZXRhZmZpbml0eTsKKwlzZW5kbW1zZzsKKwlyZWN2bW1zZzsK IH07CiAKIEZCU0Rwcml2YXRlXzEuMCB7CmRpZmYgLS1naXQgYS9saWIvbGliYy9zeXMvcmVjdi4y IGIvbGliL2xpYmMvc3lzL3JlY3YuMgppbmRleCAzMjZlN2ZmLi5jYjU0NjIyIDEwMDY0NAotLS0g YS9saWIvbGliYy9zeXMvcmVjdi4yCisrKyBiL2xpYi9saWJjL3N5cy9yZWN2LjIKQEAgLTM0LDgg KzM0LDkgQEAKIC5TaCBOQU1FCiAuTm0gcmVjdiAsCiAuTm0gcmVjdmZyb20gLAotLk5tIHJlY3Zt c2cKLS5OZCByZWNlaXZlIGEgbWVzc2FnZSBmcm9tIGEgc29ja2V0CisuTm0gcmVjdm1zZyAsCisu Tm0gcmVjdm1tc2cKKy5OZCByZWNlaXZlIG1lc3NhZ2UocykgZnJvbSBhIHNvY2tldAogLlNoIExJ QlJBUlkKIC5MYiBsaWJjCiAuU2ggU1lOT1BTSVMKQEAgLTQ3LDExICs0OCwxNSBAQAogLkZuIHJl Y3Zmcm9tICJpbnQgcyIgInZvaWQgKmJ1ZiIgInNpemVfdCBsZW4iICJpbnQgZmxhZ3MiICJzdHJ1 Y3Qgc29ja2FkZHIgKiByZXN0cmljdCBmcm9tIiAic29ja2xlbl90ICogcmVzdHJpY3QgZnJvbWxl biIKIC5GdCBzc2l6ZV90CiAuRm4gcmVjdm1zZyAiaW50IHMiICJzdHJ1Y3QgbXNnaGRyICptc2ci ICJpbnQgZmxhZ3MiCisuRnQgc3NpemVfdAorLkZuIHJlY3ZtbXNnICJpbnQgcyIgInN0cnVjdCBt bXNnaGRyICogcmVzdHJpY3QgbXNndmVjIiAic2l6ZV90IHZsZW4iICJpbnQgZmxhZ3MiICJjb25z dCBzdHJ1Y3QgdGltZXNwZWMgKiByZXN0cmljdCB0aW1lb3V0IgogLlNoIERFU0NSSVBUSU9OCiBU aGUKIC5GbiByZWN2ZnJvbQogYW5kCiAuRm4gcmVjdm1zZworYW5kCisuRm4gcmVjdm1tc2cKIHN5 c3RlbSBjYWxscwogYXJlIHVzZWQgdG8gcmVjZWl2ZSBtZXNzYWdlcyBmcm9tIGEgc29ja2V0LAog YW5kIG1heSBiZSB1c2VkIHRvIHJlY2VpdmUgZGF0YSBvbiBhIHNvY2tldCB3aGV0aGVyIG9yIG5v dApAQCAtODQsOCArODksMjkgQEAgbnVsbCBwb2ludGVyIHBhc3NlZCBhcyBpdHMKIC5GYSBmcm9t CiBhcmd1bWVudC4KIC5QcAotQWxsIHRocmVlIHJvdXRpbmVzIHJldHVybiB0aGUgbGVuZ3RoIG9m IHRoZSBtZXNzYWdlIG9uIHN1Y2Nlc3NmdWwKLWNvbXBsZXRpb24uCitUaGUKKy5GbiByZWN2bW1z ZworZnVuY3Rpb24gaXMgdXNlZCB0byByZWNlaXZlIG11bHRpcGxlCittZXNzYWdlcyBhdCBhIGNh bGwuCitUaGVpciBudW1iZXIgaXMgc3VwcGxpZWQgYnkKKy5GYSB2bGVuIC4KK1RoZSBtZXNzYWdl cyBhcmUgcGxhY2VkIGluIHRoZQorLkZhIG1zZ3ZlYwordmVjdG9yIGFmdGVyIHJlY2VwdGlvbi4K K1RoZSBzaXplIG9mIGVhY2ggcmVjZWl2ZWQgbWVzc2FnZSBpcyBwbGFjZWQgaW4gdGhlCisuRmEg bXNnX2xlbgorZmllbGQgb2YgZWFjaCBlbGVtZW50IG9mIHRoZSB2ZWN0b3IuCitJZgorLkZhIHRp bWVvdXQKK2lzIE5VTEwgdGhlIGNhbGwgd2lsbCBub3JtYWxseSBibG9jay4KK090aGVyd2lzZSBp dCB3aWxsIHdhaXQgZm9yIGRhdGEgZm9yIHRoZSBzcGVjaWZpZWQgYW1vdW50IG9mIHRpbWUuCitJ ZiB0aGUgdGltZW91dCBleHBpcmVzIGFuZCB0aGVyZSBpcyBubyBkYXRhIHJlY2VpdmVkIGEgdmFs dWUgb2YgMCBpcyByZXR1cm5lZC4KK3Bwb2xsKDIpIGlzIHVzZWQgZm9yIHRoZSBpbXBsZW1lbnRh dGlvbiBvZiB0aGUgdGltZW91dCBtZWNoYW5pc20uCisuUHAKK1RoZSBmaXJzdCB0aHJlZSByb3V0 aW5lcyByZXR1cm4gdGhlIGxlbmd0aCBvZiB0aGUgbWVzc2FnZSBvbiBzdWNjZXNzZnVsCitjb21w bGV0aW9uIHdoZXJlYXMKKy5GbiByZWN2bW1zZworcmV0dXJucyB0aGUgbnVtYmVyIG9mIHJlY2Vp dmVkIG1lc3NhZ2VzLgogSWYgYSBtZXNzYWdlIGlzIHRvbyBsb25nIHRvIGZpdCBpbiB0aGUgc3Vw cGxpZWQgYnVmZmVyLAogZXhjZXNzIGJ5dGVzIG1heSBiZSBkaXNjYXJkZWQgZGVwZW5kaW5nIG9u IHRoZSB0eXBlIG9mIHNvY2tldAogdGhlIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgZnJvbSAoc2VlCkBA IC0xMDAsNyArMTI2LDkgQEAgaW4gd2hpY2ggY2FzZSB0aGUgdmFsdWUKIC5WYSBlcnJubwogaXMg c2V0IHRvCiAuRXIgRUFHQUlOIC4KLVRoZSByZWNlaXZlIGNhbGxzIG5vcm1hbGx5IHJldHVybiBh bnkgZGF0YSBhdmFpbGFibGUsCitUaGUgcmVjZWl2ZSBjYWxscyBleGNlcHQKKy5GbiByZWN2bW1z Zworbm9ybWFsbHkgcmV0dXJuIGFueSBkYXRhIGF2YWlsYWJsZSwKIHVwIHRvIHRoZSByZXF1ZXN0 ZWQgYW1vdW50LAogcmF0aGVyIHRoYW4gd2FpdGluZyBmb3IgcmVjZWlwdCBvZiB0aGUgZnVsbCBh bW91bnQgcmVxdWVzdGVkOwogdGhpcyBiZWhhdmlvciBpcyBhZmZlY3RlZCBieSB0aGUgc29ja2V0 LWxldmVsIG9wdGlvbnMKQEAgLTEyNyw2ICsxNTUsOSBAQCBvbmUgb3IgbW9yZSBvZiB0aGUgdmFs dWVzOgogLkl0IER2IE1TR19XQUlUQUxMIFRhIHdhaXQgZm9yIGZ1bGwgcmVxdWVzdCBvciBlcnJv cgogLkl0IER2IE1TR19ET05UV0FJVCBUYSBkbyBub3QgYmxvY2sKIC5JdCBEdiBNU0dfQ01TR19D TE9FWEVDIFRhIHNldCByZWNlaXZlZCBmZHMgY2xvc2Utb24tZXhlYworLkl0IER2IE1TR19XQUlU Rk9ST05FIFRhIGRvIG5vdCBibG9jayBhZnRlciByZWNlaXZpbmcgdGhlIGZpcnN0IG1lc3NhZ2UK KyhyZWxldmFudCBvbmx5IGZvcgorLkZuIHJlY3ZtbXNnICkKIC5FbAogLlBwCiBUaGUKQEAgLTE1 OCw2ICsxODksMTEgQEAgaXMgc2V0IHRvCiBUaGlzIGZsYWcgaXMgbm90IGF2YWlsYWJsZSBpbiBz dHJpY3QKIC5UbiBBTlNJCiBvciBDOTkgY29tcGlsYXRpb24gbW9kZS4KK1RoZQorLkR2IE1TR19X QUlURk9ST05FCitmbGFnIHNldHMgTVNHX0RPTlRXQUlUIGFmdGVyIHRoZSBmaXJzdCBtZXNzYWdl IGhhcyBiZWVuIHJlY2VpdmVkLgorVGhpcyBmbGFnIGlzIG9ubHkgcmVsZXZhbnQgZm9yCisuRm4g cmVjdm1tc2cgLgogLlBwCiBUaGUKIC5GbiByZWN2bXNnCkBAIC0yOTAsOSArMzI2LDMzIEBAIGNv bnRyb2wgZGF0YSB3ZXJlIGRpc2NhcmRlZCBkdWUgdG8gbGFjayBvZiBzcGFjZSBpbiB0aGUgYnVm ZmVyCiBmb3IgYW5jaWxsYXJ5IGRhdGEuCiAuRHYgTVNHX09PQgogaXMgcmV0dXJuZWQgdG8gaW5k aWNhdGUgdGhhdCBleHBlZGl0ZWQgb3Igb3V0LW9mLWJhbmQgZGF0YSB3ZXJlIHJlY2VpdmVkLgor LlBwCitUaGUKKy5GbiByZWN2bW1zZworc3lzdGVtIGNhbGwgdXNlcyB0aGUKKy5GYSBtbXNnaGRy CitzdHJ1Y3R1cmUuIEl0cyBmb3JtIGlzIGFzIGZvbGxvd3MsIGFzIGRlZmluZWQgaW4KKy5JbiBz eXMvc29ja2V0LmggOgorLkJkIC1saXRlcmFsCitzdHJ1Y3QgbW1zZ2hkciB7CisJc3RydWN0IG1z Z2hkcgkgbXNnX2hkcjsJLyogbWVzc2FnZSBoZWFkZXIgKi8KKwlzc2l6ZV90CQkgbXNnX2xlbjsJ LyogbWVzc2FnZSBsZW5ndGggKi8KK307CisuRWQKKy5QcAorRm9yCisuRmEgbXNnX2hkcgorc2Vl IGFib3ZlLiBPbiBkYXRhIHJlY2VwdGlvbiB0aGUKKy5GYSBtc2dfbGVuCitmaWVsZCBpcyB1cGRh dGVkIHRvIHRoZSBsZW5ndGggb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UuCitPbiBkYXRhIHRyYW5z bWlzc2lvbiBpdCBpcyB1cGRhdGVkIHRvIHRoZSBudW1iZXIgb2YgY2hhcmFjdGVycyBzZW50Lgog LlNoIFJFVFVSTiBWQUxVRVMKLVRoZXNlIGNhbGxzIHJldHVybiB0aGUgbnVtYmVyIG9mIGJ5dGVz IHJlY2VpdmVkLCBvciAtMQotaWYgYW4gZXJyb3Igb2NjdXJyZWQuCitUaGVzZSBjYWxscyBleGNl cHQKKy5GbiByZWN2bW1zZworcmV0dXJuIHRoZSBudW1iZXIgb2YgYnl0ZXMgcmVjZWl2ZWQuCisu Rm4gcmVjdm1tc2cKK3JldHVybnMgdGhlIG51bWJlciBvZiBtZXNzYWdlcyByZWNlaXZlZC4KK0Eg dmFsdWUgb2YgLTEgaXMgcmV0dXJuZWQgaWYgYW4gZXJyb3Igb2NjdXJyZWQuCiAuU2ggRVJST1JT CiBUaGUgY2FsbHMgZmFpbCBpZjoKIC5CbCAtdGFnIC13aWR0aCBFcgpkaWZmIC0tZ2l0IGEvbGli L2xpYmMvc3lzL3NlbmQuMiBiL2xpYi9saWJjL3N5cy9zZW5kLjIKaW5kZXggOGZhMmM2NC4uOTgx MGFjZSAxMDA2NDQKLS0tIGEvbGliL2xpYmMvc3lzL3NlbmQuMgorKysgYi9saWIvbGliYy9zeXMv c2VuZC4yCkBAIC0zNCw4ICszNCw5IEBACiAuU2ggTkFNRQogLk5tIHNlbmQgLAogLk5tIHNlbmR0 byAsCi0uTm0gc2VuZG1zZwotLk5kIHNlbmQgYSBtZXNzYWdlIGZyb20gYSBzb2NrZXQKKy5ObSBz ZW5kbXNnICwKKy5ObSBzZW5kbW1zZworLk5kIHNlbmQgbWVzc2FnZShzKSBmcm9tIGEgc29ja2V0 CiAuU2ggTElCUkFSWQogLkxiIGxpYmMKIC5TaCBTWU5PUFNJUwpAQCAtNDcsNiArNDgsOCBAQAog LkZuIHNlbmR0byAiaW50IHMiICJjb25zdCB2b2lkICptc2ciICJzaXplX3QgbGVuIiAiaW50IGZs YWdzIiAiY29uc3Qgc3RydWN0IHNvY2thZGRyICp0byIgInNvY2tsZW5fdCB0b2xlbiIKIC5GdCBz c2l6ZV90CiAuRm4gc2VuZG1zZyAiaW50IHMiICJjb25zdCBzdHJ1Y3QgbXNnaGRyICptc2ciICJp bnQgZmxhZ3MiCisuRnQgc3NpemVfdAorLkZuIHNlbmRtbXNnICJpbnQgcyIgInN0cnVjdCBtbXNn aGRyICogcmVzdHJpY3QgbXNndmVjIiAic2l6ZV90IHZsZW4iICJpbnQgZmxhZ3MiCiAuU2ggREVT Q1JJUFRJT04KIFRoZQogLkZuIHNlbmQKQEAgLTU1LDggKzU4LDExIEBAIGFuZAogLkZuIHNlbmR0 bwogYW5kCiAuRm4gc2VuZG1zZworYW5kCisuRm4gc2VuZG1tc2cKIHN5c3RlbSBjYWxscwotYXJl IHVzZWQgdG8gdHJhbnNtaXQgYSBtZXNzYWdlIHRvIGFub3RoZXIgc29ja2V0LgorYXJlIHVzZWQg dG8gdHJhbnNtaXQgb25lIG9yIG11bHRpcGxlIG1lc3NhZ2VzICh3aXRoIHRoZSBsYXR0ZXIgY2Fs bCkgdG8KK2Fub3RoZXIgc29ja2V0LgogVGhlCiAuRm4gc2VuZAogZnVuY3Rpb24KQEAgLTY2LDYg KzcyLDggQEAgc3RhdGUsIHdoaWxlCiAuRm4gc2VuZHRvCiBhbmQKIC5GbiBzZW5kbXNnCithbmQK Ky5GbiBzZW5kbW1zZwogbWF5IGJlIHVzZWQgYXQgYW55IHRpbWUuCiAuUHAKIFRoZSBhZGRyZXNz IG9mIHRoZSB0YXJnZXQgaXMgZ2l2ZW4gYnkKQEAgLTgxLDYgKzg5LDE4IEBAIHVuZGVybHlpbmcg cHJvdG9jb2wsIHRoZSBlcnJvcgogaXMgcmV0dXJuZWQsIGFuZAogdGhlIG1lc3NhZ2UgaXMgbm90 IHRyYW5zbWl0dGVkLgogLlBwCitUaGUKKy5GbiBzZW5kbW1zZworZnVuY3Rpb24gc2VuZHMgbXVs dGlwbGUgbWVzc2FnZXMgYXQgYSBjYWxsLgorVGhleSBhcmUgZ2l2ZW4gYnkgdGhlCisuRmEgbXNn dmVjCit2ZWN0b3IgYWxvbmcgd2l0aAorLkZhIHZsZW4KK3NwZWNpZnlpbmcgaXRzIHNpemUuCitU aGUgbnVtYmVyIG9mIGNoYXJhY3RlcnMgc2VudCBwZXIgZWFjaCBtZXNzYWdlIGlzIHBsYWNlZCBp biB0aGUKKy5GYSBtc2dfbGVuCitmaWVsZCBvZiBlYWNoIGVsZW1lbnQgb2YgdGhlIHZlY3RvciBh ZnRlciB0cmFuc21pc3Npb24uCisuUHAKIE5vIGluZGljYXRpb24gb2YgZmFpbHVyZSB0byBkZWxp dmVyIGlzIGltcGxpY2l0IGluIGEKIC5GbiBzZW5kIC4KIExvY2FsbHkgZGV0ZWN0ZWQgZXJyb3Jz IGFyZSBpbmRpY2F0ZWQgYnkgYSByZXR1cm4gdmFsdWUgb2YgLTEuCkBAIC0xMzgsMTAgKzE1OCwx NiBAQCBTZWUKIC5YciByZWN2IDIKIGZvciBhIGRlc2NyaXB0aW9uIG9mIHRoZQogLkZhIG1zZ2hk cgorc3RydWN0dXJlIGFuZCB0aGUKKy5GYSBtbXNnaGRyCiBzdHJ1Y3R1cmUuCiAuU2ggUkVUVVJO IFZBTFVFUwotVGhlIGNhbGwgcmV0dXJucyB0aGUgbnVtYmVyIG9mIGNoYXJhY3RlcnMgc2VudCwg b3IgLTEKLWlmIGFuIGVycm9yIG9jY3VycmVkLgorQWxsIGNhbGxzIGV4Y2VwdAorLkZuIHNlbmRt bXNnCityZXR1cm4gdGhlIG51bWJlciBvZiBjaGFyYWN0ZXJzIHNlbnQuIFRoZQorLkZuIHNlbmRt bXNnCitjYWxsIHJldHVybnMgdGhlIG51bWJlciBvZiBtZXNzYWdlcyBzZW50LgorSWYgYW4gZXJy b3Igb2NjdXJyZWQgYSB2YWx1ZSBvZiAtMSBpcyByZXR1cm5lZC4KIC5TaCBFUlJPUlMKIFRoZQog LkZuIHNlbmQKQEAgLTE0OSw2ICsxNzUsOCBAQCBmdW5jdGlvbiBhbmQKIC5GbiBzZW5kdG8KIGFu ZAogLkZuIHNlbmRtc2cKK2FuZAorLkZuIHNlbmRtbXNnCiBzeXN0ZW0gY2FsbHMKIGZhaWwgaWY6 CiAuQmwgLXRhZyAtd2lkdGggRXIKZGlmZiAtLWdpdCBhL3N5cy9zeXMvc29ja2V0LmggYi9zeXMv c3lzL3NvY2tldC5oCmluZGV4IDE4ZTJkZTEuLjVkYTI4NmUgMTAwNjQ0Ci0tLSBhL3N5cy9zeXMv c29ja2V0LmgKKysrIGIvc3lzL3N5cy9zb2NrZXQuaApAQCAtNDMxLDYgKzQzMSw3IEBAIHN0cnVj dCBtc2doZHIgewogI2RlZmluZQlNU0dfTkJJTwkweDQwMDAJCS8qIEZJT05CSU8gbW9kZSwgdXNl ZCBieSBmaWZvZnMgKi8KICNkZWZpbmUJTVNHX0NPTVBBVCAgICAgIDB4ODAwMAkJLyogdXNlZCBp biBzZW5kaXQoKSAqLwogI2RlZmluZQlNU0dfQ01TR19DTE9FWEVDIDB4NDAwMDAJLyogbWFrZSBy ZWNlaXZlZCBmZHMgY2xvc2Utb24tZXhlYyAqLworI2RlZmluZSBNU0dfV0FJVEZPUk9ORQkweDgw MDAwCQkvKiBmb3IgcmVjdm1tc2coKSAqLwogI2VuZGlmCiAjaWZkZWYgX0tFUk5FTAogI2RlZmlu ZQlNU0dfU09DQUxMQkNLICAgMHgxMDAwMAkJLyogZm9yIHVzZSBieSBzb2NrZXQgY2FsbGJhY2tz IC0gc29yZWNlaXZlIChUQ1ApICovCkBAIC01OTUsNiArNTk2LDE2IEBAIHN0cnVjdCBzZl9oZHRy IHsKICNlbmRpZiAvKiBfS0VSTkVMICovCiAjZW5kaWYgLyogX19CU0RfVklTSUJMRSAqLwogCisj aWZkZWYgX19CU0RfVklTSUJMRQorLyoKKyAqIFNlbmQvcmVjdm1tc2cgc3BlY2lmaWMgc3RydWN0 dXJlKHMpCisgKi8KK3N0cnVjdCBtbXNnaGRyIHsKKwlzdHJ1Y3QgbXNnaGRyCW1zZ19oZHI7CQkv KiBtZXNzYWdlIGhlYWRlciAqLworCXNzaXplX3QJCW1zZ19sZW47CQkvKiBtZXNzYWdlIGxlbmd0 aCAqLworfTsKKyNlbmRpZiAvKiBfX0JTRF9WSVNJQkxFICovCisKICNpZm5kZWYJX0tFUk5FTAog CiAjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CkBAIC02MTUsMTIgKzYyNiwxOCBAQCBpbnQJbGlzdGVu KGludCwgaW50KTsKIHNzaXplX3QJcmVjdihpbnQsIHZvaWQgKiwgc2l6ZV90LCBpbnQpOwogc3Np emVfdAlyZWN2ZnJvbShpbnQsIHZvaWQgKiwgc2l6ZV90LCBpbnQsIHN0cnVjdCBzb2NrYWRkciAq IF9fcmVzdHJpY3QsIHNvY2tsZW5fdCAqIF9fcmVzdHJpY3QpOwogc3NpemVfdAlyZWN2bXNnKGlu dCwgc3RydWN0IG1zZ2hkciAqLCBpbnQpOworI2lmIF9fQlNEX1ZJU0lCTEUKK3N0cnVjdCB0aW1l c3BlYzsKK3NzaXplX3QJcmVjdm1tc2coaW50LCBzdHJ1Y3QgbW1zZ2hkciAqIF9fcmVzdHJpY3Qs IHNpemVfdCwgaW50LAorICAgIGNvbnN0IHN0cnVjdCB0aW1lc3BlYyAqIF9fcmVzdHJpY3QpOwor I2VuZGlmCiBzc2l6ZV90CXNlbmQoaW50LCBjb25zdCB2b2lkICosIHNpemVfdCwgaW50KTsKIHNz aXplX3QJc2VuZHRvKGludCwgY29uc3Qgdm9pZCAqLAogCSAgICBzaXplX3QsIGludCwgY29uc3Qg c3RydWN0IHNvY2thZGRyICosIHNvY2tsZW5fdCk7CiBzc2l6ZV90CXNlbmRtc2coaW50LCBjb25z dCBzdHJ1Y3QgbXNnaGRyICosIGludCk7CiAjaWYgX19CU0RfVklTSUJMRQogaW50CXNlbmRmaWxl KGludCwgaW50LCBvZmZfdCwgc2l6ZV90LCBzdHJ1Y3Qgc2ZfaGR0ciAqLCBvZmZfdCAqLCBpbnQp Oworc3NpemVfdAlzZW5kbW1zZyhpbnQsIHN0cnVjdCBtbXNnaGRyICogX19yZXN0cmljdCwgc2l6 ZV90LCBpbnQpOwogaW50CXNldGZpYihpbnQpOwogI2VuZGlmCiBpbnQJc2V0c29ja29wdChpbnQs IGludCwgaW50LCBjb25zdCB2b2lkICosIHNvY2tsZW5fdCk7Cg== --089e01493c12b9cea1052a4e0f84-- From owner-freebsd-threads@freebsd.org Wed Jan 27 10:19:12 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A01AA6F36D for ; Wed, 27 Jan 2016 10:19:12 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E7ACE1EDF for ; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E1701A6F369; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFB7BA6F366; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6647C1EDB; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id 123so144879869wmz.0; Wed, 27 Jan 2016 02:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WC9W5H6mMXiCFJRU9WXALfCSEx5zg39f+zZ4DnRmd48=; b=gPNpyxGaRN6sgZz2ZQHZQfWAq6nyXy8EHAPAeQaTj4wVLscLtvqyICvuGXjpZxWoYk t5X1g0Npzur++LOBv9Ho216+p9uensJHjZddvxoOnf4x7dkI+dC6Vy7zj41L4Njsw5za pAQjuYGaFBS7ncttLcyJcgwccd/Lkn1HBQCP+M6blhO88z28TSYdcsrvll+Pz6igiEzx 7VMK0phhOn8loA7DjB/Xbcyz5Uyajvit0BB3ZPx+EPaTn2mVoSGqutpbir0z4/EmV9Oa Rh6OBSmOjiogNoXowJ3adb/Bj3hUonAIe1W4oJpwnR5235UPSj2kyhnf224AP93UyeWP NsVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WC9W5H6mMXiCFJRU9WXALfCSEx5zg39f+zZ4DnRmd48=; b=G9EgklghR/skg88bGHFGKVCn/BFpSQ7O1POiTzJXbymWpHqc6lFgIAEx30yDij9ZM6 JCDwbHM1L3Mh5RHVADzn85Hsu4I83gAs5daUfqqv0+X/I2WH6ct1LqqaHubaYa7t+C0g g6/Kfj1Y2tlk30fvNSZgmIXetDi2bTH2mbQJco+hszWOYE0/urtDDBGiwhO/qzLGjIM3 ZlUQNi04OIQEtWSZvosF7UuSBTBJ1/g0LL64CuzfYTlMPiTiekanqWpbmmEbjiVucO6e tx03tRuw9GTlrnLyBL8dDIcBHp6sn7g3jmZXT9OgU23O0FjFK3M/hpXyJQJlpEUWFR+A MFIw== X-Gm-Message-State: AG10YOSRhmBJMECUkWGSI6qL0iBMpBbtdtCxikWV6qvv1kGcU9377JC4vs/fU8cokX9MSzFU1sRutFL+jFLuag== MIME-Version: 1.0 X-Received: by 10.194.119.161 with SMTP id kv1mr23282212wjb.135.1453889949887; Wed, 27 Jan 2016 02:19:09 -0800 (PST) Received: by 10.28.136.148 with HTTP; Wed, 27 Jan 2016 02:19:09 -0800 (PST) In-Reply-To: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <20160127132558.W985@besplex.bde.org> Date: Wed, 27 Jan 2016 12:19:09 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Kevin Oberman Cc: Bruce Evans , Gary Jennejohn , Daniel Eischen , threads@freebsd.org, Luigi Rizzo , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 10:19:12 -0000 ba>Is it possible that ppoll() doesn't return an error and yet revents ba>have set either POLLERR or POLLHUP or POLLNVAL? Apart from timeout. On Wed, Jan 27, 2016 at 12:14 PM, Boris Astardzhiev < boris.astardzhiev@gmail.com> wrote: > Hello, > > I've made a few changes in the patch as recommended here starting with > the switch to ppoll(). I have a question since it's not quite clear to me > as written > in the manpage. Is it possible that ppoll() doesn't return an error and > yet revents > have set either POLLERR or POLLHUP or POLLNVAL? > > See patch and comments are again welcomed. > > > On Wed, Jan 27, 2016 at 6:07 AM, Kevin Oberman > wrote: > >> Since this has become a debate on programming style, it seem appropriate >> to mention that Edward Yourdan passed away last Tuesday. For those too >> young to recognize the name, he was the developer of modern structured >> programming. He did recognize the style rules are important, but not >> iron-clad. >> >> Kevin Oberman, Part time kid herder and retired Network Engineer >> E-mail: rkoberman@gmail.com >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >> >> On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans >> wrote: >> >>> On Wed, 27 Jan 2016, Gary Jennejohn wrote: >>> >>> On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >>>> Daniel Eischen wrote: >>>> >>>> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>>>> >>>>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>>>> Luigi Rizzo wrote: >>>>>> >>>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>>>> wrote: >>>>>>> >>>>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>>>> >>>>>>>>> +ssize_t >>>>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, >>>>>>>>> int flags, >>>>>>>>> + const struct timespec *__restrict timeout) >>>>>>>>> +{ >>>>>>>>> + size_t i, rcvd; >>>>>>>>> + ssize_t ret; >>>>>>>>> + >>>>>>>>> + if (timeout != NULL) { >>>>>>>>> + fd_set fds; >>>>>>>>> + int res; >>>>>>>>> >>>>>>>> Please move all local definitions to the beginning of the function. >>>>>>>> >>>>>>> >>>>>>> This style recommendation was from 30 years ago and is >>>>>>> bad programming practice, as it tends to complicate analysis >>>>>>> for the human and increase the chance of improper usage of >>>>>>> variables. >>>>>>> >>>>>>> We should move away from this for new code. >>>>>>> >>>>>> >>>>>> Really? I personally find having all variables grouped together >>>>>> much easier to understand. Stumbling across declarations in the >>>>>> middle of the code in a for-loop, for example, takes me by surprise. >>>>>> >>>>> >>> +1 >>> >>> I used to program in a strict version of the "new" style 25-30 years >>> ago, but learned better. In the strict version, every variable must >>> have minimal scope, so squillions of inner blocks are needed to limit >>> the scopes. Some deeply nested of course. This is a good obfuscation. >>> It even breaks -Wshadow by letting you have unrelated variables named >>> 'i' that don't shadow each other because their scope is limited. Such >>> variables are good in separate functions but not in the same function. >>> Understanding the code to see that the variables are actually unrelated >>> requires counting more braces than usual. If you don't do this >>> strictly then you get a random style with some variables declared at >>> the top and some in inner blocks for mostly historical reasons. A >>> strict style with all of the variables at the top is much easier to >>> write and read. >>> >>> I also greatly dislike initializing variables in their declarations. >>>>>> >>>>>> Maybe I'm just old fashioned since I have been writing C-code for >>>>>> more than 30 years. >>>>>> >>>>> >>>>> +1 >>>>> >>>>> Probably should be discouraged, but allowed on a case-by-case >>>>> basis. One could argue that if you need to declaration blocks >>>>> in the middle of code, then that code is too complex and should >>>>> be broken out into a separate function. >>>>> >>>> >>>> Right. >>>> >>> >>> Lots of inner blocks are good for both making simple code look complex >>> and making it easier to write the complex code in the same function, >>> at least if you use a tiny indentation so that you can have 40 levels >>> of indentation without needing a 500-column terminal. >>> >>> And code like this >>>> >>>> int func(void) >>>> { >>>> int baz, zot; >>>> [some more code] >>>> if (zot < 5) >>>> { >>>> int baz = 3; >>>> [more code] >>>> } >>>> [some more code] >>>> } >>>> >>>> is even worse. The compiler (clang) seems to consider this to >>>> merely be a reinitialization of baz, but a human might be confused. >>>> >>> >>> No, that is a different baz, and is warned about by Wshadow. >>> >>> Something like for (int i = 0; i < 2; i++) is IMHO OK. >>>> >>> >>> Except it is C++ style which is so forbidden that style(9) doesn't >>> know that it needs a rule to forbid it. >>> >>> The worst is C++ style that doesn't limit the scope -- a bunch of >>> variables at the top and then somewhere in the middle of the function >>> another variable is needed and it is declared at top level of the >>> function scope. I sometimes do this when in a hurry. The strict >>> K&R-C90 style requires opening an inner block to do little more than >>> hold the declaration and then (re)indenting and (re)formatting all >>> the code in the inner block. The C++ style reduces writability and >>> readability in a different way. It doesn't cause excessive indentation >>> but it doesn't limit the scope much differently than putting all the >>> declarations at the top. At least the reader can find the declarations >>> easily when they are at the top. >>> >>> Bruce >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> > From owner-freebsd-threads@freebsd.org Wed Jan 27 20:02:39 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C4B0A7055B for ; Wed, 27 Jan 2016 20:02:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 114271B25 for ; Wed, 27 Jan 2016 20:02:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1060DA70559; Wed, 27 Jan 2016 20:02:39 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBD0AA70558; Wed, 27 Jan 2016 20:02:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95B9A1B24; Wed, 27 Jan 2016 20:02:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0RK2VUL030962 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Jan 2016 22:02:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0RK2VUL030962 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0RK2U3D030960; Wed, 27 Jan 2016 22:02:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Jan 2016 22:02:30 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: Kevin Oberman , Daniel Eischen , Gary Jennejohn , "freebsd-net@freebsd.org" , threads@freebsd.org, Luigi Rizzo Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160127200230.GG74231@kib.kiev.ua> References: <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <20160127132558.W985@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 20:02:39 -0000 On Wed, Jan 27, 2016 at 12:14:02PM +0200, Boris Astardzhiev wrote: > Hello, > > I've made a few changes in the patch as recommended here starting with > the switch to ppoll(). I have a question since it's not quite clear to me > as written > in the manpage. Is it possible that ppoll() doesn't return an error and yet > revents > have set either POLLERR or POLLHUP or POLLNVAL? Ppoll() returned error means that the error is global for the syscall, i.e. the whole syscall execution was either impossible due to invalid parameters, or external event like signal delivery interrupted the execution. Individual file descriptors events like POLLHUP (EOF detected) or POLLNVAL (fd closed meantime) or POLLERR (whatever meaning the file type is provided for exceptional and not error situation) are not global errors. > +#include > +__FBSDID("$FreeBSD$"); > + > +#include > +#include > +#include > +#include Order sys/*.h alphabetically, except sys/types.h which comes first. Note that poll.h and stddef.h are not sys/, at least not for userspace consumers. > +#include "libc_private.h" > + > +#define POLLMASK (POLLIN | POLLRDNORM | POLLRDBAND | POLLPRI) > +#define EPOLLMASK (POLLERR | POLLHUP | POLLNVAL) I do not like these definitions which are used once. They only make reading the code harder. I do not think that it is needed to check for EPOLLMASK. POLLHUP or POLLERR would result in the corresponding action on recvmsg(2), while you cannot realistically replicate the kernel logic to report the state, so it is better to delegate the handling to kernel. POLLNVAL means that the file descriptor was either invalid outright or closed during the call, i.e. a bug in the caller. > + > +ssize_t > +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, > + const struct timespec *__restrict timeout) > +{ > + struct pollfd pfd[1]; > + size_t i, rcvd; > + ssize_t ret; > + int res; > + > + if (timeout != NULL) { > + pfd[0].fd = s; > + pfd[0].events = POLLMASK; > + pfd[0].revents = 0; > + res = ppoll(&pfd[0], 1, timeout, NULL); > + if (res == -1 || res == 0) > + return (res); > + if (pfd[0].revents & EPOLLMASK || > + (pfd[0].revents & POLLMASK) == 0) > + return (-1); > + } Fix the poll use and hopefully the patch is finished. Do you have any tests written ? Please provide me the tests. From owner-freebsd-threads@freebsd.org Wed Jan 27 22:29:28 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B2AFA6F6BC for ; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2500C1244 for ; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 20621A6F6B8; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04D42A6F6B6; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id E1B5C1241; Wed, 27 Jan 2016 22:29:27 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8001:cee1:c548:2788:e3cb:8a45]) by elvis.mu.org (Postfix) with ESMTPSA id 779D4345A921; Wed, 27 Jan 2016 14:29:27 -0800 (PST) Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? To: Luigi Rizzo , gljennjohn@gmail.com References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> Cc: Daniel Eischen , threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" From: Alfred Perlstein Organization: FreeBSD Message-ID: <56A944C6.1040603@freebsd.org> Date: Wed, 27 Jan 2016 14:29:26 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 22:29:28 -0000 On 1/26/16 4:39 PM, Luigi Rizzo wrote: > On Tue, Jan 26, 2016 at 4:31 PM, Gary Jennejohn wrote: >> On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >> Daniel Eischen wrote: >> >>> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>> >>>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>> Luigi Rizzo wrote: >>>> >>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>> wrote: >>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>>> +ssize_t >>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >>>>>>> + const struct timespec *__restrict timeout) >>>>>>> +{ >>>>>>> + size_t i, rcvd; >>>>>>> + ssize_t ret; >>>>>>> + >>>>>>> + if (timeout != NULL) { >>>>>>> + fd_set fds; >>>>>>> + int res; >>>>>> Please move all local definitions to the beginning of the function. >>>>> This style recommendation was from 30 years ago and is >>>>> bad programming practice, as it tends to complicate analysis >>>>> for the human and increase the chance of improper usage of >>>>> variables. >>>>> >>>>> We should move away from this for new code. >>>>> >>>> Really? I personally find having all variables grouped together >>>> much easier to understand. Stumbling across declarations in the >>>> middle of the code in a for-loop, for example, takes me by surprise. >>>> >>>> I also greatly dislike initializing variables in their declarations. >>>> >>>> Maybe I'm just old fashioned since I have been writing C-code for >>>> more than 30 years. >>> +1 >>> >>> Probably should be discouraged, but allowed on a case-by-case >>> basis. One could argue that if you need to declaration blocks >>> in the middle of code, then that code is too complex and should >>> be broken out into a separate function. >>> >> Right. >> >> And code like this >> >> int func(void) >> { >> int baz, zot; >> [some more code] >> if (zot < 5) >> { >> int baz = 3; >> [more code] >> } >> [some more code] >> } >> >> is even worse. The compiler (clang) seems to consider this to >> merely be a reinitialization of baz, but a human might be confused. > oh please... :) > > This is simply an inner variable shadowing the outer one > (which is another poor practice, flagged with -Wshadow ). > When you exit the scope you get the external variable > with its value, as you can see from the following code. > > #include > int main(int ac, char *av[]) > { > int baz = 5; > printf("1 baz %d\n", baz); > { > int baz = 3; > printf("2 baz %d\n", baz); > } > printf("3 baz %d\n", baz); > return 0; > } > I agree wholeheartedly with Luigi. I am also surprised that shadowed variable warnings was not more widely understood. It's time to move forward and make the code more readable and maintainable. Having scoped variables just makes sense. It's true that if you see very many of them, then it's likely time to introduce separate functions, but only in extreme cases, not on a case-by-case basis. -Alfred From owner-freebsd-threads@freebsd.org Thu Jan 28 00:43:26 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5BDEA6F61B for ; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CCC7A19EE for ; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C97D8A6F619; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8CC8A6F616; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0E4419EA; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u0S0hIuW028478; Wed, 27 Jan 2016 19:43:18 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 27 Jan 2016 19:43:18 -0500 (EST) Date: Wed, 27 Jan 2016 19:43:18 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Alfred Perlstein cc: Luigi Rizzo , gljennjohn@gmail.com, threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <56A944C6.1040603@freebsd.org> Message-ID: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <56A944C6.1040603@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 00:43:27 -0000 On Wed, 27 Jan 2016, Alfred Perlstein wrote: > > > On 1/26/16 4:39 PM, Luigi Rizzo wrote: >> On Tue, Jan 26, 2016 at 4:31 PM, Gary Jennejohn >> wrote: >>> On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >>> Daniel Eischen wrote: >>> >>>> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>>> >>>>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>>> Luigi Rizzo wrote: >>>>> >>>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>>> wrote: >>>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>>>> +ssize_t >>>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int >>>>>>>> flags, >>>>>>>> + const struct timespec *__restrict timeout) >>>>>>>> +{ >>>>>>>> + size_t i, rcvd; >>>>>>>> + ssize_t ret; >>>>>>>> + >>>>>>>> + if (timeout != NULL) { >>>>>>>> + fd_set fds; >>>>>>>> + int res; >>>>>>> Please move all local definitions to the beginning of the function. >>>>>> This style recommendation was from 30 years ago and is >>>>>> bad programming practice, as it tends to complicate analysis >>>>>> for the human and increase the chance of improper usage of >>>>>> variables. >>>>>> >>>>>> We should move away from this for new code. >>>>>> >>>>> Really? I personally find having all variables grouped together >>>>> much easier to understand. Stumbling across declarations in the >>>>> middle of the code in a for-loop, for example, takes me by surprise. >>>>> >>>>> I also greatly dislike initializing variables in their declarations. >>>>> >>>>> Maybe I'm just old fashioned since I have been writing C-code for >>>>> more than 30 years. >>>> +1 >>>> >>>> Probably should be discouraged, but allowed on a case-by-case >>>> basis. One could argue that if you need to declaration blocks >>>> in the middle of code, then that code is too complex and should >>>> be broken out into a separate function. >>>> >>> Right. >>> >>> And code like this >>> >>> int func(void) >>> { >>> int baz, zot; >>> [some more code] >>> if (zot < 5) >>> { >>> int baz = 3; >>> [more code] >>> } >>> [some more code] >>> } >>> >>> is even worse. The compiler (clang) seems to consider this to >>> merely be a reinitialization of baz, but a human might be confused. >> oh please... :) >> >> This is simply an inner variable shadowing the outer one >> (which is another poor practice, flagged with -Wshadow ). >> When you exit the scope you get the external variable >> with its value, as you can see from the following code. >> >> #include >> int main(int ac, char *av[]) >> { >> int baz = 5; >> printf("1 baz %d\n", baz); >> { >> int baz = 3; >> printf("2 baz %d\n", baz); >> } >> printf("3 baz %d\n", baz); >> return 0; >> } >> > I agree wholeheartedly with Luigi. I am also surprised that shadowed > variable warnings was not more widely understood. > > It's time to move forward and make the code more readable and maintainable. > Having scoped variables just makes sense. It's true that if you see very > many of them, then it's likely time to introduce separate functions, but only > in extreme cases, not on a case-by-case basis. -1 It certainly doesn't make it more readable for me. It seems like it is done out of sheer laziness as opposed to structuring the code better. -- DE From owner-freebsd-threads@freebsd.org Thu Jan 28 23:31:55 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 117019D9A87 for ; Thu, 28 Jan 2016 23:31:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC8F017EE for ; Thu, 28 Jan 2016 23:31:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0SNVski062022 for ; Thu, 28 Jan 2016 23:31:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Thu, 28 Jan 2016 23:31:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 23:31:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #15 from rblayzor@inoc.net --- After installing a new world and booting to new root NFS. I've seen one cra= sh (usually takes time). However this one is a bit odd. Kernel message: Failed to write core file for process exim (error 14) pid 58267 (exim), uid 26: exited on signal 11 But I do get a core file, but this is all: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `exim'. Program terminated with signal 11, Segmentation fault. Cannot access memory at address 0x800978ac0 #0 0x00000008023a2990 in ?? () (gdb) bt full #0 0x00000008023a2990 in ?? () No symbol table info available. Cannot access memory at address 0x7fffffff4f70 (gdb) bt info No symbol "info" in current context. (gdb) x/i $rip 0x8023a2990: Cannot access memory at address 0x8023a2990 (gdb) info registers rax 0xffffffffffffffd0 -48 rbx 0x2010 8208 rcx 0x800788330 34367636272 rdx 0x0 0 rsi 0x3ff3 16371 rdi 0x8030033c1 34410083265 rbp 0x7fffffff5420 0x7fffffff5420 rsp 0x7fffffff4f70 0x7fffffff4f70 r8 0x7fffffff4670 140737488307824 r9 0x80269f6e0 34400237280 r10 0xfffffffffffff000 -4096 r11 0x8030033c0 34410083264 r12 0x7fffffffed40 140737488350528 r13 0x803229000 34412335104 r14 0x2010 8208 r15 0x3000 12288 rip 0x8023a2990 0x8023a2990 eflags 0x10206 66054 cs 0x43 67 ss 0x3b 59 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Fri Jan 29 18:44:13 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D029A72977 for ; Fri, 29 Jan 2016 18:44:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E3331469 for ; Fri, 29 Jan 2016 18:44:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0TIiDIa019635 for ; Fri, 29 Jan 2016 18:44:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Fri, 29 Jan 2016 18:44:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 18:44:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #16 from John Baldwin --- Hmm, the EFAULT error (14) is quite odd. I wonder if you tripped over the = bug that is fixed in HEAD by r287442, r287537, and r288944. That bug was present in 10.1 though (and 10.0), not unique to 10.2. Howeve= r, a corrupted core dump is why you can't do a full backtrace. :( --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Fri Jan 29 19:15:29 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C655FA722DC for ; Fri, 29 Jan 2016 19:15:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7B7711E3 for ; Fri, 29 Jan 2016 19:15:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0TJFTfo016300 for ; Fri, 29 Jan 2016 19:15:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Fri, 29 Jan 2016 19:15:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 19:15:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #17 from rblayzor@inoc.net --- I'm not claiming that the bug here that I've reported does not exist in 10.= 0 or 10.1, I'm just saying that we've seen this bug during our entire release cy= cle of 10.1. (which was almost a good year). We only started noticing this issue with process seg faults after updating = to 10.2. We were running the same versions of Dovecot and Exim on 10.1 when we started noticing it in 10.2. That's when we force rebuilt all of the binari= es under 10.2 to no avail. Dovecot and Exim are NOT the only processes that we've seen core out, they = are just the processes we see the most often. I've seen cron do it, ntpd and so= me other port binaries. I remember looking at their core files and seeing the = same "cannot access memory" errors in the backtrace. It was only then I started paying attention more and have been gathering more and more debug informati= on on this strange issue. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Fri Jan 29 19:16:32 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BF5AA72349 for ; Fri, 29 Jan 2016 19:16:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D7A0123A for ; Fri, 29 Jan 2016 19:16:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0TJGWbp017747 for ; Fri, 29 Jan 2016 19:16:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Fri, 29 Jan 2016 19:16:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 19:16:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #18 from rblayzor@inoc.net --- (In reply to rblayzor from comment #17) Should read "I'm just saying that we've NEVER seen this bug during our enti= re release cycle of 10.1." --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Fri Jan 29 19:50:01 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC63EA72E59 for ; Fri, 29 Jan 2016 19:50:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6DAF1033 for ; Fri, 29 Jan 2016 19:50:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0TJo1Zs081621 for ; Fri, 29 Jan 2016 19:50:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Fri, 29 Jan 2016 19:50:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 19:50:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #19 from John Baldwin --- Oh, I should be clear that the revisions I mentioned only address the issue= of core dumps being corrupt, it does not address the root cause of the seg fau= lts you are seeing. However, having proper core dumps is needed to debug the r= oot cause. You can try backporting the changes I mentioned previously to your 10.2 ker= nel (you can get by with just the first two for testing) to see if we can get m= ore usaable core dumps to use in tracking down the root cause. If you aren't u= sed to backporting changes I will try to do it in the next day or so (those fix= es should be in 10.3 anyway). Once I've done the backport I can give you a pa= tch to apply to your 10.2 kernel. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Fri Jan 29 20:27:06 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6996A72B56 for ; Fri, 29 Jan 2016 20:27:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D91761FBC for ; Fri, 29 Jan 2016 20:27:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0TKR6Vw094815 for ; Fri, 29 Jan 2016 20:27:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Fri, 29 Jan 2016 20:27:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 20:27:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #20 from rblayzor@inoc.net --- These broken cores do not happen all the time, I'm actually waiting for some crashes to report. I'm pretty sure I should see a couple in the coming days= .=20 If I keep having broken cores with no useful output I already checked out 10-STABLE and have it lined up to possibly try building a new NFS_ROOT syst= em. (though that may take some time). I would rather wait now while I have latest 10.2 running to at least see if= I can grab some useful debugs. --=20 You are receiving this mail because: You are the assignee for the bug.=