Date:   Tue, 04 Jan 2022 12:00:34 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Walt Drummond <walt@...mmond.us>
Cc:     aacraid@...rosemi.com, viro@...iv.linux.org.uk,
        anna.schumaker@...app.com, arnd@...db.de, bsegall@...gle.com,
        bp@...en8.de, chuck.lever@...cle.com, bristot@...hat.com,
        dave.hansen@...ux.intel.com, dwmw2@...radead.org,
        dietmar.eggemann@....com, dinguyen@...nel.org,
        geert@...ux-m68k.org, gregkh@...uxfoundation.org, hpa@...or.com,
        idryomov@...il.com, mingo@...hat.com, yzaikin@...gle.com,
        ink@...assic.park.msu.ru, jejb@...ux.ibm.com, jmorris@...ei.org,
        bfields@...ldses.org, jlayton@...nel.org, jirislaby@...nel.org,
        john.johansen@...onical.com, juri.lelli@...hat.com,
        keescook@...omium.org, mcgrof@...nel.org,
        martin.petersen@...cle.com, mattst88@...il.com, mgorman@...e.de,
        oleg@...hat.com, pbonzini@...hat.com, peterz@...radead.org,
        rth@...ddle.net, richard@....at, serge@...lyn.com,
        rostedt@...dmis.org, tglx@...utronix.de,
        trond.myklebust@...merspace.com, vincent.guittot@...aro.org,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        ceph-devel@...r.kernel.org, kvm@...r.kernel.org,
        linux-alpha@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-m68k@...r.kernel.org,
        linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [RFC PATCH 0/8] signals: Support more than 64 signals

Walt Drummond <walt@...mmond.us> 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/20190625161153.29811-1-ar@cs.msu.ru/ 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

Powered by blists - more mailing lists