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: > > On Fri, May 26, 2017 at 12:37:32PM +0100, Dave P Martin wrote: > > > On Tue, May 23, 2017 at 12:30:19PM +0100, Catalin Marinas wrote: > > > > 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
