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 947D4C433EF for ; Fri, 1 Jul 2022 07:34:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234876AbiGAHes (ORCPT ); Fri, 1 Jul 2022 03:34:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232764AbiGAHep (ORCPT ); Fri, 1 Jul 2022 03:34:45 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 960AE4132B; Fri, 1 Jul 2022 00:34:44 -0700 (PDT) Received: from dggpeml500025.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4LZ6NR3mhQz1L8fQ; Fri, 1 Jul 2022 15:32:23 +0800 (CST) Received: from dggpeml500018.china.huawei.com (7.185.36.186) by dggpeml500025.china.huawei.com (7.185.36.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 1 Jul 2022 15:34:42 +0800 Received: from [10.67.111.186] (10.67.111.186) by dggpeml500018.china.huawei.com (7.185.36.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 1 Jul 2022 15:34:42 +0800 Message-ID: Date: Fri, 1 Jul 2022 15:34:41 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 Subject: Re: [Question] The system may be stuck if there is a cpu cgroup cpu.cfs_quato_us is very low To: Tejun Heo CC: , , Juri Lelli , Vincent Guittot , , , , lkml , , , , , Steven Rostedt , References: <5987be34-b527-4ff5-a17d-5f6f0dc94d6d@huawei.com> From: Zhang Qiao In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.111.186] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpeml500018.china.huawei.com (7.185.36.186) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, tejun Thanks for your reply. 在 2022/6/27 16:32, Tejun Heo 写道: > Hello, > > On Mon, Jun 27, 2022 at 02:50:25PM +0800, Zhang Qiao wrote: >> Becuase the task cgroup's cpu.cfs_quota_us is very small and >> test_fork's load is very heavy, the test_fork may be throttled long >> time, therefore, the cgroup_threadgroup_rw_sem read lock is held for >> a long time, other processes will get stuck waiting for the lock: > > Yeah, this is a known problem and can happen with other locks too. The > solution prolly is only throttling while in or when about to return to > userspace. There is one really important and wide-spread assumption in > the kernel: > > If things get blocked on some shared resource, whatever is holding > the resource ends up using more of the system to exit the critical > section faster and thus unblocks others ASAP. IOW, things running in > kernel are work-conserving. > > The cpu bw controller gives the userspace a rather easy way to break > this assumption and thus is rather fundamentally broken. This is > basically the same problem we had with the old cgroup freezer > implementation which trapped threads in random locations in the > kernel. > so, if we want to completely slove this problem, is the best way to change the cfs bw controller throttle mechanism? for example, throttle tasks in a safe location. Thanks. Qiao > So, right now, it's rather broken and can easily be used as an dos > attack vector. > > Thanks. >