On Fri, Jan 5, 2024 at 8:25 PM Rob Landley <r...@landley.net> wrote: > > On 1/5/24 19:14, enh wrote: > >> I'm out of the habit of speaking at conferences (there was a pandemic), > >> really I > >> should just get on a regular local schedule of Posting Crap Videos To > >> Youtube. > >> NOT trying to polish them but just get them out regularly and then later > >> string > >> together playlists of the less bad ones. (I can blather much > >> stream-of-consciousness! You think this is bad, you should meet me in > >> person! > >> Elliott was subject to this at a lunch once, and I was NOT sleep deprived, > >> and > >> on my best behavior for that.) > > > > (fwiw, it's less overwhelming in person where you're actually > > interacting than it is finding the time to even read a 500-line email > > response, let alone reply :-) ) > > I used to teach community college courses to vent my enthusiasm, but I > wandered > away for several years and when I looked back into it the bureaucratic > requirements had increased dramatically. (Not certification, just... > paperwork.) > > > keep reading the test to see a couple of extra special cases: > > https://android.googlesource.com/platform/bionic/+/main/tests/unistd_test.cpp#1128 > > I was reading the actual kernel code to see what the limits are, which are > enforced here: > > https://android.googlesource.com/platform/bionic/+/main/tests/unistd_test.cpp#1128 > > Based on _STK_LIM from: > > https://github.com/torvalds/linux/blob/v6.6/include/uapi/linux/resource.h#L63 > > And ARG_MAX at: > > https://github.com/torvalds/linux/blob/v6.6/include/uapi/linux/limits.h#L8 > > So min is 131072 bytes and max is 6 megabytes. > > > basically, if RLIMIT_STACK is too big, you're capped at 128KiB. more > > weirdly, if it's too _small_ you also get the maximum 128KiB. > > You're seeing 128k for too _big_? That's weird. Sounds like a bug?
isn't that https://elixir.bootlin.com/linux/v6.6.4/source/fs/exec.c#L853 ? ``` stack_expand = min(rlim_stack, stack_size + stack_expand); ``` > > (i don't think this affects your code, but the reason we touched this > > recently is that it's not "32 pages" as we claimed before --- it's > > actually 128KiB, which _happens to be_ 32 pages if your page size is > > 4KiB: > > https://android.googlesource.com/platform/bionic/+/2da31cf7b0c6071f83244eb0c89f95395a48cb37%5E%21/#F0 > > ) > > They hardwired 131072 into the ARG_MAX #define due to hysterical raisins, so > it > didn't move when page size does. The comment in exec.c gives pages as > historical > motivation, but that's not what the code _does_. > > *shrug* Arbitrary and historical. > > >> Basically I want to know what struct is at the end of the stack (a > >> sequenced > >> collection of structs and arrays are conceptually in an encapsulating > >> struct), > >> and where does "1/4 stack size" _start_ measuring from. (From the actual > >> end, or > >> does some of the data there "not count"? The debian xargs behavior implies > >> it's > >> _just_ measuring the strings, but if so I could feed it an argv[] of a > >> couple > >> million "" and blow the stack because each of those is 8 bytes of argv[] to > >> point at 1 byte of NUL terminator, and resticting _that_ to 1/4 the stack > >> would > >> try to write off the end of it. I'm pretty sure somebody would have > >> noticed by > >> now...) > > > > wasn't our conclusion last time we talked about this "it's always > > likely to wobble a bit, so as long as we go with the most conservative > > assumption, that's what we want for this use case?". > > I was informed of "xargs --show-limits", and if I have to implement that I > would > like to do it _right_. didn't we have this discussion before, where we worked out that no-one does this right? (which is why we didn't implement it at the time?) > Also, my argument with Linus about this was years ago now and things seem to > have stabilized. Or at least git annotate fs/exec.c says the kernel hasn't > changed how it calculates this since... commit 655c16a8ce9c1 in 2019 was > peeling > out the calculation into a separate function... commit c31dbb146dd4 was > fixing a > race condition (fetch stack limit once at the start of exec into a variable, > in > case it changes during processing)... > > Looks like commit da029c11e6b1 in 2017 was the last thing to touch this? 6 > years > ago. That changed the behavior on July 7, and I argued with Linus about it > November 3: > > https://lkml.iu.edu/hypermail/linux/kernel/1711.0/02949.html > > Both the min and max limits the kernel enforces are complete ass-pulls (and > "max" seems likely to move someday because find | args is already choked by it > and I recently bought a raspberry-pi-alike with 8 gigs RAM), but we're about 6 > months from the 7 year time horizon: seems stable enough that I can change my > code if/when they change again... > > Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
