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 96B63C433EF for ; Sat, 21 May 2022 03:51:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354499AbiEUDvW (ORCPT ); Fri, 20 May 2022 23:51:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354490AbiEUDvT (ORCPT ); Fri, 20 May 2022 23:51:19 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B5A0DF41; Fri, 20 May 2022 20:51:15 -0700 (PDT) Received: from kwepemi500009.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4L4qNX0XZszgY8y; Sat, 21 May 2022 11:49:48 +0800 (CST) Received: from kwepemm600009.china.huawei.com (7.193.23.164) by kwepemi500009.china.huawei.com (7.221.188.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 21 May 2022 11:51:13 +0800 Received: from [10.174.176.73] (10.174.176.73) by kwepemm600009.china.huawei.com (7.193.23.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 21 May 2022 11:51:12 +0800 Subject: Re: [PATCH -next v3 2/2] blk-throttle: fix io hung due to configuration updates To: Tejun Heo , =?UTF-8?Q?Michal_Koutn=c3=bd?= CC: , , , , , , References: <20220519085811.879097-1-yukuai3@huawei.com> <20220519085811.879097-3-yukuai3@huawei.com> <20220519095857.GE16096@blackbody.suse.cz> <20220519161026.GG16096@blackbody.suse.cz> <73464ca6-9412-cc55-d9c0-f2e8a10f0607@huawei.com> <20220520160305.GA17335@blackbody.suse.cz> From: "yukuai (C)" Message-ID: <97be6af0-ea94-f4ee-5ab2-02b6fc02cbff@huawei.com> Date: Sat, 21 May 2022 11:51:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.176.73] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600009.china.huawei.com (7.193.23.164) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 在 2022/05/21 0:20, Tejun Heo 写道: > Hello, > > On Fri, May 20, 2022 at 06:03:05PM +0200, Michal Koutný wrote: >>> Then io hung can be triggered by always submmiting new configuration >>> before the throttled bio is dispatched. >> >> How big is this a problem actually? Is it only shooting oneself in the leg >> or can there be a user who's privileged enough to modify throttling >> configuration yet not privileged enough to justify the hung's >> consequences (like some global FS locks). > > So, the problem in itself is of the self-inflicted type and I'd prefer to > ignore it. Unfortunately, the kernel doesn't have the kind of isolation > where stalling out some aribtrary tasks is generally safe, especially not > blk-throtl as it doesn't handle bio_issue_as_root() and thus can have a > pretty severe priority inversions where IOs which can block system-wide > operations (e.g. memory reclaim) get trapped in a random cgroup. Hi, Tejun It's right the problem is self-inflicted. However, I do think with Michal's suggestion, how throttled bios are handled while new config is submitted really make sense from the functional poinit of view. Do you think the solution is OK? Thnaks, Kuai > > Even ignoring that, the kernel in general assumes some forward progress from > everybody and when a part stalls it's relatively easy to spread to the rest > of the system, sometimes gradually, sometimes suddenly - e.g. if the stalled > IO was being performed while holding the mmap_sem, which isn't rare, then > anything which tries to read its proc cmdline will hang behind it. > > So, we wanna avoid a situation where a non-priviledged user can cause > indefinite UNINTERRUPTIBLE sleeps to prevent local DoS attacks. I mean, > preventing local attacks is almost never fool proof but we don't want to > make it too easy at least. > > Thanks. >