svn commit: r322258 - head/sys/kern

[Alan Somers]

On Fri, Aug 25, 2017 at 9:00 PM, Bruce Evans <brde at optusnet.com.au> wrote:
> On Thu, 24 Aug 2017, Alan Somers wrote:
>
>> On Wed, Aug 9, 2017 at 1:05 AM, Bruce Evans <brde at 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.

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 <limits.h> 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