[PATCH v10 4/7] signal: define the SA_UNSUPPORTED bit in sa_flags

[Dave Martin]

On Wed, Oct 07, 2020 at 07:21:25PM -0700, Peter Collingbourne wrote:
> On Tue, Sep 8, 2020 at 8:13 AM Dave Martin <Dave.Martin at arm.com> wrote:
> >
> > On Fri, Aug 21, 2020 at 10:10:14PM -0700, Peter Collingbourne wrote:
> >
> > Nit: no statement of the chage being made (other than in the subject
> > line).
> 
> Will fix.
> 
> > > This bit will never be supported in the uapi. The purpose of this flag
> > > bit is to allow userspace to distinguish an old kernel that does not
> > > clear unknown sa_flags bits from a kernel that supports every flag bit.
> > >
> > > In other words, if userspace finds that this bit remains set in
> > > oldact.sa_flags, it means that the kernel cannot be trusted to have
> > > cleared unknown flag bits from sa_flags, so no assumptions about flag
> > > bit support can be made.
> >
> > This isn't quite right?  After a single sigaction() call, oact will
> > contain the sa_flags for the previously registered handler.  So a
> > second sigaction() call would be needed to find out the newly effective
> > sa_flags.
> 
> You're right, this is unclear to say the least. In v11 I will reword like so:
> 
>     In other words, if userspace does something like:
> 
>       act.sa_flags |= SA_UNSUPPORTED;
>       sigaction(SIGSEGV, &act, 0);
>       sigaction(SIGSEGV, 0, &oldact);
> 
>     and finds that SA_UNSUPPORTED remains set in oldact.sa_flags, it means
>     that the kernel cannot be trusted to have cleared unknown flag bits
>     from sa_flags, so no assumptions about flag bit support can be made.

Seems reasonable.  We'd need to make sure we're clear about which flags
this applies for, though.  The pre-existing flags can be assumed to be
supported irrespective of whether SA_UNSUPPORTED remains set.

Cheers
---Dave