On Tue, Jun 06, 2017 at 12:37:53PM +0100, Dave P Martin wrote:

On Mon, Jun 05, 2017 at 03:17:44PM +0100, Catalin Marinas wrote:

quoted

On Fri, May 26, 2017 at 12:37:32PM +0100, Dave P Martin wrote:

quoted

On Tue, May 23, 2017 at 12:30:19PM +0100, Catalin Marinas wrote:

quoted

BTW, does SIGFRAME_MAXSZ now become ABI? Or the user only needs to
interrogate the frame size and we keep this internal to the kernel?

If the kernel rejects extra_contexts that cause this limit to be
exceeded, then yes -- though it will rarely be relevant except in the
case of memory corruption, or if architecture extensions eventually
require a larger frame.

(sve_context could theoretically grow larger then SIGFRAME_MAXSZ all by
itself, but that's unlikely to happen any time soon.)

Userspace could hit SIGFRAME_MAXSZ by constructing a valid sequence of
records that is ridiculously large, by padding out the records: common
sense suggests not to do this, but it's never been documented or
enforced.  I didn't feel comfortable changing the behaviour here to be
more strict.

So, SIGFRAME_MAXSZ should either be given a larger, more future-proof
value ... or otherwise we should perhaps get rid of it entirely.

If we can, yes, I would get rid of it.

If the size field is retained I prefer to keep this, but it's
deliberately not in any header.  This allows the kernel to have a
stricter idea about what is sane, without it formally being ABI.

This is supposed to be a deterrent against people writing signal frame
code manipulation code in a stupid way.  SIGFRAME_MAXSZ should only
ever be increased during maintenance -- it's probably worth adding a
comment on that point.

Fine by me.

-- 
Catalin