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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Catalin Marinas <catalin.marinas@xxxxxxx> writes:

> On Wed, Nov 04, 2020 at 10:54:34AM -0600, Eric W. Biederman wrote:
>> Peter Collingbourne <pcc@xxxxxxxxxx> writes:
>> > From: Helge Deller <deller@xxxxxx>
>> >
>> > 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@xxxxxx>
>> > Reviewed-by: Peter Collingbourne <pcc@xxxxxxxxxx>
>> > 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@xxxxxxxxxxxx>
>> 
>> 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.

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





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux