Messages in this thread | | | From | (Eric W. Biederman) | Date | Wed, 07 Apr 2021 11:56:36 -0500 | Subject | Re: [PATCH v9 4/8] Reimplement RLIMIT_NPROC on top of ucounts |
| |
Alexey Gladkov <gladkov.alexey@gmail.com> writes:
> On Mon, Apr 05, 2021 at 11:56:35AM -0500, Eric W. Biederman wrote: >> >> Also when setting ns->ucount_max[] in create_user_ns because one value >> is signed and the other is unsigned. Care should be taken so that >> rlimit_infinity is translated into the largest positive value the >> type can hold. > > You mean like that ? > > ns->ucount_max[UCOUNT_RLIMIT_NPROC] = rlimit(RLIMIT_NPROC) <= LONG_MAX ? > rlimit(RLIMIT_NPROC) : LONG_MAX; > ns->ucount_max[UCOUNT_RLIMIT_MSGQUEUE] = rlimit(RLIMIT_MSGQUEUE) <= LONG_MAX ? > rlimit(RLIMIT_MSGQUEUE) : LONG_MAX; > ns->ucount_max[UCOUNT_RLIMIT_SIGPENDING] = rlimit(RLIMIT_SIGPENDING) <= LONG_MAX ? > rlimit(RLIMIT_SIGPENDING) : LONG_MAX; > ns->ucount_max[UCOUNT_RLIMIT_MEMLOCK] = rlimit(RLIMIT_MEMLOCK) <= LONG_MAX ? > rlimit(RLIMIT_MEMLOCK) : LONG_MAX;
Yes.
I only got as far as: if (rlimit(RLIMI_NNN) == RLIM_INFINITY) { ns->ucount_max[UCOUNT_LIMIT_NNN] = LONG_MAX; } else { ns->ucount_max[UCOUNT_LMIT_NNN] = rlmit(RLIMIT_NNN); } But forcing everything about LONG_MAX to LONG_MAX actually looks better in practice. Especially as that is effectively RLIMIT_INFINITY anyway.
Eric
| |