On Thu, 24 Aug 2017, Alan Somers wrote:

On Wed, Aug 9, 2017 at 1:05 AM, Bruce Evans <b...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to