linux-kernel - Re: [PATCH -next v3 2/2] blk-throttle: fix io hung due to configuration updates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <97be6af0-ea94-f4ee-5ab2-02b6fc02cbff@huawei.com>
Date:   Sat, 21 May 2022 11:51:11 +0800
From:   "yukuai (C)" <yukuai3@...wei.com>
To:     Tejun Heo <tj@...nel.org>,
        Michal Koutný <mkoutny@...e.com>
CC:     <axboe@...nel.dk>, <ming.lei@...hat.com>, <geert@...ux-m68k.org>,
        <cgroups@...r.kernel.org>, <linux-block@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <yi.zhang@...wei.com>
Subject: Re: [PATCH -next v3 2/2] blk-throttle: fix io hung due to
 configuration updates

在 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.
>