This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3 26/28] arm64/sve: Add documentation
- From: Dave Martin <Dave dot Martin at arm dot com>
- To: Catalin Marinas <catalin dot marinas at arm dot com>
- Cc: linux-arch at vger dot kernel dot org, Mark Rutland <mark dot rutland at arm dot com>, Okamoto Takayuki <tokamoto at jp dot fujitsu dot com>, libc-alpha at sourceware dot org, Ard Biesheuvel <ard dot biesheuvel at linaro dot org>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Richard Sandiford <richard dot sandiford at arm dot com>, Will Deacon <will dot deacon at arm dot com>, Michael Kerrisk <mtk dot manpages at gmail dot com>, Alan Hayward <alan dot hayward at arm dot com>, linux-api at vger dot kernel dot org, Alex Bennée <alex dot bennee at linaro dot org>, kvmarm at lists dot cs dot columbia dot edu, linux-arm-kernel at lists dot infradead dot org
- Date: Fri, 13 Oct 2017 18:35:01 +0100
- Subject: Re: [PATCH v3 26/28] arm64/sve: Add documentation
- Authentication-results: sourceware.org; auth=none
- References: <1507660725-7986-1-git-send-email-Dave.Martin@arm.com> <1507660725-7986-27-git-send-email-Dave.Martin@arm.com> <20171013142421.j32jzisukewxtosx@armageddon.cambridge.arm.com>
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