On Fri, 2026-08-28 at 14:27 +0100, Mark Brown wrote: > Yeah, it is. I can't think why someone would ask for that either, but > equally it's more work to explicitly have a list of combinations we > reject for policy reasons. At least on arm64 each permission just comes > down to a separate bit in a control register so they're fully > independent all the way down to the hardware.
If we want to have a unified API (Bill convinced me that we did, but maybe we should have more discussion on this point), we will need to hammer out the small differences between the arch's. For technically supported, but nonsensical combos. I'd think to resolve the differences by not supporting them. But I mean, it's not the end of the world. In the end we are just talking about confusing a handful of libc developers. They can be probably handle things. > > > > > > It has been on my list to look at this > > > > > repitition at some point, it had been held up by the clone3() stuff > > > > > but > > > > > that seems to have died a death for now. > > > > > Oh? What was the blocker? > > > > Basically the glibc people weren't convinced they'd ever want to reuse a > > > shadow stack at which point having the kernel free and reallocate each > > > time > > > is just as easy. It saves having to handle corner cases with threads that > > > didn't exit cleanly. > > > I thought it was also because they wanted finer grained control of stack > > sizes > > too? But yea, if no libc wants it, it's a hard sell. > > They'd rather have just a size control for that, probably a process wide > control would be most useful since it's likely to be the same number for > all threads. I suspect the main use casse would be someone trying to do > green threads, where there's an extra real thread being created. Ok, don't want to re-litigate anything. But at some point someone was talking about a case where you needed to create a special large stack. In general it makes sense to not add this if no one is pestering about it.
