From: Dave Martin <Dave.Martin@arm•com>
To: Peter Collingbourne <pcc@google•com>
Cc: Parisc List <linux-parisc@vger•kernel.org>,
Catalin Marinas <catalin.marinas@arm•com>,
Kevin Brodsky <kevin.brodsky@arm•com>,
Oleg Nesterov <oleg@redhat•com>,
Evgenii Stepanov <eugenis@google•com>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership•com>,
Kostya Serebryany <kcc@google•com>,
"Eric W. Biederman" <ebiederm@xmission•com>,
Andrey Konovalov <andreyknvl@google•com>,
David Spickett <david.spickett@linaro•org>,
Vincenzo Frascino <vincenzo.frascino@arm•com>,
Will Deacon <will@kernel•org>,
Linux ARM <linux-arm-kernel@lists•infradead.org>,
Richard Henderson <rth@twiddle•net>
Subject: Re: [PATCH v10 4/7] signal: define the SA_UNSUPPORTED bit in sa_flags
Date: Mon, 12 Oct 2020 14:37:39 +0100 [thread overview]
Message-ID: <20201012133738.GD32292@arm.com> (raw)
In-Reply-To: <CAMn1gO6rNqb-_Rm=7zXaRdP-QvcO5JfnUSBqj3E1uYe2T+YAiw@mail.gmail.com>
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@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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-12 13:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-22 5:10 [PATCH v10 0/7] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-08-22 5:10 ` [PATCH v10 1/7] parisc: start using signal-defs.h Peter Collingbourne
2020-09-08 15:12 ` Dave Martin
2020-08-22 5:10 ` [PATCH v10 2/7] arch: move SA_* definitions to generic headers Peter Collingbourne
2020-09-08 15:12 ` Dave Martin
2020-10-03 1:14 ` Peter Collingbourne
2020-10-05 11:06 ` Dave Martin
2020-08-22 5:10 ` [PATCH v10 3/7] signal: clear non-uapi flag bits when passing/returning sa_flags Peter Collingbourne
2020-09-08 15:12 ` Dave Martin
2020-10-08 2:23 ` Peter Collingbourne
2020-08-22 5:10 ` [PATCH v10 4/7] signal: define the SA_UNSUPPORTED bit in sa_flags Peter Collingbourne
2020-09-08 15:13 ` Dave Martin
2020-10-08 2:21 ` Peter Collingbourne
2020-10-12 13:37 ` Dave Martin [this message]
2020-08-22 5:10 ` [PATCH v10 5/7] signal: deduplicate code dealing with common _sigfault fields Peter Collingbourne
2020-09-08 15:13 ` Dave Martin
2020-10-06 5:07 ` Peter Collingbourne
2020-10-07 8:56 ` Dave Martin
2020-08-22 5:10 ` [PATCH v10 6/7] signal: define the field siginfo.si_xflags Peter Collingbourne
2020-09-08 15:13 ` Dave Martin
2020-10-08 2:11 ` Peter Collingbourne
2020-10-09 18:19 ` Peter Collingbourne
2020-10-12 13:57 ` Dave Martin
2020-10-12 13:55 ` Dave Martin
2020-08-22 5:10 ` [PATCH v10 7/7] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-09-08 15:13 ` Dave Martin
2020-10-08 2:54 ` Peter Collingbourne
2020-10-12 14:14 ` Dave Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201012133738.GD32292@arm.com \
--to=dave.martin@arm$(echo .)com \
--cc=James.Bottomley@hansenpartnership$(echo .)com \
--cc=andreyknvl@google$(echo .)com \
--cc=catalin.marinas@arm$(echo .)com \
--cc=david.spickett@linaro$(echo .)org \
--cc=ebiederm@xmission$(echo .)com \
--cc=eugenis@google$(echo .)com \
--cc=kcc@google$(echo .)com \
--cc=kevin.brodsky@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-parisc@vger$(echo .)kernel.org \
--cc=oleg@redhat$(echo .)com \
--cc=pcc@google$(echo .)com \
--cc=rth@twiddle$(echo .)net \
--cc=vincenzo.frascino@arm$(echo .)com \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox