[Toybox] [PATCH] ulimit: actually use the units we claim.

[Rob Landley]

Sorry for the radio silence, typing this in a very sleep deprived state from an
airport. :)

On 5/15/23 12:53, enh wrote:
> On Sun, May 14, 2023 at 9:31 PM Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 5/12/23 00:58, Rob Landley wrote:
>     > On 5/11/23 22:54, Rob Landley wrote:
>     >> Also, the RLIMIT_BLAH macros in asm-generic.h go from 0 to 15 in a fixed
>     order,
>     >> so just defining the table entries in that order (and reordering the
>     flags to be
>     >> in that order) makes a chunk of the logic drop out...
>     >
>     > Except that -a outputs the results in alphabetical order...
> 
>     And it varies by architecture (left myself a note!) 
> 
> seriously? i'm guessing because it's sorted on the value of the constant?

I mean the constants vary by architecture. Three architectures overload:

$ grep -r RLIMIT_ arch/*/include | sed 's@[^/]*/\([^/]*\)[^:]*@\1@'
alpha:#define RLIMIT_NOFILE		6	/* max number of open files */
alpha:#define RLIMIT_AS			7	/* address space limit */
alpha:#define RLIMIT_NPROC		8	/* max number of processes */
alpha:#define RLIMIT_MEMLOCK		9	/* max locked-in-memory address space */
mips:#define RLIMIT_NOFILE		5	/* max number of open files */
mips:#define RLIMIT_AS			6	/* address space limit */
mips:#define RLIMIT_RSS			7	/* max resident set size */
mips:#define RLIMIT_NPROC		8	/* max number of processes */
mips:#define RLIMIT_MEMLOCK		9	/* max locked-in-memory address space */
sparc:#define RLIMIT_NOFILE		6	/* max number of open files */
sparc:#define RLIMIT_NPROC		7	/* max number of processes */

Which is why it wasn't already sorted by architecture with the value to feed
into the syscall implicit in the table position.

The generic is 5-9 are RSS, NPROC, NOFILE, MEMLOCK, AS.

(Way back in the dark ages, Linux tried to be compatible with the the dominant
existing unix's ABI on various architectures, so you could link their .o files
into Linux executables, the same sort of silly thing lgpl calls for. This
stopped being particularly interesting 20 years ago, but we're stuck with legacy
architecture variation for backwards compatibility with _ourselves_ because of
it...)

> but that would have to be a run-time sort, no, to vary by architecture? how does
> that even happen? did chet accidentally sort on the wrong field in a struct, and
> no-one's reported the bug?

It's why I _didn't_ do it, and on my current review going "this would b emuch
simpler organized THIS way", I went and rewrote it all and then hit the comment
inn the cleanup stage when I was mostly done and went  "oh right"...

(This is why mkroot needs to run the test suite, for regression testing across
architectures...)

>     So after some head scratching and false starts, what I'm currently leaning
>     towards doing is:
> 
>     1) add units to ulimit like you did.
> 
> including the "8m means 8*1024, not 8*1024*field-specific-multiplier" thing?
> want me to send a patch/new revision of my current patch for that?

The _input_ side is easy to do, especially since it doesn't break existing users.
 
>     2) keep prlimit mostly like ulimit, but have it show/accept bytes.
>     3) have prlimit with no arguments default to -a (show all)
>     4) Add the HARD:SOFT parsing (to both). Keep ulimit's no-colon default to soft
>     and make prlimit's no-colon default be "both".
>     5) Remove the multi-argument exclusions, go ahead and output all the enabled
>     ones (with -a enabling all), but output them in alphabetical order instead of
>     command line order. (This means the ulimit -c -c -c thing... ain't gonna?)
> 
> that actually seems worse than just rejecting it? the only use i can see for
> this functionality is what i was doing: "show me before and after around a set".

So... display, change, display what you changed it to? (Except you know what you
changed it to, there's no deltas, so it's just... reading back what you wrote to
confirm it took?)

> i think the only reasonable alternative to that is "any given invocation
> _either_ sets _or_ shows; no mixing".

Ah, I wasn't clear. Yes, it would only set with one argument. 5) above was about
display. Making "ulimit -d -e" show both: the easy way to do it is to still
output in alphabetical order. Which is clear because more than one has display
prefixes. One is machine parseable "just result". That part's true of bash now.

The difference I was proposing is that bash produces different output for:

$ ulimit -d -e
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
$ ulimit -e -d
scheduling priority             (-e) 0
data seg size           (kbytes, -d) unlimited

And I was gonna let toybox just always produce the enabled outputs in
alphabetical order.

> and to be clear, i have no proof anyone's actually using this, and i'm not sure
> what it's for beyond debugging. (which is why it was useful for me while
> actually _testing_ ulimit, but probably useless to anyone just _using_ ulimit?)

If the value is clamped to the hard limit and you didn't check what the hard
limit was before trying to set it...

Rob