From: Catalin Marinas <catalin.marinas@arm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Peter Collingbourne <pcc@google.com>,
Evgenii Stepanov <eugenis@google.com>,
Kostya Serebryany <kcc@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Dave Martin <Dave.Martin@arm.com>, Will Deacon <will@kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Andrey Konovalov <andreyknvl@google.com>,
Richard Henderson <rth@twiddle.net>,
linux-api@vger.kernel.org, Helge Deller <deller@gmx.de>,
David Spickett <david.spickett@linaro.org>
Subject: Re: [PATCH v13 1/8] parisc: Drop parisc special case for __sighandler_t
Date: Wed, 4 Nov 2020 17:24:48 +0000 [thread overview]
Message-ID: <20201104172447.GF28902@gaia> (raw)
In-Reply-To: <87a6vx6p11.fsf@x220.int.ebiederm.org>
On Wed, Nov 04, 2020 at 10:54:34AM -0600, Eric W. Biederman wrote:
> Peter Collingbourne <pcc@google.com> writes:
> > From: Helge Deller <deller@gmx.de>
> >
> > I believe we can and *should* drop this parisc-specific typedef for
> > __sighandler_t when compiling a 64-bit kernel. The reasons:
> >
> > 1. We don't have a 64-bit userspace yet, so nothing (on userspace side)
> > can break.
> >
> > 2. Inside the Linux kernel, this is only used in kernel/signal.c, in
> > function kernel_sigaction() where the signal handler is compared against
> > SIG_IGN. SIG_IGN is defined as (__sighandler_t)1), so only the pointers
> > are compared.
> >
> > 3. Even when a 64-bit userspace gets added at some point, I think
> > __sighandler_t should be defined what it is: a function pointer struct.
> >
> > I compiled kernel/signal.c with and without the patch, and the produced code
> > is identical in both cases.
> >
> > Signed-off-by: Helge Deller <deller@gmx.de>
> > Reviewed-by: Peter Collingbourne <pcc@google.com>
> > Link:
> > https://linux-review.googlesource.com/id/I21c43f21b264f339e3aa395626af838646f62d97
>
> Peter as you have sent this, this also needs your Signed-off-by.
>
> Otherwise this looks reasonable to me.
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> While the final bits look like they are still under discussion it looks
> like the preceding cleanups are pretty solid at this point.
Minor nits, unless you nak the whole approach of SA_FAULTFLAGS and
SA_UNSUPPORTED ;) (it looks a bit complicated to me but I don't have a
better idea for a generic implementation).
> Any chance we can get the cleanups into a tree in linux-next so that
> the discussion can focus on the core parts of this work?
>
> Perhaps I should pick up the clenaups?
However you prefer (I usually start queuing patches at -rc3). If you
pick them up, please provide a stable branch somewhere so that we can
add the others on top.
Thanks.
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Peter Collingbourne <pcc@google.com>,
Helge Deller <deller@gmx.de>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Oleg Nesterov <oleg@redhat.com>,
linux-api@vger.kernel.org,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Kostya Serebryany <kcc@google.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Andrey Konovalov <andreyknvl@google.com>,
David Spickett <david.spickett@linaro.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Will Deacon <will@kernel.org>, Dave Martin <Dave.Martin@arm.com>,
Evgenii Stepanov <eugenis@google.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v13 1/8] parisc: Drop parisc special case for __sighandler_t
Date: Wed, 4 Nov 2020 17:24:48 +0000 [thread overview]
Message-ID: <20201104172447.GF28902@gaia> (raw)
In-Reply-To: <87a6vx6p11.fsf@x220.int.ebiederm.org>
On Wed, Nov 04, 2020 at 10:54:34AM -0600, Eric W. Biederman wrote:
> Peter Collingbourne <pcc@google.com> writes:
> > From: Helge Deller <deller@gmx.de>
> >
> > I believe we can and *should* drop this parisc-specific typedef for
> > __sighandler_t when compiling a 64-bit kernel. The reasons:
> >
> > 1. We don't have a 64-bit userspace yet, so nothing (on userspace side)
> > can break.
> >
> > 2. Inside the Linux kernel, this is only used in kernel/signal.c, in
> > function kernel_sigaction() where the signal handler is compared against
> > SIG_IGN. SIG_IGN is defined as (__sighandler_t)1), so only the pointers
> > are compared.
> >
> > 3. Even when a 64-bit userspace gets added at some point, I think
> > __sighandler_t should be defined what it is: a function pointer struct.
> >
> > I compiled kernel/signal.c with and without the patch, and the produced code
> > is identical in both cases.
> >
> > Signed-off-by: Helge Deller <deller@gmx.de>
> > Reviewed-by: Peter Collingbourne <pcc@google.com>
> > Link:
> > https://linux-review.googlesource.com/id/I21c43f21b264f339e3aa395626af838646f62d97
>
> Peter as you have sent this, this also needs your Signed-off-by.
>
> Otherwise this looks reasonable to me.
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> While the final bits look like they are still under discussion it looks
> like the preceding cleanups are pretty solid at this point.
Minor nits, unless you nak the whole approach of SA_FAULTFLAGS and
SA_UNSUPPORTED ;) (it looks a bit complicated to me but I don't have a
better idea for a generic implementation).
> Any chance we can get the cleanups into a tree in linux-next so that
> the discussion can focus on the core parts of this work?
>
> Perhaps I should pick up the clenaups?
However you prefer (I usually start queuing patches at -rc3). If you
pick them up, please provide a stable branch somewhere so that we can
add the others on top.
Thanks.
--
Catalin
_______________________________________________
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-11-04 17:24 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-03 4:09 [PATCH v13 0/8] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-11-03 4:09 ` Peter Collingbourne
2020-11-03 4:09 ` [PATCH v13 1/8] parisc: Drop parisc special case for __sighandler_t Peter Collingbourne
2020-11-03 4:09 ` Peter Collingbourne
2020-11-04 16:54 ` Eric W. Biederman
2020-11-04 16:54 ` Eric W. Biederman
2020-11-04 17:24 ` Catalin Marinas [this message]
2020-11-04 17:24 ` Catalin Marinas
2020-11-04 17:36 ` Eric W. Biederman
2020-11-04 17:36 ` Eric W. Biederman
2020-11-04 18:00 ` Dave Martin
2020-11-04 18:00 ` Dave Martin
2020-11-04 20:46 ` Peter Collingbourne
2020-11-04 20:46 ` Peter Collingbourne
2020-11-03 4:09 ` [PATCH v13 2/8] parisc: start using signal-defs.h Peter Collingbourne
2020-11-03 4:09 ` Peter Collingbourne
2020-11-04 18:05 ` Eric W. Biederman
2020-11-04 18:05 ` Eric W. Biederman
2020-11-03 4:09 ` [PATCH v13 3/8] arch: move SA_* definitions to generic headers Peter Collingbourne
2020-11-03 4:09 ` Peter Collingbourne
2020-11-04 18:47 ` Eric W. Biederman
2020-11-04 18:47 ` Eric W. Biederman
2020-11-04 20:48 ` Peter Collingbourne
2020-11-04 20:48 ` Peter Collingbourne
2020-11-03 4:09 ` [PATCH v13 4/8] signal: clear non-uapi flag bits when passing/returning sa_flags Peter Collingbourne
2020-11-03 4:09 ` Peter Collingbourne
2020-11-03 4:09 ` [PATCH v13 5/8] signal: define the SA_UNSUPPORTED bit in sa_flags Peter Collingbourne
2020-11-03 4:09 ` Peter Collingbourne
2020-11-03 4:09 ` [PATCH v13 6/8] signal: deduplicate code dealing with common _sigfault fields Peter Collingbourne
2020-11-03 4:09 ` Peter Collingbourne
2020-11-03 4:09 ` [PATCH v13 7/8] signal: define the field siginfo.si_faultflags Peter Collingbourne
2020-11-03 4:09 ` Peter Collingbourne
2020-11-03 17:53 ` Catalin Marinas
2020-11-03 17:53 ` Catalin Marinas
2020-11-03 18:39 ` Peter Collingbourne
2020-11-03 18:39 ` Peter Collingbourne
2020-11-04 10:57 ` Dave Martin
2020-11-04 10:57 ` Dave Martin
2020-11-04 18:23 ` Catalin Marinas
2020-11-04 18:23 ` Catalin Marinas
2020-11-04 19:57 ` Peter Collingbourne
2020-11-04 19:57 ` Peter Collingbourne
2020-11-03 4:09 ` [PATCH v13 8/8] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-11-03 4:09 ` Peter Collingbourne
2020-11-03 18:33 ` Catalin Marinas
2020-11-03 18:33 ` Catalin Marinas
2020-11-03 19:16 ` Peter Collingbourne
2020-11-03 19:16 ` Peter Collingbourne
2020-11-04 17:45 ` Catalin Marinas
2020-11-04 17:45 ` Catalin Marinas
2020-11-04 18:27 ` Peter Collingbourne
2020-11-04 18:27 ` Peter Collingbourne
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=20201104172447.GF28902@gaia \
--to=catalin.marinas@arm.com \
--cc=Dave.Martin@arm.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=andreyknvl@google.com \
--cc=david.spickett@linaro.org \
--cc=deller@gmx.de \
--cc=ebiederm@xmission.com \
--cc=eugenis@google.com \
--cc=kcc@google.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.