From: Dave Martin <Dave.Martin@arm.com>
To: Peter Collingbourne <pcc@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Evgenii Stepanov <eugenis@google.com>,
Kostya Serebryany <kcc@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Will Deacon <will@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
linux-parisc@vger.kernel.org,
Andrey Konovalov <andreyknvl@google.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
David Spickett <david.spickett@linaro.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: Tue, 8 Sep 2020 16:13:06 +0100 [thread overview]
Message-ID: <20200908151306.GU6642@arm.com> (raw)
In-Reply-To: <f37a8b86c53be4cc440a73be4123e0419deefe5f.1598072840.git.pcc@google.com>
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).
> 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.
>
> Signed-off-by: Peter Collingbourne <pcc@google.com>
> ---
> View this change in Gerrit: https://linux-review.googlesource.com/q/Ic2501ad150a3a79c1cf27fb8c99be342e9dffbcb
>
> include/uapi/asm-generic/signal-defs.h | 7 +++++++
> kernel/signal.c | 6 ++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/include/uapi/asm-generic/signal-defs.h b/include/uapi/asm-generic/signal-defs.h
> index 319628058a53..e853cbe8722d 100644
> --- a/include/uapi/asm-generic/signal-defs.h
> +++ b/include/uapi/asm-generic/signal-defs.h
> @@ -14,6 +14,12 @@
> * SA_RESTART flag to get restarting signals (which were the default long ago)
> * SA_NODEFER prevents the current signal from being masked in the handler.
> * SA_RESETHAND clears the handler when the signal is delivered.
> + * SA_UNSUPPORTED is a flag bit that will never be supported. Kernels from
> + * before the introduction of SA_UNSUPPORTED did not clear unknown bits from
> + * sa_flags when read using the oldact argument to sigaction and rt_sigaction,
> + * so this bit allows flag bit support to be detected from userspace while
> + * allowing an old kernel to be distinguished from a kernel that supports every
> + * flag bit.
> *
> * SA_ONESHOT and SA_NOMASK are the historical Linux names for the Single
> * Unix names RESETHAND and NODEFER respectively.
> @@ -42,6 +48,7 @@
> #ifndef SA_RESETHAND
> #define SA_RESETHAND 0x80000000
> #endif
> +#define SA_UNSUPPORTED 0x00000400
I guess people may debate which bit is chosen, but your consolidation
of these definitions should help to reduce the possibility of future
collisions. This bit appears unused for now, so I guess I don't have a
strong opinion.
> #define SA_NOMASK SA_NODEFER
> #define SA_ONESHOT SA_RESETHAND
> diff --git a/kernel/signal.c b/kernel/signal.c
> index f802c82c7bcc..c80e70bde11d 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -3984,6 +3984,12 @@ int do_sigaction(int sig, struct k_sigaction *act, struct k_sigaction *oact)
> if (oact)
> *oact = *k;
>
> + /*
> + * Make sure that we never accidentally claim to support SA_UNSUPPORTED,
> + * e.g. by having an architecture use the bit in their uapi.
> + */
> + BUILD_BUG_ON(UAPI_SA_FLAGS & SA_UNSUPPORTED);
> +
Seems reasonable.
With the above rewording in the commit message to clarify that a second
sigaction() is needed:
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
[...]
Cheers
---Dave
next prev parent reply other threads:[~2020-09-08 15:15 UTC|newest]
Thread overview: 31+ 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-08-30 17:07 ` Helge Deller
2020-10-03 1:22 ` Peter Collingbourne
2020-10-03 10:04 ` Helge Deller
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 [this message]
2020-10-08 2:21 ` Peter Collingbourne
2020-10-12 13:37 ` Dave Martin
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=20200908151306.GU6642@arm.com \
--to=dave.martin@arm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=andreyknvl@google.com \
--cc=catalin.marinas@arm.com \
--cc=david.spickett@linaro.org \
--cc=ebiederm@xmission.com \
--cc=eugenis@google.com \
--cc=kcc@google.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-parisc@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pcc@google.com \
--cc=rth@twiddle.net \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).