From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47DFEC43461 for ; Wed, 7 Apr 2021 16:56:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E49826128D for ; Wed, 7 Apr 2021 16:56:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E49826128D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2C0C06B0072; Wed, 7 Apr 2021 12:56:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 26FAE6B0073; Wed, 7 Apr 2021 12:56:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 110976B007D; Wed, 7 Apr 2021 12:56:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) by kanga.kvack.org (Postfix) with ESMTP id E809C6B0072 for ; Wed, 7 Apr 2021 12:56:45 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 963096126 for ; Wed, 7 Apr 2021 16:56:45 +0000 (UTC) X-FDA: 78006175170.23.81ABD69 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by imf20.hostedemail.com (Postfix) with ESMTP id 6404A135 for ; Wed, 7 Apr 2021 16:56:42 +0000 (UTC) Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lUBTt-00CZh7-I0; Wed, 07 Apr 2021 10:56:41 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1lUBTs-0007Tf-91; Wed, 07 Apr 2021 10:56:41 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Alexey Gladkov Cc: LKML , Kernel Hardening , Linux Containers , linux-mm@kvack.org, Andrew Morton , Christian Brauner , Jann Horn , Jens Axboe , Kees Cook , Linus Torvalds , Oleg Nesterov References: <8f0c2888b4e92d51239e154b82d75972e7e39833.1616533074.git.gladkov.alexey@gmail.com> <20210406154444.icpvezlq3izzxf5t@example.org> Date: Wed, 07 Apr 2021 11:56:36 -0500 In-Reply-To: <20210406154444.icpvezlq3izzxf5t@example.org> (Alexey Gladkov's message of "Tue, 6 Apr 2021 17:44:44 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1lUBTs-0007Tf-91;;;mid=;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18gGOagHueeOSvjjB9O1FjohVGYorUmAaY= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v9 4/8] Reimplement RLIMIT_NPROC on top of ucounts X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6404A135 X-Stat-Signature: yf8w617hydpkqsru3qeytw5onifum7pz Received-SPF: none (xmission.com>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=out03.mta.xmission.com; client-ip=166.70.13.233 X-HE-DKIM-Result: none/none X-HE-Tag: 1617814602-470912 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Alexey Gladkov 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