linux-parisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).