public inbox for linux-api@vger.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 1/7] signal.h: Define SIGINFO on all architectures
       [not found] ` <20190605081906.28938-2-ar@cs.msu.ru>
@ 2019-06-11 20:36   ` Eric W. Biederman
  2019-06-11 22:38     ` Arseny Maslennikov
  0 siblings, 1 reply; 2+ messages in thread
From: Eric W. Biederman @ 2019-06-11 20:36 UTC (permalink / raw)
  To: Arseny Maslennikov
  Cc: Greg Kroah-Hartman, Jiri Slaby, Ingo Molnar, Peter Zijlstra,
	linux-kernel, Vladimir D . Seleznev, linux-api

Arseny Maslennikov <ar@cs.msu.ru> writes:

> This complementary patch defines SIGINFO as a synonym for SIGPWR
> on every architecture supported by the kernel.
> The particular signal number chosen does not really matter and is only
> required for the related tty functionality to work properly,
> so if it does not suite expectations, any suggestions are warmly
> welcome.
>
> SIGPWR looks like a nice candidate for this role, because it is
> defined on every supported arch; it is currently only used to inform
> PID 1 of power failures, and daemons that care about low-level
> events do not tend to have a controlling terminal.
>
> However, on sparcs SIGPWR is a synonym for SIGLOST, a signal unique
> to that architecture, with a narrow set of intended uses that do not
> combine well with interactively requesting status.
> SIGLOST is not used by any kernel code at the moment.
> I'm not sure there is a more reasonable alternative right now.

Is the name SIGINFO already well established.

It just is a little bit confusing with struct siginfo.

At least on x86 it looks like we have signals 32 and 33 that are
reserved and not used for anything.  Is there a reason you have
not picked one of those?

Also should this be a realtime signal with signal information
or a non-realtime signal?

I don't expect there is much to encode except that the user is asking
for information.  I half wonder if it could be done as a different
si_code to SIGWINCH.  But of course that doesn't work because it is
not a real time signal so does not queue more than one siginfo. (Sigh).

I just would like to see that we have a clear concept of how this new
signal plays into all of the signal handling bits.

Added linux-api because this is fundamentally extending the linux-api,
and we probably want man-page updates etc.

Eric

>
> Signed-off-by: Arseny Maslennikov <ar@cs.msu.ru>
> ---
>  arch/arm/include/uapi/asm/signal.h     | 1 +
>  arch/h8300/include/uapi/asm/signal.h   | 1 +
>  arch/ia64/include/uapi/asm/signal.h    | 1 +
>  arch/m68k/include/uapi/asm/signal.h    | 1 +
>  arch/mips/include/uapi/asm/signal.h    | 1 +
>  arch/parisc/include/uapi/asm/signal.h  | 1 +
>  arch/powerpc/include/uapi/asm/signal.h | 1 +
>  arch/s390/include/uapi/asm/signal.h    | 1 +
>  arch/sparc/include/uapi/asm/signal.h   | 2 ++
>  arch/x86/include/uapi/asm/signal.h     | 1 +
>  arch/xtensa/include/uapi/asm/signal.h  | 1 +
>  include/uapi/asm-generic/signal.h      | 1 +
>  12 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/include/uapi/asm/signal.h b/arch/arm/include/uapi/asm/signal.h
> index 9b4185ba4f8a..b80b53a17267 100644
> --- a/arch/arm/include/uapi/asm/signal.h
> +++ b/arch/arm/include/uapi/asm/signal.h
> @@ -50,6 +50,7 @@ typedef unsigned long sigset_t;
>  #define SIGLOST		29
>  */
>  #define SIGPWR		30
> +#define SIGINFO		SIGPWR
>  #define SIGSYS		31
>  #define	SIGUNUSED	31
>  
> diff --git a/arch/h8300/include/uapi/asm/signal.h b/arch/h8300/include/uapi/asm/signal.h
> index e15521037348..7a2b783af22b 100644
> --- a/arch/h8300/include/uapi/asm/signal.h
> +++ b/arch/h8300/include/uapi/asm/signal.h
> @@ -50,6 +50,7 @@ typedef unsigned long sigset_t;
>  #define SIGLOST		29
>  */
>  #define SIGPWR		30
> +#define SIGINFO		SIGPWR
>  #define SIGSYS		31
>  #define	SIGUNUSED	31
>  
> diff --git a/arch/ia64/include/uapi/asm/signal.h b/arch/ia64/include/uapi/asm/signal.h
> index aa98ff1b9e22..b4c98cb17165 100644
> --- a/arch/ia64/include/uapi/asm/signal.h
> +++ b/arch/ia64/include/uapi/asm/signal.h
> @@ -45,6 +45,7 @@
>  #define SIGLOST		29
>  */
>  #define SIGPWR		30
> +#define SIGINFO		SIGPWR
>  #define SIGSYS		31
>  /* signal 31 is no longer "unused", but the SIGUNUSED macro remains for backwards compatibility */
>  #define	SIGUNUSED	31
> diff --git a/arch/m68k/include/uapi/asm/signal.h b/arch/m68k/include/uapi/asm/signal.h
> index 915cc755a184..a0b4e4108cb8 100644
> --- a/arch/m68k/include/uapi/asm/signal.h
> +++ b/arch/m68k/include/uapi/asm/signal.h
> @@ -50,6 +50,7 @@ typedef unsigned long sigset_t;
>  #define SIGLOST		29
>  */
>  #define SIGPWR		30
> +#define SIGINFO		SIGPWR
>  #define SIGSYS		31
>  #define	SIGUNUSED	31
>  
> diff --git a/arch/mips/include/uapi/asm/signal.h b/arch/mips/include/uapi/asm/signal.h
> index 53104b10aae2..975a6f0d3b0b 100644
> --- a/arch/mips/include/uapi/asm/signal.h
> +++ b/arch/mips/include/uapi/asm/signal.h
> @@ -43,6 +43,7 @@ typedef unsigned long old_sigset_t;		/* at least 32 bits */
>  #define SIGCHLD		18	/* Child status has changed (POSIX).  */
>  #define SIGCLD		SIGCHLD /* Same as SIGCHLD (System V).	*/
>  #define SIGPWR		19	/* Power failure restart (System V).  */
> +#define SIGINFO		SIGPWR	/* Keyboard status request (4.2 BSD). */
>  #define SIGWINCH	20	/* Window size change (4.3 BSD, Sun).  */
>  #define SIGURG		21	/* Urgent condition on socket (4.2 BSD).  */
>  #define SIGIO		22	/* I/O now possible (4.2 BSD).	*/
> diff --git a/arch/parisc/include/uapi/asm/signal.h b/arch/parisc/include/uapi/asm/signal.h
> index d38563a394f2..fe2e00d590ac 100644
> --- a/arch/parisc/include/uapi/asm/signal.h
> +++ b/arch/parisc/include/uapi/asm/signal.h
> @@ -22,6 +22,7 @@
>  #define SIGUSR2		17
>  #define SIGCHLD		18
>  #define SIGPWR		19
> +#define SIGINFO		SIGPWR
>  #define SIGVTALRM	20
>  #define SIGPROF		21
>  #define SIGIO		22
> diff --git a/arch/powerpc/include/uapi/asm/signal.h b/arch/powerpc/include/uapi/asm/signal.h
> index 85b0a7aa43e7..e7f3885905b4 100644
> --- a/arch/powerpc/include/uapi/asm/signal.h
> +++ b/arch/powerpc/include/uapi/asm/signal.h
> @@ -53,6 +53,7 @@ typedef struct {
>  #define SIGLOST		29
>  */
>  #define SIGPWR		30
> +#define SIGINFO		SIGPWR
>  #define SIGSYS		31
>  #define	SIGUNUSED	31
>  
> diff --git a/arch/s390/include/uapi/asm/signal.h b/arch/s390/include/uapi/asm/signal.h
> index 9a14a611ed82..12ee62987971 100644
> --- a/arch/s390/include/uapi/asm/signal.h
> +++ b/arch/s390/include/uapi/asm/signal.h
> @@ -58,6 +58,7 @@ typedef unsigned long sigset_t;
>  #define SIGLOST         29
>  */
>  #define SIGPWR          30
> +#define SIGINFO         SIGPWR
>  #define SIGSYS		31
>  #define SIGUNUSED       31
>  
> diff --git a/arch/sparc/include/uapi/asm/signal.h b/arch/sparc/include/uapi/asm/signal.h
> index ff9505923b9a..b655163198bb 100644
> --- a/arch/sparc/include/uapi/asm/signal.h
> +++ b/arch/sparc/include/uapi/asm/signal.h
> @@ -71,6 +71,8 @@
>  #define SIGWINCH	28
>  #define SIGLOST		29
>  #define SIGPWR		SIGLOST
> +/* XXX: is it OK for SIGINFO to collide with LOST? */
> +#define SIGINFO		SIGPWR
>  #define SIGUSR1		30
>  #define SIGUSR2		31
>  
> diff --git a/arch/x86/include/uapi/asm/signal.h b/arch/x86/include/uapi/asm/signal.h
> index e5745d593dc7..1539bb28826c 100644
> --- a/arch/x86/include/uapi/asm/signal.h
> +++ b/arch/x86/include/uapi/asm/signal.h
> @@ -55,6 +55,7 @@ typedef unsigned long sigset_t;
>  #define SIGLOST		29
>  */
>  #define SIGPWR		30
> +#define SIGINFO		SIGPWR
>  #define SIGSYS		31
>  #define	SIGUNUSED	31
>  
> diff --git a/arch/xtensa/include/uapi/asm/signal.h b/arch/xtensa/include/uapi/asm/signal.h
> index 005dec5bfde4..d644234305de 100644
> --- a/arch/xtensa/include/uapi/asm/signal.h
> +++ b/arch/xtensa/include/uapi/asm/signal.h
> @@ -65,6 +65,7 @@ typedef struct {
>  #define SIGPOLL		SIGIO
>  /* #define SIGLOST		29 */
>  #define SIGPWR		30
> +#define SIGINFO		SIGPWR
>  #define SIGSYS		31
>  #define	SIGUNUSED	31
>  
> diff --git a/include/uapi/asm-generic/signal.h b/include/uapi/asm-generic/signal.h
> index 5c716a952cbe..9f9a1db0d43c 100644
> --- a/include/uapi/asm-generic/signal.h
> +++ b/include/uapi/asm-generic/signal.h
> @@ -43,6 +43,7 @@
>  #define SIGLOST		29
>  */
>  #define SIGPWR		30
> +#define SIGINFO		SIGPWR
>  #define SIGSYS		31
>  #define	SIGUNUSED	31

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH 1/7] signal.h: Define SIGINFO on all architectures
  2019-06-11 20:36   ` [PATCH 1/7] signal.h: Define SIGINFO on all architectures Eric W. Biederman
