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

[enh]

On Wed, May 17, 2023 at 1:27 AM Rob Landley <rob at landley.net> wrote:

> 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?)
>

yeah, exactly. (your later "what if there's a hard limit in the way?" point
is a non-testing example where you might want to do that.)


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

yeah, given that this is human-readable rather than machine-readable
anyway, that seems like it should probably be fine? "good enough for now"
anyway!


> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20230517/31fd2987/attachment-0001.htm>