On Fri, Oct 13, 2017 at 03:24:21PM +0100, Catalin Marinas wrote: > On Tue, Oct 10, 2017 at 07:38:43PM +0100, Dave P Martin wrote: [...] > > +* If the SVE context is too big to fit in sigcontext.__reserved[], then extra > > + space is allocated on the stack, an extra_context record is written in > > + __reserved[] referencing this space. sve_context is then written in the > > + extra space. Refer to [1] for further details about this mechanism. > > Does this document require that the user stack is sufficiently large or > should we cap the vector length (prior to the last two RFC patches)? Oh, I think I missed your point here. I don't think it's worth capping the vector length beyond what the series alread does: the last two patches provide a way to find out how big the signal frame could be, but software still needs porting either way if it enables large vectors via prctl or ptrace. Conversely, software basing its stack allocations on SIGSTKSZ (16K) will probably get away with it: this seems to be the common choice when allocating stacks. Apart from models, we're not likely to see SVE implementations with huge vector lengths for a while yet. In any case, /proc/sys/abi/sve_default_vector_length proves a discretionary global clamp that can be set by the distro or admin. This will prevent programs from seeing large frames unless the VL is set explicitly to something > 64 bytes via prctl/ptrace (which current software won't do). [...] Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
