Date: Sat, 26 Aug 2017 13:00:41 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Alan Somers <asomers@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r322258 - head/sys/kern Message-ID: <20170826121557.K2180@besplex.bde.org> In-Reply-To: <CAOtMX2jS2SdN9mgbu0E_9WytCMFYUeZ6RPg=EGcAFe%2BBj17=TA@mail.gmail.com> References: <201708081614.v78GEVGY066448@repo.freebsd.org> <20170809141608.I1096@besplex.bde.org> <CAOtMX2jS2SdN9mgbu0E_9WytCMFYUeZ6RPg=EGcAFe%2BBj17=TA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Aug 2017, Alan Somers wrote:
> On Wed, Aug 9, 2017 at 1:05 AM, Bruce Evans <brde@optusnet.com.au> 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 <limits.h> or <unistd.h>".
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
<limits.h> 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 <limits.h> 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 <limits.h>
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 <limits.h> (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.
Anything that removes the compile time limit is good. Except actually
removing it from <limits.h> would break any applications that use it.
Applications should use the minimum for the limit if they don't care,
else sysconf().
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170826121557.K2180>