From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 220F4C433EF for ; Wed, 11 May 2022 18:33:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346321AbiEKSdo (ORCPT ); Wed, 11 May 2022 14:33:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346356AbiEKSde (ORCPT ); Wed, 11 May 2022 14:33:34 -0400 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B166415F6CF for ; Wed, 11 May 2022 11:33:32 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]:54628) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nor9O-00FzwP-Pv; Wed, 11 May 2022 12:33:30 -0600 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:37846 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nor9M-002r2a-CN; Wed, 11 May 2022 12:33:30 -0600 From: "Eric W. Biederman" To: Thomas Gleixner Cc: Zhang Qiao , lkml , keescook@chromium.org, Peter Zijlstra , elver@google.com, legion@kernel.org, oleg@redhat.com, brauner@kernel.org References: <87ilrd2dfj.fsf@email.froward.int.ebiederm.org> <58223bd3-b63b-0c2b-abcc-e1136090d060@huawei.com> <874k2mtny7.fsf@email.froward.int.ebiederm.org> <87zgk5v148.ffs@tglx> Date: Wed, 11 May 2022 13:33:21 -0500 In-Reply-To: <87zgk5v148.ffs@tglx> (Thomas Gleixner's message of "Thu, 28 Apr 2022 14:33:27 +0200") Message-ID: <87a6bnudfy.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1nor9M-002r2a-CN;;;mid=<87a6bnudfy.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=softfail X-XM-AID: U2FsdGVkX18c8RREKaMvog+JcKW3X0/sbAa5ThrtZRE= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: Question about kill a process group X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas Gleixner writes: > On Thu, Apr 21 2022 at 11:12, Eric W. Biederman wrote: >> Zhang Qiao 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. After having slept on this a bit it finally occurred to me the semi-obvious solution to this issue is to convert tasklist_lock from a rw-spinlock to rw-semaphore. The challenge is finding the users (tty layer?) that generate signals from interrupt context and redirect that signal generation. Once signals holding tasklist_lock are no longer generated from interrupt context irqs no longer need to be disabled and after verifying tasklist_lock isn't held under any other spinlocks it can be converted to a semaphore. It won't help the signal delivery times, but it should reduce the effect on the rest of the system, and prevent watchdogs from firing. I don't know if I have time to do any of that now, but it does seem a reasonable direction to move the code in. Eric