This patch set expands the number of signals in Linux beyond the
current cap of 64. It sets a new cap at the somewhat arbitrary limit
of 1024 signals, both because it’s what GLibc and MUSL support and
because many architectures pad sigset_t or ucontext_t in the kernel to
this cap. This limit is not fixed and can be further expanded within
reason.
Despite best efforts, there is some non-zero potential that this could
break user space; I'd appreciate any comments, review and/or pointers
to areas of concern.
Basically, these changes entail:
- Make all system calls that accept sigset_t honor the existing
sigsetsize parameter for values between 8 and 128, and to return
sigsetsize bytes to user space.
- Add AT_SIGSET_SZ to the aux vector to signal to user space the
maximum size sigset_t the kernel can accept.
- Remove the sigmask() macro except in compatibility cases, change
the sigaddset()/sigdelset()/etc. to accept a comma separated list
of signal numbers.
- Change the _NSIG_WORDS calculation to round up when needed on
generic and x86.
- Place the complete sigmask in the real time signal frame (x86_64,
x32 and ia32).
- Various fixes where sigset_t size is assumed.
- Add BSD SIGINFO (and VSTATUS) as a test.
The changes that have the most risk of breaking user space are the
ones that put more than 8 bytes of sigset_t in the real time signal
stack frame (Patches 2 & 6), and I should note that an earlier and
incomplete version of patch 2 was NAK’ed by Al in
https://lore.kernel.org/lkml/[email protected]/.
As far as I have been able to determine this patchset, and
specifically changing the size of sigset_t, does not break user space.
The two uses of sigset_t that pose the most user space risk are 1) as
a member of ucontext_t passed as a parameter to the signal handler and
2) when user space performs manual inspection of the real-time signal
stack frame.
In case (1), user space has definitions of both siget_t and ucontext_t
that are independent of, and may differ from, the kernel (eg, sigset_t
in uclibc-ng is 16 bytes, musl is 128 bytes, glibc is 128 bytes on all
architectures except Arc, etc.). User space will interpret the data
on the signal stack through these definitions, and extensions to
sigset_t will be opaque. Other non-C runtimes are similarly
independent from kernel sigset_t and ucontext_t and derive their
definition of sigset_t from libc either directly or indirectly, and do
not manually inspect the signal stack (specifically OpenJDK, Golang,
Python3, Rust and Perl).
The only instances I found of case (2), manually inspecting the signal
stack frame, are in stack unwinders/backtracers (GDB, GCC, libunwind)
and in GDB when recording program execution, and only on the i386,
x86_64, s390 and powerpc architectures. The GDB, GCC and libunwind
behave consistently with and without this patchset.
GDB's execution recording is somewhat more complicated. It uses
internally defined architecture specific constants to represent the
total size of the signal frame, and will save that entire frame for
later use. I cannot confirm that the values for powerpc and s390 are
correct, but for this purpose it doesn't matter as these architectures
explicitly pad for an expanded uc_sigmask. I can, however, confirm
that the values for i386 and x86_64 are not correct, and that GDB is
recording an incorrect amount of stack data. This doesn’t appear to
be an issue; while I cannot build a test case on x86_64 due to a known
bug[1], a basic test on i386 shows that the stack is correctly being
recorded, and forward and reverse replay seems to work just fine
across signal handlers.
There are other cases to consider if the number of signals and
therefore the size of sigset_t changes:
Impact on struct rt_sigframe member elements
The placement of ucontext_t in struct rt_sigframe has the potential
to move following member elements in ways that could break user
space if user space relied on the offsets of these elements.
However a review shows that any elements in rt_sigframe after
ucontext_t.uc_sigmask are either (1) unused or only used by the
kernel or (2) fall into the x86_64/i386 floating point state case
above.
Kernel has new signals, user space does not
Any new bits in ucontext.uc_sigmask placed on the signal stack are
opaque to user space (except in cases where user space already has a
larger sigset_t, as in glibc).
There are no changes to the real-time signals system call semantics,
as the kernel will honor the hard-coded sigsetsize value of 8 in
libc and behave as it has before these changes.
Signal numbers larger than 64 cannot be blocked or caught until user
space is updated, however their default action will work as
expected. This can cause one problem: a parent process that uses
the signal number a child exited with as an index into an array
without bounds checking can cause a crash. I’ve seen exactly one
instance of this in tcsh, and is, I think, a bug in tcsh.
User space has new signals, kernel does not
User space attempting to use a signal number not supported by the
kernel in system calls (eg, sigaction()) or other libc functions (eg,
sigaddset()) will result in EINVAL, as expected.
User space needs to know how to set the sigsetsize parameter to the
real time signal system calls and it can use getauxval(AT_SIGSET_SZ)
to determine this. If it returns zero the sigsetsize must be 8,
otherwise the kernel will accept sigsetsize between 8 and the return
value.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23188
Walt Drummond (8):
signals: Make the real-time signal system calls accept different sized
sigset_t from user space.
signals: Put the full signal mask on the signal stack for x86_64, X32
and ia32 compatibility mode
signals: Use a helper function to test if a signal is a real-time
signal.
signals: Remove sigmask() macro
signals: Better support cases where _NSIG_WORDS is greater than 2
signals: Round up _NSIG_WORDS
signals: Add signal debugging
signals: Support BSD VSTATUS, KERNINFO and SIGINFO
arch/alpha/kernel/signal.c | 4 +-
arch/m68k/include/asm/signal.h | 6 +-
arch/nios2/kernel/signal.c | 2 -
arch/x86/ia32/ia32_signal.c | 5 +-
arch/x86/include/asm/sighandling.h | 34 +++
arch/x86/include/asm/signal.h | 10 +-
arch/x86/include/uapi/asm/signal.h | 4 +-
arch/x86/kernel/signal.c | 11 +-
drivers/scsi/dpti.h | 2 -
drivers/tty/Makefile | 2 +-
drivers/tty/n_tty.c | 21 ++
drivers/tty/tty_io.c | 10 +-
drivers/tty/tty_ioctl.c | 4 +
drivers/tty/tty_status.c | 135 ++++++++++
fs/binfmt_elf.c | 1 +
fs/binfmt_elf_fdpic.c | 1 +
fs/ceph/addr.c | 2 +-
fs/jffs2/background.c | 2 +-
fs/lockd/svc.c | 1 -
fs/proc/array.c | 32 +--
fs/proc/base.c | 48 ++++
fs/signalfd.c | 26 +-
include/asm-generic/termios.h | 4 +-
include/linux/compat.h | 98 ++++++-
include/linux/sched.h | 52 +++-
include/linux/signal.h | 389 ++++++++++++++++++++--------
include/linux/tty.h | 8 +
include/uapi/asm-generic/ioctls.h | 2 +
include/uapi/asm-generic/signal.h | 8 +-
include/uapi/asm-generic/termbits.h | 34 +--
include/uapi/linux/auxvec.h | 1 +
kernel/compat.c | 30 +--
kernel/fork.c | 2 +-
kernel/ptrace.c | 18 +-
kernel/signal.c | 288 ++++++++++----------
kernel/sysctl.c | 41 +++
kernel/time/posix-timers.c | 3 +-
lib/Kconfig.debug | 10 +
security/apparmor/ipc.c | 4 +-
virt/kvm/kvm_main.c | 18 +-
40 files changed, 974 insertions(+), 399 deletions(-)
create mode 100644 drivers/tty/tty_status.c
--
2.30.2
On Mon, Jan 03, 2022 at 10:19:48AM -0800, Walt Drummond wrote:
> This patch set expands the number of signals in Linux beyond the
> current cap of 64. It sets a new cap at the somewhat arbitrary limit
> of 1024 signals, both because it’s what GLibc and MUSL support and
> because many architectures pad sigset_t or ucontext_t in the kernel to
> this cap. This limit is not fixed and can be further expanded within
> reason.
Could you explain the point of the entire exercise? Why do we need more
rt signals in the first place?
glibc has quite a bit of utterly pointless future-proofing. So "they
allow more" is not a good reason - not without a plausible use-case,
at least.
I simply wanted SIGINFO and VSTATUS, and that necessitated this. If
the limit of 1024 rt signals is an issue, that's an extremely simple
change to make.
On Mon, Jan 3, 2022 at 10:48 AM Al Viro <[email protected]> wrote:
>
> On Mon, Jan 03, 2022 at 10:19:48AM -0800, Walt Drummond wrote:
> > This patch set expands the number of signals in Linux beyond the
> > current cap of 64. It sets a new cap at the somewhat arbitrary limit
> > of 1024 signals, both because it’s what GLibc and MUSL support and
> > because many architectures pad sigset_t or ucontext_t in the kernel to
> > this cap. This limit is not fixed and can be further expanded within
> > reason.
>
> Could you explain the point of the entire exercise? Why do we need more
> rt signals in the first place?
>
> glibc has quite a bit of utterly pointless future-proofing. So "they
> allow more" is not a good reason - not without a plausible use-case,
> at least.
On Mon, Jan 03, 2022 at 05:00:58PM -0800, Walt Drummond wrote:
> I simply wanted SIGINFO and VSTATUS, and that necessitated this.
Elaborate, please. What exactly requires more than 32 rt signals?
On Tue, Jan 04, 2022 at 01:16:17AM +0000, Al Viro wrote:
> On Mon, Jan 03, 2022 at 05:00:58PM -0800, Walt Drummond wrote:
> > I simply wanted SIGINFO and VSTATUS, and that necessitated this.
>
> Elaborate, please. What exactly requires more than 32 rt signals?
More to the point, which system had SIGINFO >= SIGRTMIN? Or signals
with numbers greater than SIGRTMAX, for that matter?
I really don't get it...
Walt Drummond <[email protected]> writes:
> This patch set expands the number of signals in Linux beyond the
> current cap of 64. It sets a new cap at the somewhat arbitrary limit
> of 1024 signals, both because it’s what GLibc and MUSL support and
> because many architectures pad sigset_t or ucontext_t in the kernel to
> this cap. This limit is not fixed and can be further expanded within
> reason.
Ahhhh!!
Please let's not expand the number of signals supported if there is any
alternative. Signals only really make sense for supporting existing
interfaces. For new applications there is almost always something
better.
In the last discussion of adding SIGINFO
https://lore.kernel.org/lkml/[email protected]/ the
approach examined was to fix SIGPWR to be ignored by default and to
define SIGINFO as SIGPWR.
I dug through the previous conversations and there is a little debate
about what makes sense for SIGPWR to do by default. Alan Cox remembered
SIGPWR was sent when the power was restored, so ignoring SIGPWR by
default made sense. Ted Tso pointed out a different scenario where it
was reasonable for SIGPWR to be a terminating signal.
So far no one has actually found any applications that will regress if
SIGPWR becomes ignored by default. Furthermore on linux SIGPWR is only
defined to be sent to init, and init ignores all signals by default so
in practice SIGPWR is ignored by the only process that receives it
currently.
I am persuaded at least enough that I could see adding a patch to
linux-next and them sending to Linus that could be reverted if anything
broke.
Where I saw the last conversation falter was in making a persuasive
case of why SIGINFO was interesting to add. Given a world of ssh
connections I expect a persuasive case can be made. Especially if there
are a handful of utilities where it is already implemented that just
need to be built with SIGINFO defined.
> - Add BSD SIGINFO (and VSTATUS) as a test.
If your actual point is not to implement SIGINFO and you really have
another use case for expanding sigset_t please make it clear.
Without seeing the persuasive case for more signals I have to say that
adding more signals to the kernel sounds like a bad idea.
Eric
On Tue, Jan 04, 2022 at 12:00:34PM -0600, Eric W. Biederman wrote:
> I dug through the previous conversations and there is a little debate
> about what makes sense for SIGPWR to do by default. Alan Cox remembered
> SIGPWR was sent when the power was restored, so ignoring SIGPWR by
> default made sense. Ted Tso pointed out a different scenario where it
> was reasonable for SIGPWR to be a terminating signal.
>
> So far no one has actually found any applications that will regress if
> SIGPWR becomes ignored by default. Furthermore on linux SIGPWR is only
> defined to be sent to init, and init ignores all signals by default so
> in practice SIGPWR is ignored by the only process that receives it
> currently.
As it turns out, systemd does *not* ignore SIGPWR. Instead, it will
initiate the sigpwr target. From the systemd.special man page:
sigpwr.target
A special target that is started when systemd receives the
SIGPWR process signal, which is normally sent by the kernel
or UPS daemons when power fails.
And child processes of systemd are not ignoring SIGPWR. Instead, they
are getting terminated.
<tytso@cwcc>
41% /bin/sleep 50 &
[1] 180671
<tytso@cwcc>
42% kill -PWR 180671
[1]+ Power failure /bin/sleep 50
> Where I saw the last conversation falter was in making a persuasive
> case of why SIGINFO was interesting to add. Given a world of ssh
> connections I expect a persuasive case can be made. Especially if there
> are a handful of utilities where it is already implemented that just
> need to be built with SIGINFO defined.
One thing that's perhaps worth disentangling is the value of
supporting VSTATUS --- which is a control character much like VINTR
(^C) or VQUIT (control backslash) which is set via the c_cc[] array in
termios structure. Quoting from the termios man page:
VSTATUS
(not in POSIX; not supported under Linux; status
request: 024, DC4, Ctrl-T). Status character (STATUS).
Display status information at terminal, including state
of foreground process and amount of CPU time it has
consumed. Also sends a SIGINFO signal (not supported on
Linux) to the foreground process group.
The basic idea is that when you type C-t, you can find out information
about the currently running process. This is a feature that
originally comes from TOPS-10's TENEX operating system, and it is
supported today on FreeBSD and Mac OS. For example, it might display
something like this:
load: 2.39 cmd: ping 5374 running 0.00u 0.00s
The reason why SIGINFO is sent to the foreground process group is that
it gives the process an opportunity print application specific
information about currently running process. For example, maybe the C
compiler could print something like "parsing 2042 of 5000 header
files", or some such. :-)
There are people who wish that Linux supported Control-T / VSTATUS,
for example, just last week, on TUHS, the Unix greybeards list, there
were two such heartfelt wishes for Control-T support from two such
greybeards:
"It's my biggest annoyance with Linux that it doesn't [support
control-t]
- https://minnie.tuhs.org/pipermail/tuhs/2021-December/024849.html
"I personally can't stand using Linux, even casually for a very
short sys-admin task, because of this missing feature"
- https://minnie.tuhs.org/pipermail/tuhs/2021-December/024898.html
I claim, though, that we could implement VSTATUS without implenting
the SIGINFO part of the feature. Previous few applications *ever*
implemented SIGINFO signal handlers so they could give status
information, it's the hard one, since we don't have any spare signals
left. If we were to repurpose some lesser used signal, whether it be
SIGPWR, SIGLOST, or SIGSTKFLT, the danger is that there might be some
userspace program (such as a UPS monitoring program which wants to
trigger power fail handling, or a userspace NFSv4 process that wants
to signal that it was unable to recover a file's file lock after a
server reboot), and if we try to take over the signal assignment, it's
possible that we might get surprised. Furthermore, all of the
possibly unused signals that we might try to reclaim terminate the
process by default, and SIGINFO *has* to have a default signal
handling action of Ignore, since otherwise typing Control-T will end
up killing the current foreground application.
Personally, I don't care all that much about VSTATUS support --- I
used it when I was in university, but honestly, I've never missed it.
But if there is someone who wants to try to implement VSTATUS, and
make some Unix greybeards happy, and maybe even switch from FreeBSD to
Linux as a result, go wild. I'm not convinced, though, that adding
the SIGINFO part of the support is worth the effort.
Not only do almost no programs implement SIGINFO support, a lot of CPU
bound programs where this might be actually useful, end up running a
large number of processes in parallel. Take the "parsing 2042 of 5000
header files" example I gave above. Consider what would happen if gcc
implemented support for SIGINFO, but the user was running a "make -j
16" and typed Control-T. The result would be chaos!
So if you really miss Control-T, and it's the only thing holding back
a few FreeBSD users from Linux, I don't see the problem with
implementing that part of the feature. Why not just do the easy part
of the feature which is perhaps 5% of the work, and might provide 99%
of the benefit (at least for those people who care).
> Without seeing the persuasive case for more signals I have to say that
> adding more signals to the kernel sounds like a bad idea.
Concur, 100%.
- Ted
Fair enough. I'll abandon the signals part of this and just send out
the VSTATUS/Control-T part, after I address some comments from Greg.
Thanks.
On Tue, Jan 4, 2022 at 12:52 PM Theodore Ts'o <[email protected]> wrote:
>
> On Tue, Jan 04, 2022 at 12:00:34PM -0600, Eric W. Biederman wrote:
> > I dug through the previous conversations and there is a little debate
> > about what makes sense for SIGPWR to do by default. Alan Cox remembered
> > SIGPWR was sent when the power was restored, so ignoring SIGPWR by
> > default made sense. Ted Tso pointed out a different scenario where it
> > was reasonable for SIGPWR to be a terminating signal.
> >
> > So far no one has actually found any applications that will regress if
> > SIGPWR becomes ignored by default. Furthermore on linux SIGPWR is only
> > defined to be sent to init, and init ignores all signals by default so
> > in practice SIGPWR is ignored by the only process that receives it
> > currently.
>
> As it turns out, systemd does *not* ignore SIGPWR. Instead, it will
> initiate the sigpwr target. From the systemd.special man page:
>
> sigpwr.target
> A special target that is started when systemd receives the
> SIGPWR process signal, which is normally sent by the kernel
> or UPS daemons when power fails.
>
> And child processes of systemd are not ignoring SIGPWR. Instead, they
> are getting terminated.
>
> <tytso@cwcc>
> 41% /bin/sleep 50 &
> [1] 180671
> <tytso@cwcc>
> 42% kill -PWR 180671
> [1]+ Power failure /bin/sleep 50
>
> > Where I saw the last conversation falter was in making a persuasive
> > case of why SIGINFO was interesting to add. Given a world of ssh
> > connections I expect a persuasive case can be made. Especially if there
> > are a handful of utilities where it is already implemented that just
> > need to be built with SIGINFO defined.
>
> One thing that's perhaps worth disentangling is the value of
> supporting VSTATUS --- which is a control character much like VINTR
> (^C) or VQUIT (control backslash) which is set via the c_cc[] array in
> termios structure. Quoting from the termios man page:
>
> VSTATUS
> (not in POSIX; not supported under Linux; status
> request: 024, DC4, Ctrl-T). Status character (STATUS).
> Display status information at terminal, including state
> of foreground process and amount of CPU time it has
> consumed. Also sends a SIGINFO signal (not supported on
> Linux) to the foreground process group.
>
> The basic idea is that when you type C-t, you can find out information
> about the currently running process. This is a feature that
> originally comes from TOPS-10's TENEX operating system, and it is
> supported today on FreeBSD and Mac OS. For example, it might display
> something like this:
>
> load: 2.39 cmd: ping 5374 running 0.00u 0.00s
>
> The reason why SIGINFO is sent to the foreground process group is that
> it gives the process an opportunity print application specific
> information about currently running process. For example, maybe the C
> compiler could print something like "parsing 2042 of 5000 header
> files", or some such. :-)
>
> There are people who wish that Linux supported Control-T / VSTATUS,
> for example, just last week, on TUHS, the Unix greybeards list, there
> were two such heartfelt wishes for Control-T support from two such
> greybeards:
>
> "It's my biggest annoyance with Linux that it doesn't [support
> control-t]
> - https://minnie.tuhs.org/pipermail/tuhs/2021-December/024849.html
>
> "I personally can't stand using Linux, even casually for a very
> short sys-admin task, because of this missing feature"
> - https://minnie.tuhs.org/pipermail/tuhs/2021-December/024898.html
>
> I claim, though, that we could implement VSTATUS without implenting
> the SIGINFO part of the feature. Previous few applications *ever*
> implemented SIGINFO signal handlers so they could give status
> information, it's the hard one, since we don't have any spare signals
> left. If we were to repurpose some lesser used signal, whether it be
> SIGPWR, SIGLOST, or SIGSTKFLT, the danger is that there might be some
> userspace program (such as a UPS monitoring program which wants to
> trigger power fail handling, or a userspace NFSv4 process that wants
> to signal that it was unable to recover a file's file lock after a
> server reboot), and if we try to take over the signal assignment, it's
> possible that we might get surprised. Furthermore, all of the
> possibly unused signals that we might try to reclaim terminate the
> process by default, and SIGINFO *has* to have a default signal
> handling action of Ignore, since otherwise typing Control-T will end
> up killing the current foreground application.
>
> Personally, I don't care all that much about VSTATUS support --- I
> used it when I was in university, but honestly, I've never missed it.
> But if there is someone who wants to try to implement VSTATUS, and
> make some Unix greybeards happy, and maybe even switch from FreeBSD to
> Linux as a result, go wild. I'm not convinced, though, that adding
> the SIGINFO part of the support is worth the effort.
>
> Not only do almost no programs implement SIGINFO support, a lot of CPU
> bound programs where this might be actually useful, end up running a
> large number of processes in parallel. Take the "parsing 2042 of 5000
> header files" example I gave above. Consider what would happen if gcc
> implemented support for SIGINFO, but the user was running a "make -j
> 16" and typed Control-T. The result would be chaos!
>
> So if you really miss Control-T, and it's the only thing holding back
> a few FreeBSD users from Linux, I don't see the problem with
> implementing that part of the feature. Why not just do the easy part
> of the feature which is perhaps 5% of the work, and might provide 99%
> of the benefit (at least for those people who care).
>
> > Without seeing the persuasive case for more signals I have to say that
> > adding more signals to the kernel sounds like a bad idea.
>
> Concur, 100%.
>
> - Ted
"Theodore Ts'o" <[email protected]> writes:
> On Tue, Jan 04, 2022 at 12:00:34PM -0600, Eric W. Biederman wrote:
>> I dug through the previous conversations and there is a little debate
>> about what makes sense for SIGPWR to do by default. Alan Cox remembered
>> SIGPWR was sent when the power was restored, so ignoring SIGPWR by
>> default made sense. Ted Tso pointed out a different scenario where it
>> was reasonable for SIGPWR to be a terminating signal.
>>
>> So far no one has actually found any applications that will regress if
>> SIGPWR becomes ignored by default. Furthermore on linux SIGPWR is only
>> defined to be sent to init, and init ignores all signals by default so
>> in practice SIGPWR is ignored by the only process that receives it
>> currently.
>
> As it turns out, systemd does *not* ignore SIGPWR. Instead, it will
> initiate the sigpwr target. From the systemd.special man page:
>
> sigpwr.target
> A special target that is started when systemd receives the
> SIGPWR process signal, which is normally sent by the kernel
> or UPS daemons when power fails.
>
> And child processes of systemd are not ignoring SIGPWR. Instead, they
> are getting terminated.
>
> <tytso@cwcc>
> 41% /bin/sleep 50 &
> [1] 180671
> <tytso@cwcc>
> 42% kill -PWR 180671
> [1]+ Power failure /bin/sleep 50
That is all as expected, and does not demonstrate a regression would
happen if SIGPWR were to treat SIG_DFL as SIG_IGN, as SIGWINCH, SIGCONT,
SIGCHLD, SIGURG do. It does show there is the possibility of problems.
The practical question is does anything send SIGPWR to anything besides
init, and expect the process to handle SIGPWR or terminate?
Possibly easier to implement (if people desire) is to simply send
SIGCONT with an si_code that indicates someone pressed the VSTATUS
key. We have a per signal 32bit si_code space so that should
be comparatively easy.
> I claim, though, that we could implement VSTATUS without implenting
> the SIGINFO part of the feature.
I agree that is the place to start. And if we aren't going to use
SIGINFO perhaps we could have an equally good notification method
if anyone wants one. Say call an ioctl and get an fd that can
be read when a VSTATUS request comes in.
SIGINFO vs SIGCONT vs a fd vs something else is something we can sort
out when people get interested in modifying userspace.
Eric
On Tue, Jan 04, 2022 at 04:05:26PM -0600, Eric W. Biederman wrote:
>
> That is all as expected, and does not demonstrate a regression would
> happen if SIGPWR were to treat SIG_DFL as SIG_IGN, as SIGWINCH, SIGCONT,
> SIGCHLD, SIGURG do. It does show there is the possibility of problems.
>
> The practical question is does anything send SIGPWR to anything besides
> init, and expect the process to handle SIGPWR or terminate?
So if I *cared* about SIGINFO, what I'd do is ask the systemd
developers and users list if there are any users of the sigpwr.target
feature that they know of. And I'd also download all of the open
source UPS monitoring applications (and perhaps documentation of
closed-source UPS applications, such as for example APC's program) and
see if any of them are trying to send the SIGPWR signal.
I don't personally think it's worth the effort to do that research,
but maybe other people care enough to do the work.
> > I claim, though, that we could implement VSTATUS without implenting
> > the SIGINFO part of the feature.
>
> I agree that is the place to start. And if we aren't going to use
> SIGINFO perhaps we could have an equally good notification method
> if anyone wants one. Say call an ioctl and get an fd that can
> be read when a VSTATUS request comes in.
>
> SIGINFO vs SIGCONT vs a fd vs something else is something we can sort
> out when people get interested in modifying userspace.
Once VSTATUS support lands in the kernel, we can wait and see if there
is anyone who shows up wanting the SIGINFO functionality. Certainly
we have no shortage of userspace notification interfaces in Linux. :-)
- Ted
The only standard tools that support SIGINFO are sleep, dd and ping,
(and kill, for obvious reasons) so it's not like there's a vast hole
in the tooling or something, nor is there a large legacy software base
just waiting for SIGINFO to appear. So while I very much enjoyed
figuring out how to make SIGINFO work ...
I'll have the VSTATUS patch out in a little bit.
I also think there might be some merit in consolidating the 10
'sigsetsize != sizeof(sigset_t)' checks in a macro and adding comments
that wave people off on trying to do what I did. If that would be
useful, happy to provide the patch.
On Tue, Jan 4, 2022 at 2:23 PM Theodore Ts'o <[email protected]> wrote:
>
> On Tue, Jan 04, 2022 at 04:05:26PM -0600, Eric W. Biederman wrote:
> >
> > That is all as expected, and does not demonstrate a regression would
> > happen if SIGPWR were to treat SIG_DFL as SIG_IGN, as SIGWINCH, SIGCONT,
> > SIGCHLD, SIGURG do. It does show there is the possibility of problems.
> >
> > The practical question is does anything send SIGPWR to anything besides
> > init, and expect the process to handle SIGPWR or terminate?
>
> So if I *cared* about SIGINFO, what I'd do is ask the systemd
> developers and users list if there are any users of the sigpwr.target
> feature that they know of. And I'd also download all of the open
> source UPS monitoring applications (and perhaps documentation of
> closed-source UPS applications, such as for example APC's program) and
> see if any of them are trying to send the SIGPWR signal.
>
> I don't personally think it's worth the effort to do that research,
> but maybe other people care enough to do the work.
>
> > > I claim, though, that we could implement VSTATUS without implenting
> > > the SIGINFO part of the feature.
> >
> > I agree that is the place to start. And if we aren't going to use
> > SIGINFO perhaps we could have an equally good notification method
> > if anyone wants one. Say call an ioctl and get an fd that can
> > be read when a VSTATUS request comes in.
> >
> > SIGINFO vs SIGCONT vs a fd vs something else is something we can sort
> > out when people get interested in modifying userspace.
>
>
> Once VSTATUS support lands in the kernel, we can wait and see if there
> is anyone who shows up wanting the SIGINFO functionality. Certainly
> we have no shortage of userspace notification interfaces in Linux. :-)
>
> - Ted
On Tue, Jan 04, 2022 at 02:31:44PM -0800, Walt Drummond wrote:
> The only standard tools that support SIGINFO are sleep, dd and ping,
> (and kill, for obvious reasons) so it's not like there's a vast hole
> in the tooling or something, nor is there a large legacy software base
> just waiting for SIGINFO to appear. So while I very much enjoyed
> figuring out how to make SIGINFO work ...
As far as I recall, GNU make on *BSD does support SIGINFO (Not a
standard tool, but obviously an established one).
The developers of strace have expressed interest in SIGINFO support
to print tracer status messages (unfortunately, not on a public list).
Computational software can use this instead of stderr progress spam, if
run in an interactive fashion on a terminal, as it frequently is. There
is a user base, it's just not very vocal on kernel lists. :)
I generally agree with Ted's suggestion that we could merge the
easy-to-design part — the VSTATUS+kerninfo — first and deal with the
SIGINFO part later. The only concern I have here is that the "later"
part might never practically arrive... :)
Still, some notes on the SIGINFO/userspace-status
part:
On Tue, Jan 04, 2022 at 03:52:28PM -0500, Theodore Ts'o wrote:
> On Tue, Jan 04, 2022 at 12:00:34PM -0600, Eric W. Biederman wrote:
> > I dug through the previous conversations and there is a little debate
> > about what makes sense for SIGPWR to do by default. Alan Cox remembered
> > SIGPWR was sent when the power was restored, so ignoring SIGPWR by
> > default made sense. Ted Tso pointed out a different scenario where it
> > was reasonable for SIGPWR to be a terminating signal.
> >
> > So far no one has actually found any applications that will regress if
> > SIGPWR becomes ignored by default.
Some folks from linux-api@ claimed otherwise, but unfortunately didn't elaborate.
> > Furthermore on linux SIGPWR is only
> > defined to be sent to init, and init ignores all signals by default so
> > in practice SIGPWR is ignored by the only process that receives it
> > currently.
>
> As it turns out, systemd does *not* ignore SIGPWR. Instead, it will
> initiate the sigpwr target. From the systemd.special man page:
>
> sigpwr.target
> A special target that is started when systemd receives the
> SIGPWR process signal, which is normally sent by the kernel
> or UPS daemons when power fails.
Not sure what you had in mind; in case you're suggesting that systemd has
to drop the sigpwr.target semantics — it doesn't.
We don't need to ask systemd to drop sigpwr.target semantics.
To introduce SIGINFO == SIGPWR to the kernel, the only "breaking" change
we have to do is to change the default disposition for SIGPWR, i. e. the
behaviour if the signal is set to SIG_DFL. If a process (including PID
1) installs its own signal handler for SIGPWR to do something when PWR
is received (or blocks the signal and handles it via signalfd
notifications), then the default disposition does not matter at all, as
Eric notes further in this thread.
From a quick glance at systemd code, pid1's main() function calls
manager_new() calls manager_setup_signals(); this function, in turn,
blocks a set of signals, including PWR, and sets up a signalfd(2) on
that set. No changes have to be made in systemd, no need to remove the
sigpwr.target semantics.
The target activation does not send SIGPWR to anyone, it results in
systemd services being started and possibly stopped; the exact
consequences are out of scope for systemd.
There could be another concern: a VSTATUS keypress could result in
SIGINFO == SIGPWR being sent to pid1. In a correct implementation this
will not ever happen, because a sane PID 1 does not have (and never
acquires) a controlling terminal.
> And child processes of systemd are not ignoring SIGPWR. Instead, they
> are getting terminated.
>
> <tytso@cwcc>
> 41% /bin/sleep 50 &
> [1] 180671
> <tytso@cwcc>
> 42% kill -PWR 180671
> [1]+ Power failure /bin/sleep 50
All the possible surprises with the SIGINFO == SIGPWR approach we might
get stem from here, not from the sigpwr.target.
> > Where I saw the last conversation falter was in making a persuasive
> > case of why SIGINFO was interesting to add. Given a world of ssh
> > connections I expect a persuasive case can be made. Especially if there
> > are a handful of utilities where it is already implemented that just
> > need to be built with SIGINFO defined.
>
> One thing that's perhaps worth disentangling is the value of
> supporting VSTATUS --- which is a control character much like VINTR
> (^C) or VQUIT (control backslash) which is set via the c_cc[] array in
> termios structure. Quoting from the termios man page:
>
> VSTATUS
> (not in POSIX; not supported under Linux; status
> request: 024, DC4, Ctrl-T). Status character (STATUS).
> Display status information at terminal, including state
> of foreground process and amount of CPU time it has
> consumed. Also sends a SIGINFO signal (not supported on
> Linux) to the foreground process group.
>
> The basic idea is that when you type C-t, you can find out information
> about the currently running process. This is a feature that
> originally comes from TOPS-10's TENEX operating system, and it is
> supported today on FreeBSD and Mac OS. For example, it might display
> something like this:
>
> load: 2.39 cmd: ping 5374 running 0.00u 0.00s
>
> The reason why SIGINFO is sent to the foreground process group is that
> it gives the process an opportunity print application specific
> information about currently running process. For example, maybe the C
> compiler could print something like "parsing 2042 of 5000 header
> files", or some such. :-)
>
> There are people who wish that Linux supported Control-T / VSTATUS,
> for example, just last week, on TUHS, the Unix greybeards list, there
> were two such heartfelt wishes for Control-T support from two such
> greybeards:
>
> "It's my biggest annoyance with Linux that it doesn't [support
> control-t]
> - https://minnie.tuhs.org/pipermail/tuhs/2021-December/024849.html
>
> "I personally can't stand using Linux, even casually for a very
> short sys-admin task, because of this missing feature"
> - https://minnie.tuhs.org/pipermail/tuhs/2021-December/024898.html
>
> I claim, though, that we could implement VSTATUS without implenting
> the SIGINFO part of the feature. Previous few applications *ever*
> implemented SIGINFO signal handlers so they could give status
> information, it's the hard one, since we don't have any spare signals
> left. If we were to repurpose some lesser used signal, whether it be
> SIGPWR, SIGLOST, or SIGSTKFLT, the danger is that there might be some
> userspace program (such as a UPS monitoring program which wants to
> trigger power fail handling, or a userspace NFSv4 process that wants
> to signal that it was unable to recover a file's file lock after a
> server reboot), and if we try to take over the signal assignment, it's
> possible that we might get surprised. Furthermore, all of the
> possibly unused signals that we might try to reclaim terminate the
> process by default, and SIGINFO *has* to have a default signal
> handling action of Ignore, since otherwise typing Control-T will end
> up killing the current foreground application.
>
> Personally, I don't care all that much about VSTATUS support --- I
> used it when I was in university, but honestly, I've never missed it.
> But if there is someone who wants to try to implement VSTATUS, and
> make some Unix greybeards happy, and maybe even switch from FreeBSD to
> Linux as a result, go wild. I'm not convinced, though, that adding
> the SIGINFO part of the support is worth the effort.
>
> Not only do almost no programs implement SIGINFO support, a lot of CPU
To be fair, many programs are a lot younger than 4.3BSD, and with the
current ubiquity of Linux without VSTATUS, it's kind of a chicken-egg
problem. :)
> bound programs where this might be actually useful, end up running a
> large number of processes in parallel. Take the "parsing 2042 of 5000
> header files" example I gave above. Consider what would happen if gcc
> implemented support for SIGINFO, but the user was running a "make -j
> 16" and typed Control-T. The result would be chaos!
>
> So if you really miss Control-T, and it's the only thing holding back
> a few FreeBSD users from Linux, I don't see the problem with
> implementing that part of the feature. Why not just do the easy part
> of the feature which is perhaps 5% of the work, and might provide 99%
> of the benefit (at least for those people who care).
>
> > Without seeing the persuasive case for more signals I have to say that
> > adding more signals to the kernel sounds like a bad idea.
>
> Concur, 100%.
>
> - Ted
Hi!
> > The only standard tools that support SIGINFO are sleep, dd and ping,
> > (and kill, for obvious reasons) so it's not like there's a vast hole
> > in the tooling or something, nor is there a large legacy software base
> > just waiting for SIGINFO to appear. So while I very much enjoyed
> > figuring out how to make SIGINFO work ...
>
> As far as I recall, GNU make on *BSD does support SIGINFO (Not a
> standard tool, but obviously an established one).
>
> The developers of strace have expressed interest in SIGINFO support
> to print tracer status messages (unfortunately, not on a public list).
> Computational software can use this instead of stderr progress spam, if
> run in an interactive fashion on a terminal, as it frequently is. There
> is a user base, it's just not very vocal on kernel lists. :)
And often it would be useful if cp supported this. Yes, this
is feature I'd like to see.
BR, Pavel
--