Re: [PATCH] sched/autogroup: Serialize nice rate-limit updates

[Hui Su <sh_def@163.com>]

> Is it really that big of a problem?

I agree that the impact is limited. The issue is that concurrent
unprivileged callers can pass the same expired rate-limit window and
weaken the intended throttling of the expensive task-group update path.

> That comment suggests we don't want to take any global locks but this
> adds one more? Is that a good idea?
>
> Spinlock looks too heavy-handed for this. You can perhaps do a simple
> try_cmpxchg() and the ones that fails it can simply return -EAGAIN.
>
> Thoughts?

I agree that try_cmpxchg() is a better fit than adding another global
lock. One unprivileged caller can claim an expired rate-limit window,
while unprivileged callers that lose the cmpxchg can return -EAGAIN
without serializing on a spinlock or entering the expensive update path.

The v2 implementation needs to preserve the existing CAP_SYS_ADMIN behavior:
privileged callers bypass the rate-limit check but still update next. Thus,
an admin caller that loses the cmpxchg must retry rather than return
-EAGAIN.

I'll rework this along those lines for v2. I'll rerun the KCSAN and
rate-limit tests and add coverage for concurrent CAP_SYS_ADMIN callers
to verify that cmpxchg contention does not introduce an -EAGAIN result
for privileged callers.

Thanks for the review.

Thanks and Regards,
Hui