Re: git: 69413598d266 - main - signal: use proc_iterate to save on work
- In reply to: Konstantin Belousov : "Re: git: 69413598d266 - main - signal: use proc_iterate to save on work"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 07 Sep 2022 09:36:03 UTC
On 9/7/22, Konstantin Belousov <kostikbel@gmail.com> wrote:
> On Mon, Sep 05, 2022 at 06:07:08PM +0200, Mateusz Guzik wrote:
>> On 9/5/22, Konstantin Belousov <kostikbel@gmail.com> wrote:
>> > On Mon, Sep 05, 2022 at 11:56:15AM +0000, Mateusz Guzik wrote:
>> >> The branch main has been updated by mjg:
>> >>
>> >> URL:
>> >> https://cgit.FreeBSD.org/src/commit/?id=69413598d2660054e29cac9454fe18c08e3bf36d
>> >>
>> >> commit 69413598d2660054e29cac9454fe18c08e3bf36d
>> >> Author: Mateusz Guzik <mjg@FreeBSD.org>
>> >> AuthorDate: 2022-03-10 18:58:12 +0000
>> >> Commit: Mateusz Guzik <mjg@FreeBSD.org>
>> >> CommitDate: 2022-09-05 11:54:47 +0000
>> >>
>> >> signal: use proc_iterate to save on work
>> >>
>> >> Most notably poudriere performs kill -9 -1 in jails for each port
>> >> being built. This reduces the scan from hundrends of processes to
>> >> literally 1.
>> >>
>> >> Reviewed by: jamie, markj
>> >> Differential Revision: https://reviews.freebsd.org/D34522
>> >> ---
>> >> sys/kern/kern_sig.c | 39 ++++++++++++++++++++++++++++-----------
>> >> 1 file changed, 28 insertions(+), 11 deletions(-)
>> >>
>> >> diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c
>> >> index 6fd3eca0a14e..c50a37de07e6 100644
>> >> --- a/sys/kern/kern_sig.c
>> >> +++ b/sys/kern/kern_sig.c
>> >> @@ -1776,18 +1776,13 @@ struct killpg1_ctx {
>> >> };
>> >>
>> >> static void
>> >> -killpg1_sendsig(struct proc *p, bool notself, struct killpg1_ctx
>> >> *arg)
>> >> +killpg1_sendsig_locked(struct proc *p, struct killpg1_ctx *arg)
>> >> {
>> >> int err;
>> >>
>> >> - if (p->p_pid <= 1 || (p->p_flag & P_SYSTEM) != 0 ||
>> >> - (notself && p == arg->td->td_proc) || p->p_state == PRS_NEW)
>> >> - return;
>> >> - PROC_LOCK(p);
>> >> err = p_cansignal(arg->td, p, arg->sig);
>> >> if (err == 0 && arg->sig != 0)
>> >> pksignal(p, arg->sig, arg->ksi);
>> >> - PROC_UNLOCK(p);
>> >> if (err != ESRCH)
>> >> arg->found = true;
>> >> if (err == 0)
>> >> @@ -1796,6 +1791,31 @@ killpg1_sendsig(struct proc *p, bool notself,
>> >> struct killpg1_ctx *arg)
>> >> arg->ret = err;
>> >> }
>> >>
>> >> +static void
>> >> +killpg1_sendsig(struct proc *p, bool notself, struct killpg1_ctx
>> >> *arg)
>> >> +{
>> >> +
>> >> + if (p->p_pid <= 1 || (p->p_flag & P_SYSTEM) != 0 ||
>> >> + (notself && p == arg->td->td_proc) || p->p_state == PRS_NEW)
>> >> + return;
>> >> +
>> >> + PROC_LOCK(p);
>> >> + killpg1_sendsig_locked(p, arg);
>> >> + PROC_UNLOCK(p);
>> >> +}
>> >> +
>> >> +static void
>> >> +kill_processes_prison_cb(struct proc *p, void *arg)
>> >> +{
>> >> + struct killpg1_ctx *ctx = arg;
>> >> +
>> >> + if (p->p_pid <= 1 || (p->p_flag & P_SYSTEM) != 0 ||
>> >> + (p == ctx->td->td_proc) || p->p_state == PRS_NEW)
>> > Extra ()
>> >
>> >> + return;
>> >> +
>> >> + killpg1_sendsig_locked(p, ctx);
>> >> +}
>> >> +
>> >> /*
>> >> * Common code for kill process group/broadcast kill.
>> >> * cp is calling process.
>> >> @@ -1817,11 +1837,8 @@ killpg1(struct thread *td, int sig, int pgid,
>> >> int
>> >> all, ksiginfo_t *ksi)
>> >> /*
>> >> * broadcast
>> >> */
>> >> - sx_slock(&allproc_lock);
>> >> - FOREACH_PROC_IN_SYSTEM(p) {
>> >> - killpg1_sendsig(p, true, &arg);
>> >> - }
>> >> - sx_sunlock(&allproc_lock);
>> >> + prison_proc_iterate(td->td_ucred->cr_prison,
>> >> + kill_processes_prison_cb, &arg);
>> >> } else {
>> >> sx_slock(&proctree_lock);
>> >> if (pgid == 0) {
>> >
>> > I believe before your change, kill(-1) would kill all processes in the
>> > jail, which includes all processes in the nested jails. Now, it seems
>> > that linkage prevents iterating over the nested jails, am I missing it?
>> >
>>
>> See the pr_childcount check. If any jails pop up, there is a full scan
>> like right now. And if the count transitions 0 -> 1 -> 0 during the
>> iteration of the loop, there is nobody left to signal.
> I see.
>
>>
>> All previously existing races remain unaffected.
> No, now you are potentially signalling some processes more than once.
> Sending the signal is not idempotent operation.
>
You have a point, I was pretty fixated on just kill -9 -1.
I'm going going to have to ponder a little bit, perhaps it is time to
finally fix the races.
--
Mateusz Guzik <mjguzik gmail.com>