From: "yukuai (C)" <yukuai3@huawei.com> To: "Tejun Heo" <tj@kernel.org>, "Michal Koutný" <mkoutny@suse.com> Cc: <axboe@kernel.dk>, <ming.lei@redhat.com>, <geert@linux-m68k.org>, <cgroups@vger.kernel.org>, <linux-block@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <yi.zhang@huawei.com> Subject: Re: [PATCH -next v3 2/2] blk-throttle: fix io hung due to configuration updates Date: Sat, 21 May 2022 11:51:11 +0800 [thread overview] Message-ID: <97be6af0-ea94-f4ee-5ab2-02b6fc02cbff@huawei.com> (raw) In-Reply-To: <Yoe/1BRYzSRI0JBd@slm.duckdns.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. >
WARNING: multiple messages have this Message-ID (diff)
From: "yukuai (C)" <yukuai3@huawei.com> To: "Tejun Heo" <tj@kernel.org>, "Michal Koutný" <mkoutny@suse.com> Cc: axboe@kernel.dk, ming.lei@redhat.com, geert@linux-m68k.org, cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com Subject: Re: [PATCH -next v3 2/2] blk-throttle: fix io hung due to configuration updates Date: Sat, 21 May 2022 11:51:11 +0800 [thread overview] Message-ID: <97be6af0-ea94-f4ee-5ab2-02b6fc02cbff@huawei.com> (raw) In-Reply-To: <Yoe/1BRYzSRI0JBd@slm.duckdns.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. >
next prev parent reply other threads:[~2022-05-21 3:51 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-19 8:58 [PATCH -next v3 0/2] bugfix for blk-throttle Yu Kuai 2022-05-19 8:58 ` Yu Kuai 2022-05-19 8:58 ` [PATCH -next v3 1/2] blk-throttle: fix that io throttle can only work for single bio Yu Kuai 2022-05-19 8:58 ` Yu Kuai 2022-05-19 10:42 ` Ming Lei 2022-05-19 8:58 ` [PATCH -next v3 2/2] blk-throttle: fix io hung due to configuration updates Yu Kuai 2022-05-19 8:58 ` Yu Kuai 2022-05-19 9:58 ` Michal Koutný 2022-05-19 12:14 ` yukuai (C) 2022-05-19 12:14 ` yukuai (C) 2022-05-19 16:10 ` Michal Koutný 2022-05-19 16:10 ` Michal Koutný 2022-05-20 1:22 ` yukuai (C) 2022-05-20 1:22 ` yukuai (C) 2022-05-20 1:36 ` yukuai (C) 2022-05-20 1:36 ` yukuai (C) 2022-05-20 16:03 ` Michal Koutný 2022-05-20 16:20 ` Tejun Heo 2022-05-21 3:51 ` yukuai (C) [this message] 2022-05-21 3:51 ` yukuai (C) 2022-05-21 5:00 ` Tejun Heo 2022-05-21 5:00 ` Tejun Heo 2022-05-21 3:01 ` yukuai (C) 2022-05-21 3:01 ` yukuai (C)
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=97be6af0-ea94-f4ee-5ab2-02b6fc02cbff@huawei.com \ --to=yukuai3@huawei.com \ --cc=axboe@kernel.dk \ --cc=cgroups@vger.kernel.org \ --cc=geert@linux-m68k.org \ --cc=linux-block@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=ming.lei@redhat.com \ --cc=mkoutny@suse.com \ --cc=tj@kernel.org \ --cc=yi.zhang@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.