From: Dave Martin <Dave.Martin@arm.com>
To: Peter Collingbourne <pcc@google.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-parisc@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Oleg Nesterov <oleg@redhat.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>,
Evgenii Stepanov <eugenis@google.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v10 2/7] arch: move SA_* definitions to generic headers
Date: Tue, 8 Sep 2020 16:12:23 +0100 [thread overview]
Message-ID: <20200908151223.GS6642@arm.com> (raw)
In-Reply-To: <f5b9b91e7401d82c899fb6d1bb7fb2158103e5f3.1598072840.git.pcc@google.com>
On Fri, Aug 21, 2020 at 10:10:12PM -0700, Peter Collingbourne wrote:
> Most architectures with the exception of alpha, mips, parisc and
> sparc use the same values for these flags. Move their definitions into
> asm-generic/signal-defs.h and allow the architectures with non-standard
> values to override them. Also, document the non-standard flag values
> in order to make it easier to add new generic flags in the future.
>
> Signed-off-by: Peter Collingbourne <pcc@google.com>
While this looks reasonable, I've just realised that you strip the "U"
from some arches' definitions here.
So, on powerpc and x86, this changes the type of flags other than
SA_RESETHAND from unsigned int to int.
While I can't see this breaking any sensible use of these flags, there's
a chance that there is software relying on this distinction by
accident.
I wonder whether it's worth doing something like
#ifdef ARCH_WANT_STRICTLY_UNSIGNED_SA_FLAGS
#define __SA_FLAG_VAL(x) x ## U
#else
#define __SA_FLAG_VAL(x) x
#endif
#ifndef SA_NOCLDSTOP
#define SA_NOCLDSTOP __SA_FLAG_VAL(0x00000001)
#endif
/* ... */
Mind you, the historical situation also has issues, e.g. because
sa_flags in struct sigaction is an int, assigning
struct sigaction sa;
sa.sa_flags = SA_RESETHAND;
implies an overflow and so isn't portably safe (at least in theory). I
guess we are getting away with it today. Preserving the situation by
keeping the "U"s where appropriate would at least avoid making the
situation worse.
[...]
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-09-08 15:13 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 [this message]
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
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=20200908151223.GS6642@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).