On Wed, Nov 4, 2020 at 9:24 AM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > 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> Thanks, likewise for the other patches that you acked. > > 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. Picking up the cleanups first sounds good to me and I don't mind which tree they go via. To make it easier to pick up just the cleanups I will reorder the patches a bit. I will move patch 6 to patch 4 so that 1-4 are the non-uapi-affecting cleanups and 5-8 implement the substantive changes. Peter
