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