Thread (1 message) 1 message, 1 author, 2020-11-04

Re: [PATCH v13 1/8] parisc: Drop parisc special case for __sighandler_t

From: Eric W. Biederman <hidden>
Date: 2020-11-04 17:37:45
Also in: linux-arm-kernel

Catalin Marinas [off-list ref] writes:
On Wed, Nov 04, 2020 at 10:54:34AM -0600, Eric W. Biederman wrote:
quoted
Peter Collingbourne [off-list ref] writes:
quoted
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 <redacted>
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" <redacted>

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).
quoted
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.
I just want to make certain the cleanups don't get lost in the shuffle.

If we are almost there then I will focus my energy on reviewing the
patches and make certain there isn't something important that has been
overlooked.  I don't expect there is.


Eric

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help