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@xxxxxxx> 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
