public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
	Zhang Qiao <zhangqiao22@huawei.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	keescook@chromium.org, Peter Zijlstra <peterz@infradead.org>,
	elver@google.com, legion@kernel.org, oleg@redhat.com,
	brauner@kernel.org
Subject: Re: Question about kill a process group
Date: Thu, 28 Apr 2022 14:33:27 +0200	[thread overview]
Message-ID: <87zgk5v148.ffs@tglx> (raw)
In-Reply-To: <874k2mtny7.fsf@email.froward.int.ebiederm.org>

On Thu, Apr 21 2022 at 11:12, Eric W. Biederman wrote:
> Zhang Qiao <zhangqiao22@huawei.com> writes:
>>> How many children are being created in this test?  Several million?
>>
>>   There are about 300,000+ processes.
>
> Not as many as I was guessing, but still enough to cause a huge
> wait on locks.

Indeed. It's about 4-5us per process to send the signal on a 2GHz
SKL-X. So with 20000k processes tasklist lock is read held for 1 second.

> I do agree over 1 second for holding a spin lock is ridiculous and a
> denial of service attack.

Exactly. Even holding it for 100ms (20k forks) is daft.

So unless the number of PIDs for a user is limited this _is_ an
unpriviledged DoS vector.

> Anyway I am very curious why you are the only one seeing a problem with
> fork12.

It's fully reproducible. It's just a question how big the machine is and
what the PID limits are on the box you are testing on.

>>> I suspect the issue really is the thundering hurd of a million+
>>> processes synchronizing on a single lock.

There are several issues:

 1) The parent sending the signal is holding the lock for an
    obscene long time.

 2) Every signaled child runs into tasklist lock contention as all of
    them need to aquire it for write in do_exit(). That means within
    (NR_CPUS - 1) * 5usec all CPUs are spinning on tasklist lock with
    interrupts disabled up to the point where #1 has finished.

So depending on the number of childs and the configured limits of a
lockup detector this is sufficient to trigger a warning.

Thanks,

        tglx

  parent reply	other threads:[~2022-04-28 12:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29  8:07 Question about kill a process group Zhang Qiao
2022-04-02  2:22 ` Zhang Qiao
2022-04-13  1:56   ` Zhang Qiao
2022-04-13 15:47     ` Eric W. Biederman
2022-04-14 11:40       ` Zhang Qiao
2022-04-21 16:12         ` Eric W. Biederman
2022-04-28  2:05           ` Zhang Qiao
2022-04-28 12:33           ` Thomas Gleixner [this message]
2022-05-11 18:33             ` Eric W. Biederman
2022-05-11 22:53               ` Thomas Gleixner
2022-05-12 18:23                 ` Eric W. Biederman
2022-09-26  7:32                   ` Zhang Qiao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zgk5v148.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=brauner@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=elver@google.com \
    --cc=keescook@chromium.org \
    --cc=legion@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=zhangqiao22@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox