On Mon, Feb 14, 2022 at 09:23:09AM -0600, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> wrote: > Pretty much. The function essentially only exists so that we can > handle the weirdness of RLIMIT_NPROC. > Now that I have discovered the > weirdness of RLIMIT_NPROC is old historical sloppiness I expect the > proper solution is to rework how RLIMIT_NPROC operates and to remove > is_ucounts_overlimit all together. The fork path could make do with some kind of atomic add+check (similar to inc_ucounts) and overflows would be sanitized by that. (Seems to apply to other former RLIMIT_* per-user counters too.) The is_ucounts_overlimit() and overflowable increment indeed appears necessary only to satisfy the set*uid+execve pair. For the sake of bug-fixing, both the patches 5/8 and 6/8 can have Reviewed-by: Michal Koutný <mkoutny@xxxxxxxx> Michal
