[ksh93-integration-discuss] How can I search for my own bugreports ?

[Richard L. Hamilton]

> 6526924 kernel syscall Dis setrlimit(2)/getrlimit(2) should support RLIMIT_LOCKS, *_MEMLOCK and *_PTHREAD

Out of curiosity, I did a truss on a not-too-old ksh93 binary (s+), and saw the following while
doing a ulimit -a:
[address space limit]
25539/1:        getrlimit(RLIMIT_VMEM, 0xFFFFFFFF7FFFD0B8)      = 0
25539/1:                cur = RLIM64_INFINITY  max = RLIM64_INFINITY
[core file size]
25539/1:        getrlimit(RLIMIT_CORE, 0xFFFFFFFF7FFFD0B8)      = 0
25539/1:                cur = RLIM64_INFINITY  max = RLIM64_INFINITY
[cpu time]
25539/1:        getrlimit(RLIMIT_CPU, 0xFFFFFFFF7FFFD0B8)       = 0
25539/1:                cur = RLIM64_INFINITY  max = RLIM64_INFINITY
[data size]
25539/1:        getrlimit(RLIMIT_DATA, 0xFFFFFFFF7FFFD0B8)      = 0
25539/1:                cur = RLIM64_INFINITY  max = RLIM64_INFINITY
[file size]
25539/1:        getrlimit(RLIMIT_FSIZE, 0xFFFFFFFF7FFFD0B8)     = 0
25539/1:                cur = RLIM64_INFINITY  max = RLIM64_INFINITY
[nofile]
25539/1:        getrlimit(RLIMIT_NOFILE, 0xFFFFFFFF7FFFD0B8)    = 0
25539/1:                cur = 256  max = 65536
25539/1:        sysconfig(_CONFIG_CHILD_MAX)                    = 29995
[pipe buffer size]
25539/1:        pathconf("/", _PC_PIPE_BUF)                     = 5120
[?]
25539/1:        getrlimit(RLIMIT_CPU, 0xFFFFFFFF7FFFD0B8)       = 0
25539/1:                cur = RLIM64_INFINITY  max = RLIM64_INFINITY
[socket buffer size?]
25539/1:        pathconf("/", _PC_PIPE_BUF)                     = 5120
[stack size]
25539/1:        getrlimit(RLIMIT_STACK, 0xFFFFFFFF7FFFD0B8)     = 0
25539/1:                cur = 8388608  max = RLIM64_INFINITY
[process size]
25539/1:        getrlimit(RLIMIT_VMEM, 0xFFFFFFFF7FFFD0B8)      = 0
25539/1:                cur = RLIM64_INFINITY  max = RLIM64_INFINITY

Which is to say, as that binary does things, the address space and process size limits look to be one
and the same on Solaris, as do the pipe buffer size and socket buffer size (and AFAIK, pipe buffer
size is _not_ settable, unlike some OSs).  On another trace, I saw something reasonable for
the nproc limit (sysconfig(_CONFIG_CHILD_MAX)), although again, that's clearly not going to
be something the individual process can set even a soft limit for.

Now, I can see _why_ the address space limit and process size limit are one and the same:
$ grep RLIMIT_AS /usr/include/sys/resource.h
#define RLIMIT_AS       RLIMIT_VMEM

but at the shell level, I wonder if it's not a little misleading to have them both; it leaves the
impression that they can be set individually.

Perhaps it might help if the output of ulimit -a at the very least indicated the limits that
were inherently read-only on a given platform; and in the case of limits that were synonyms
on a particular platform (such as address space and process size on Solaris), indicated that also.
And it's not at all clear to me what the sense of treating pipe buffer size and socket buffer size
as the same is; maybe on some *BSD systems, pipe() is really socketpair(), but on Solaris, real
pipe() calls result in a STREAMS based entity (onto which one can push STREAMS modules,
use the STREAMS rather than the socketpair() method of passing file descriptors, etc).  OTOH,
I see that at least sometimes the ksh93 code maps pipe() to socketpair(); not sure what the
heck it's doing on Solaris.  Still, if it isn't mapping pipe() to socketpair(), then by using
pathconf("/", _PC_PIPE_BUF) it's lying about the socket buffer size, and if it is, it's lying about both.

So in addition to adding some other limits, rationalizing what ksh93 does with the existing ones
on Solaris might not be a bad idea.  (and the limit that some systems have, RLIMIT_RSS, also
sounds rather tempting if one's going to be thinking of adding limits; I'd think it would be
much more useful in most cases than RLIMIT_LOCKS, for example)
 
 
This message posted from opensolaris.org