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