From owner-freebsd-hackers@freebsd.org Wed Feb 28 09:40:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49AA0F38683 for ; Wed, 28 Feb 2018 09:40:50 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 B8C746E3F5 for ; Wed, 28 Feb 2018 09:40:49 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x234.google.com with SMTP id v111so1660755wrb.3 for ; Wed, 28 Feb 2018 01:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=28TZZRSRce2QwWaKn0mQqerpESIB9a2ydoyhywymPYs=; b=QMQ5H81kq8AgslJ57ySW1+TWuvSzTcEjHIcDGIc/qrDes1EJBcYGdbF1mXMw7J7rkO heYFMuRUeob7HAoJQe6SPa2CZCtm7NxNsbA8UebfS6XIRoXZ/V1IuAKQ+ErTsWAWve6G L1NWn7eRLrSRsO7tF9pApC9Hw6jNIZaHrBNl7VAqhAYFvpWiRYz5Cm2iZ2PBdmM4zAq2 /BzrBkNpAFgIO5ghpfTGCMJq2U2nIfYf2/X8TWmF2eDBC+cbqKSIYhlB3hiXpUIAX3Nv haIXKbltZGzRbdYnx0j883qPPOsxsPGlFKro4tjIGoFdvLuAaL/vyf//855NwbHkXp+f ZG/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=28TZZRSRce2QwWaKn0mQqerpESIB9a2ydoyhywymPYs=; b=l3VA6Vi+bHwtxIqN/MxT2bTOYAOjLoPhIimRWVVz5iVX3Xwe24jKAg5DwYiu/SwdcX FVHU1q50kadRmpFbYM0pSDjHckVUxAvLzYdhhWu599LZkaYTr7POZT+oBoSo0BJmloBm /sSj2EqDZyDRggDEXIl/0/LfeuX1iZXZ1XGG238oUINrkIbE1dnLcIxLgyg3I5hwU3jE sv9iSDGpp4KU89swoaNGkqzk/lgG79PvYnnpqKWhsf+5Lb47B77QtpLE41iaAJSYCFc3 EYb8hew4Pb/FN+ha+CzhrWnEGN7CiU6SyciYy3khK+++83glpqSa0vYpgXEoY6KDYr9w 95aA== X-Gm-Message-State: APf1xPB4m+6tPeNTdQkUzoQp2NllH/fiGl7lyErd71bHjiHnpkPyrvaV OuTQ2B6ES0r007gdnkhwqncrOA== X-Google-Smtp-Source: AH8x224H9wGN2VFM0cjamePvmv5sNoz4gsmLfojPk3OLjYg4Xx19fiSQiMDJxZ9fic+GtWPwp2hjRA== X-Received: by 10.223.191.10 with SMTP id p10mr16459113wrh.160.1519810848407; Wed, 28 Feb 2018 01:40:48 -0800 (PST) Received: from ernst.home (p5B02321F.dip0.t-ipconnect.de. [91.2.50.31]) by smtp.gmail.com with ESMTPSA id b136sm1052938wme.34.2018.02.28.01.40.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 28 Feb 2018 01:40:47 -0800 (PST) Date: Wed, 28 Feb 2018 10:40:39 +0100 From: Gary Jennejohn To: Chris Torek Cc: freebsd-hackers@freebsd.org Subject: Re: Marking select(2) as restrict Message-ID: <20180228104039.1680ca80@ernst.home> In-Reply-To: <201802272230.w1RMUOmL079462@elf.torek.net> References: <20180227210110.GA76452@stack.nl> <201802272230.w1RMUOmL079462@elf.torek.net> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 09:40:50 -0000 On Tue, 27 Feb 2018 14:30:24 -0800 (PST) Chris Torek wrote: > If we can back up a bit, there are (at least) two mostly-separate > issues: > > * What types and qualfiiers to use for various parameters: > These are dictated by standards, and we should just conform > to whatever is in the standard unless there's some major > reason to do otherwise. > > POSIX says that we *should* use "restrict" here: > http://pubs.opengroup.org/onlinepubs/009696699/functions/pselect.html > > so if no one has a major reason to do otherwise (such as > "no conforming program can tell that we didn't and all it will > achieve is nothing" :-) ) I'd say add the restrict. > > (As kib and others have noted, it achieves a lot of nothing, so > the priority for this particular conformance seems low.) > > * Select itself: it makes no sense *in the caller* to pass > the same &fd_set argument to more than one parameter unless > they are all input-only. The kernel is going to write on them, > and there is no guarantee that the kernel will write them in any > particular order. Hence if you write: > > ret = select(nfds, &a, &a, &a, timeout); > > you are nearly guaranteed to have a bug: this call can only > be correct if the only value you intend to inspect is "ret". > > (That, in fact, is what devd was doing: if ret==0, daemonize, > and in any case throw away the returned results in the by-pointer > arguments. Hence not a bug -- unless ... well, read on.) > > The remaining question is: can even that be correct? In > particular, should the kernel be required to use copy-in/copy-out > semantics, or can it do the equivalent (minus error checking > and a lot of other important details) of: > > int select(int nfds, fd_set *in, fd_set *out, fd_set *ex, > struct timeval *tvp) { > some_complicated_type v_in, v_out, v_ex; > > v1 = op(*in); > *in = function(v1); > v2 = op(*out); > ... > } > > ? If the latter is *permitted*, then the call passing "&a" > three times is *always* wrong, since *in might have been > clobbered before *out is ever loaded. If a program breaks > because it was doing this, well, it was already broken, we were > just lucky that it worked anyway. (Was this good luck, or bad > luck? :-) ) > > Currently, the kernel does in fact copy them all in, > then futz with them, then copy them all out (for good reasons). > So the devd usage always works. But will the kernel *always* > do this, or is that an accident of the implementation? > Linux also does a copyin (copy_from_user) of each FD_SET. Linux also does not use restrict in select. It would be a very bad design decision to not copy each FD_SET separately into the kernel. > If the kernel *is* always going to do this, the documentation > should say so, at which point the POSIX requirement for the > restrict on the parameter is itself a bug (as far as BSD is > concerned). That would call for feature test macros around > the declaration. > > So, if we declare that select(nfds, &a, &a, &a, timeout) *is* > legal and meaningful in BSD, *don't* just put in the restrict: > use feature test macros as appropriate to handle any conformance > issues. But please also update select(2) to call out when this > is OK (e.g., in devd's particular use case). > It would be good to explicitly state that it is only safe to use pointers to a single FD_SET when only the error return is of interest and the results in the FD_SET will be ignored. -- Gary Jennejohn