@ 2019-06-11 22:38     ` Arseny Maslennikov
  0 siblings, 0 replies; 2+ messages in thread
From: Arseny Maslennikov @ 2019-06-11 22:38 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Greg Kroah-Hartman, Jiri Slaby, Ingo Molnar, Peter Zijlstra,
	linux-kernel, Vladimir D . Seleznev, linux-api

[-- Attachment #1: Type: text/plain, Size: 4419 bytes --]

On Tue, Jun 11, 2019 at 03:36:00PM -0500, Eric W. Biederman wrote:
> Arseny Maslennikov <ar@cs.msu.ru> writes:
> 
> > This complementary patch defines SIGINFO as a synonym for SIGPWR
> > on every architecture supported by the kernel.
> > The particular signal number chosen does not really matter and is only
> > required for the related tty functionality to work properly,
> > so if it does not suite expectations, any suggestions are warmly
> > welcome.
> >
> > SIGPWR looks like a nice candidate for this role, because it is
> > defined on every supported arch; it is currently only used to inform
> > PID 1 of power failures, and daemons that care about low-level
> > events do not tend to have a controlling terminal.
> >
> > However, on sparcs SIGPWR is a synonym for SIGLOST, a signal unique
> > to that architecture, with a narrow set of intended uses that do not
> > combine well with interactively requesting status.
> > SIGLOST is not used by any kernel code at the moment.
> > I'm not sure there is a more reasonable alternative right now.
> 
> Is the name SIGINFO already well established.
> 
> It just is a little bit confusing with struct siginfo.
> 

I thought about this, but the alternatives are clunkier.
SIGKBINFO? Implies there actually is a keyboard, most ttys are
virtual/software nowadays. Misplaced emphasis.
SIGSTATUS? Too generic.
SIGTINFO? This could work, like conveys the nature and all, but many
applications already do #ifdef SIGINFO; if we reuse the name they will
suddenly just work, and this helps adoption.
SIGTINFO does decipher to "terminal info", this sounds too ambiguous.

Fortunately, from UNIX tradition signal names are defined in caps, and
given there is much more related written discussion than spoken, this
stands out enough to my taste. I'd say, it stands out a lot.

> At least on x86 it looks like we have signals 32 and 33 that are
> reserved and not used for anything.  Is there a reason you have
> not picked one of those?

Quoting signal(7) from man-pages:
       The Linux kernel supports a range of 33 different real-time
       signals, numbered 32  to  64.   However,  the  glibc  POSIX
       threads  implementation  internally  uses two (for NPTL) or
       three   (for   LinuxThreads)   real-time    signals    (see
       pthreads(7)),  and  adjusts  the value of SIGRTMIN suitably
       (to 34 or 35).

This excerpt gives the cue that signals 32 and 33 are not really unused,
and I did not want to cause further adjustments to SIGRTMIN/SIGRTMAX,
since this means we have to recompile the world with the new, changed
SIGRTMIN/MAX...

If we'd change RTMIN, this makes all the rt signal numbers shift to the
right and can cause havoc if we do not recompile the world.

We could probably go with decrementing RTMAX and reusing the value
(effectively reserving a signal number from the end), but aliasing PWR
seems much easier and less harmful, and easier for apps to adopt.
If we find a strong reason not to reuse PWR, this may be considered as a
plan B, but the idea to allocate even more precious signals seems too
wasteful to me for now.

> 
> Also should this be a realtime signal with signal information
> or a non-realtime signal?

I see no requirement for this to be a realtime signal.

Non-realtime signals like PWR or INT also have at least some signal
information which can be accessed with handlers installed with
sigaction(2). [1] has a small example.
The most obvious piece of info is that signals sent by n_tty
(si_code==SI_KERNEL) are easy to distinguish from signals sent by
processes (si_code==SI_USER)

> 
> I don't expect there is much to encode except that the user is asking
> for information.  I half wonder if it could be done as a different
> si_code to SIGWINCH.  But of course that doesn't work because it is
> not a real time signal so does not queue more than one siginfo. (Sigh).
> 

Signals are just a huge mess (not that this is news...)  :)

> I just would like to see that we have a clear concept of how this new
> signal plays into all of the signal handling bits.
> 
> Added linux-api because this is fundamentally extending the linux-api,
> and we probably want man-page updates etc.
> 
> Eric
> 

[1]https://github.com/porrided/tty-kb-status-userspace/blob/d32028056c85b279cf8d5f43478b5419d090637c/siginfo-test/siginfo.c

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-06-11 22:38 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20190605081906.28938-1-ar@cs.msu.ru>
     [not found] ` <20190605081906.28938-2-ar@cs.msu.ru>
2019-06-11 20:36   ` [PATCH 1/7] signal.h: Define SIGINFO on all architectures Eric W. Biederman
2019-06-11 22:38     ` Arseny Maslennikov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox