Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3668561ybi; Mon, 29 Jul 2019 10:26:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqzJBqiO041NA42xC+aVlJhwoP1nO5I1DFoHP4fok7yN/wjbKdvUkMN6IOJHKpWcVIcJLpt/ X-Received: by 2002:aa7:8817:: with SMTP id c23mr38189837pfo.146.1564421176544; Mon, 29 Jul 2019 10:26:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564421176; cv=none; d=google.com; s=arc-20160816; b=XgDNGC2JYN11e+N6+gV+b/PYCPx8eq8eIgyzIXPgCmERlfobmqT0vttP+FVLO2ipa3 /hgoQpXrOFeb61quPH9udQTPnJuqNN3l4o5PWhvd0oGlHvJYOqCMjolsb2lYvwOh0uid 1oRvb/C5q8uLaUgalZ/IbZCe9TucttsFdqg0IDUHNnAuQn37y3Ap7Qn3V3yhvcBAgCui dh5enIyurhAYSRLYObkcpX5TIOgwweSdOEjlUz5WlfzkH7zO/YI8pyqIi0xpLH0engPQ TsmpjrXD6bBNdtL1g1FC21TImepPh3peq2BkYNC5DR0QRNVf5KsMFAkq8GPLvcPTeaQp UYww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=07qBSDcGsxkcoM1ntqjTIvB/KWKvXAEcQspNtrjmZBg=; b=LeuxHeU1o2qP5jDOyyMSGEl4z17tX0Lf6LuRHFwPneHlEj0MBetBHJlShIj9W0pmAN IFs/bFc8XkXC6RkVVZGDY6iADMH1LQzOQ/Y/xXiYp/0HaQrcaPbxdCgXviJoVPINTRhd NZR+PROR89lOjQtpvkDPX9EXM7vYgtuWTlpQa/KLNpJe2yWn5RunlBZ93+Ux1vOinubp FpuHNeB08dYhRjCGV8ccl/jykyvr/JiqKTAQy2P6R0pO3LC3rY7vg3N+hAm6h2wzdpmo 1dzdGgH0/piuHsaCrVDqy3ND5+3Jt9eBGR8fIlLo74fh0q+fpNo2eQ73t2YdlgFOaxkf X0pQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h1si24544384pls.183.2019.07.29.10.26.01; Mon, 29 Jul 2019 10:26:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387899AbfG2NXz (ORCPT + 99 others); Mon, 29 Jul 2019 09:23:55 -0400 Received: from netrider.rowland.org ([192.131.102.5]:58787 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S2387413AbfG2NXy (ORCPT ); Mon, 29 Jul 2019 09:23:54 -0400 Received: (qmail 21810 invoked by uid 500); 29 Jul 2019 09:23:53 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Jul 2019 09:23:53 -0400 Date: Mon, 29 Jul 2019 09:23:53 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: "Michael Kerrisk (man-pages)" cc: linux-man@vger.kernel.org, Kernel development list Subject: Re: Error (?) in man page for ppoll(2) In-Reply-To: <4ce02b01-f174-99a1-ac34-21a2c6414df2@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Jul 2019, Michael Kerrisk (man-pages) wrote: > Hello Alan, > > On 7/21/19 5:32 PM, Alan Stern wrote: > > Here are two extracts from the man page for ppoll(2) (from the > > man-pages 4.16 package; the 5.01 version is the same): > > > > Specifying a negative value in timeout means an infinite timeout. > > > > > > Other than the difference in the precision of the timeout argument, the > > following ppoll() call: > > > > ready = ppoll(&fds, nfds, tmo_p, &sigmask); > > > > is equivalent to atomically executing the following calls: > > > > sigset_t origmask; > > int timeout; > > > > timeout = (tmo_p == NULL) ? -1 : > > (tmo_p->tv_sec * 1000 + tmo_p->tv_nsec / 1000000); > > pthread_sigmask(SIG_SETMASK, &sigmask, &origmask); > > ready = poll(&fds, nfds, timeout); > > pthread_sigmask(SIG_SETMASK, &origmask, NULL); > > > > But if tmo_p->tv_sec is negative, the ppoll() call is not equivalent to > > the corresponding poll() call. The kernel rejects negative values of > > tv_sec with an EINVAL error; it does not interpret the value as meaning > > an infinite timeout. > > > > (Yes, the kernel interprets tmo_p == NULL as an infinite timeout, but > > the man page is still wrong for the case tmo_p->tv_sec < 0.) > > > > Suggested fix: Following the end of the second extract above, add: > > > > except that negative time values in tmo_p are not interpreted > > as an infinite timeout. > > > > Also, in the ERRORS section, change the text for EINVAL to: > > > > EINVAL The nfds value exceeds the RLIMIT_NOFILE value or > > *tmo_p contains an invalid (negative) time value. > > Thanks for the report, and the text change suggestions. > I've applied the patch below. > > Thanks, > > Michael > > diff --git a/man2/poll.2 b/man2/poll.2 > index 0b023e0a5..3eacb88b7 100644 > --- a/man2/poll.2 > +++ b/man2/poll.2 > @@ -271,7 +271,7 @@ ready = ppoll(&fds, nfds, tmo_p, &sigmask); > .EE > .in > .PP > -is equivalent to > +is nearly equivalent to > .I atomically > executing the following calls: > .PP > @@ -288,6 +288,17 @@ pthread_sigmask(SIG_SETMASK, &origmask, NULL); > .EE > .in > .PP > +The above code segment is described as > +.I nearly > +equivalent because whereas a negative > +.I timeout > +value for > +.BR poll () > +is interpreted as an infinite timeout, a negative value expressed in > +.IR *tmo_p > +results in an error from > +.BR ppoll (). > +.PP > See the description of > .BR pselect (2) > for an explanation of why > @@ -354,6 +365,12 @@ value exceeds the > .B RLIMIT_NOFILE > value. > .TP > +.B EINVAL > +.RB ( ppoll ()) > +The timeout value expressed in > +.IR *ip > +is invalid (nragtive). ----------------^^^ Typo. Otherwise, I approve of the patch. Thank you, Alan > +.TP > .B ENOMEM > There was no space to allocate file descriptor tables. > .SH VERSIONS