From owner-svn-src-all@freebsd.org Mon Aug 28 17:40:24 2017 Return-Path: Delivered-To: svn-src-all@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 A0337E10E0E; Mon, 28 Aug 2017 17:40:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 59A758214A; Mon, 28 Aug 2017 17:40:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-wr0-x22d.google.com with SMTP id j29so2740504wre.2; Mon, 28 Aug 2017 10:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KYxrvCWzwidKSqRjHKLo7LlYuJcSD3Sg+EAQzyRYo9k=; b=kHgLKpvMJOdFSEwlDdADbWZEJw8bQxWTbmp19gWDVFb2REmB31PLbJwSJL4oL4ifND sY05eklaOIhE2fhGdiNTSv6aURjCYxEesrzW/mS6/dbtpeEzS7ohTRPjKzXmPuP0s13V 84/VorjGG19x+I9PLiKKFiYZje/JMyXJNSiigpI66N29JGBoBpCO1xXj4TgwfDrvKazo JKcdGlG/fyEE9KNOyHUHFnySewxfKeGdQbE+/r+yBR/rLiGx2E6AQncsni21/mcKbCzy mhZPA4fD7qWxvR/uDQMkBoxiTsH+5Q2qdo+uldq05thOUI+tpGQSqbOwDAZ+HiLWW/i7 w1sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KYxrvCWzwidKSqRjHKLo7LlYuJcSD3Sg+EAQzyRYo9k=; b=q4Dbltdwq8nrjg7h8hMkNovVMgq3nXZlnqv11RzWSOk6i9NYram6gIBChhGKxSshWu zD121I3qZc7Tux/G8sNVpdPZh+WVWRHE4kdqmh24aDFbtxcCy+g3Dv9WChSiawy0b9W6 nh//G/khoa6U1YZyvOV8g3IqU46fDHkgIC+wt+Wi+rUM14/T84g7Ak89UU53RhngEU5e HIGNM3chbktpvHkCsZpy7Oq0aRlPwnwaDYCdK5xOgu+L/Shn/K97Z7pDfKulECBNtNrQ BLvhI7RF5wrxHQr7mGDAVD1YhAnSJEraRSRnz5Edd0NVgSvGgiLppVFRkfRSxE3VkEwA lAbw== X-Gm-Message-State: AHYfb5gn5XbAnv/hjnstIlVwMx/kVjNq/T5EnxaZ85wyj1bCeOrgV6/G PHEYYq4SXHG1+SO3ZwtZjRSX6BSqmg== X-Received: by 10.223.129.41 with SMTP id 38mr1031831wrm.324.1503942022646; Mon, 28 Aug 2017 10:40:22 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.28.56.194 with HTTP; Mon, 28 Aug 2017 10:40:22 -0700 (PDT) In-Reply-To: <20170826121557.K2180@besplex.bde.org> References: <201708081614.v78GEVGY066448@repo.freebsd.org> <20170809141608.I1096@besplex.bde.org> <20170826121557.K2180@besplex.bde.org> From: Alan Somers Date: Mon, 28 Aug 2017 11:40:22 -0600 X-Google-Sender-Auth: SpbkQbiTxavjOhRh5Z-esfJSQes Message-ID: Subject: Re: svn commit: r322258 - head/sys/kern To: Bruce Evans Cc: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 17:40:24 -0000 On Fri, Aug 25, 2017 at 9:00 PM, Bruce Evans wrote: > On Thu, 24 Aug 2017, Alan Somers wrote: > >> On Wed, Aug 9, 2017 at 1:05 AM, Bruce Evans wrote: >>> >>> On Tue, 8 Aug 2017, Alan Somers wrote: >>> ... >>> The compile-time definition of AIO_LISTIO_MAX seems to be broken. I >>> think >>> POSIX species that AIO_LISTIO_MAX shall not be defined if the value of >>> {AIO_LISTIO_MAX} varies at runtime, but it is still defined. FreeBSD >>> has this bug for many other sysconf() variables, e.g., {OPEN_MAX}. >>> Perhaps AIO_LISTIO_MAX is easier to fix since it is not hard-coded as >>> often as OPEN_MAX. >> >> >> What you describe is Linux's behavior, but the POSIX requirement is a >> bit more general. All POSIX says is that "The value returned [by >> sysconf(3)] shall not be more restrictive than the corresponding value >> described to the application when it was compiled with the >> implementation's or ". > > > No, I described the POSIX requirement. See the section on limits.h. It > says that > - {AIO_LISTIO_MAX} is a runtime invariant (so sysctls that change it are > not POSIX conformant) > - for all runtime invariant limits, the definition shall be omitted from > if it is unspecified (sic). This indetermination (sic) > might depend on the memory size. [That was not a direct quote > except for the sic words. POSIX says "indeterminate" in both places > in the 1990 and 1996 versions, but this is broken in the 2001 and 2006 > versions.] > So defining AIO_LISTIO_MAX in is not conformant if you change > it before runtime using something like a tunable. > > You quoted the section for sysconf(3). The wording there is too generic. > It covers both runtime increasable and runtime invariant limits. It > only really applies to the runtime increasable limits. For the runtime > invariant, limits it only applies vacuously. The section on > disallows defining runtime invariant limits unless they are known at > compile time. If they would be different at runtime, then they were not > known at comple time, so must not be defined then, and the requirement > that the runtime limits are larger is vacuously satisfied. > > There aren't many runtime increasable limits, and at least in the 2006 > version, only {OPEN_MAX} is allowed to vary within a process's lifetime. > {OPEN_MAX} can be decreased in practice and the 2006 version doesn't > disallow this provided OPEN_MAX is not defined in (then > {OPEN_MAX} must be a compile-time invariant). When it is not defined, > the requirement to only increase it is vacuously satisfied, so only > the special requirement for {OPEN_MAX} applies. This allows changing > it using setrlimit(). The direction of the change is not limited to > an increase, but many more paragraphs are needed to speciy what happens > when it does decrease (open files above the limit stay open, but > obviously you can't use the current limit to limit the search for these > files...). > >> ... > > >> I dug deeper and found that there wasn't any good reason for the >> aio_listio_max limit to exist in the first place. This DR eliminates >> it, which I think will satisfy most of your concerns. >> https://reviews.freebsd.org/D12120 > > > This is inconvenient for me to review. Could you please try using Phabricator? It's great; I promise. It's also the project's designated code review tool. As one of our most prolific code reviewers, you really ought to start using it. It's useful for both precommit and postcommit review, and the workflow is much better than using email alone. > > Anything that removes the compile time limit is good. Except actually > removing it from would break any applications that use it. > Applications should use the minimum for the limit if they don't care, > else sysconf(). So you're happy to leave AIO_LISTIO_MAX in limits.h as if it were a runtime increasable limit? That provides the best compatibility for legacy applications. > > The 2006 version of POSIX says in its section about profiles that most > if its limits are inadequate (so profiles should change them). I > don't know the mechanism for this. Just omitting most compile-time > limits and increasing the sysconf() limits won't help for sloppy > applications. > > Bruce