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=-13.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 75E98C4320A for ; Tue, 24 Aug 2021 01:20:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 516F4613A7 for ; Tue, 24 Aug 2021 01:20:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233637AbhHXBUw convert rfc822-to-8bit (ORCPT ); Mon, 23 Aug 2021 21:20:52 -0400 Received: from mga02.intel.com ([134.134.136.20]:32082 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233487AbhHXBUm (ORCPT ); Mon, 23 Aug 2021 21:20:42 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10085"; a="204408296" X-IronPort-AV: E=Sophos;i="5.84,346,1620716400"; d="scan'208";a="204408296" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Aug 2021 18:19:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,346,1620716400"; d="scan'208";a="443630247" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga002.jf.intel.com with ESMTP; 23 Aug 2021 18:19:55 -0700 Received: from shsmsx602.ccr.corp.intel.com (10.109.6.142) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 18:19:54 -0700 Received: from shsmsx605.ccr.corp.intel.com (10.109.6.215) by SHSMSX602.ccr.corp.intel.com (10.109.6.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 24 Aug 2021 09:19:53 +0800 Received: from shsmsx605.ccr.corp.intel.com ([10.109.6.215]) by SHSMSX605.ccr.corp.intel.com ([10.109.6.215]) with mapi id 15.01.2242.010; Tue, 24 Aug 2021 09:19:53 +0800 From: "Ma, XinjianX" To: "Eric W. Biederman" , Alexey Gladkov CC: "linux-kselftest@vger.kernel.org" , lkp , "akpm@linux-foundation.org" , "axboe@kernel.dk" , "christian.brauner@ubuntu.com" , "containers@lists.linux-foundation.org" , "jannh@google.com" , "keescook@chromium.org" , "kernel-hardening@lists.openwall.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "oleg@redhat.com" , "torvalds@linux-foundation.org" Subject: RE: [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns Thread-Topic: [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns Thread-Index: AQHXmGLx+8SQcsWA7kykjkjhccpFyquB2fCQ Date: Tue, 24 Aug 2021 01:19:52 +0000 Message-ID: <06bb27f1d79243febf9ddc4633c4e084@intel.com> References: <87a6lgysxp.fsf@disp2133> <20210818131117.x7omzb2wkjq7le3s@example.org> <87o89ttqql.fsf@disp2133> <20210819172618.qwrrw4m7wt33wfmz@example.org> <87eeajswfc.fsf_-_@disp2133> In-Reply-To: <87eeajswfc.fsf_-_@disp2133> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.1.3 dlp-reaction: no-action x-originating-ip: [10.108.32.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Eric W. Biederman > Sent: Tuesday, August 24, 2021 5:07 AM > To: Alexey Gladkov > Cc: Ma, XinjianX ; linux-kselftest@vger.kernel.org; > lkp ; akpm@linux-foundation.org; axboe@kernel.dk; > christian.brauner@ubuntu.com; containers@lists.linux-foundation.org; > jannh@google.com; keescook@chromium.org; kernel- > hardening@lists.openwall.com; linux-kernel@vger.kernel.org; linux- > mm@kvack.org; oleg@redhat.com; torvalds@linux-foundation.org > Subject: [PATCH] ucounts: Fix regression preventing increasing of rlimits in > init_user_ns > > > "Ma, XinjianX" reported: > > > When lkp team run kernel selftests, we found after these series of > > patches, testcase mqueue: mq_perf_tests in kselftest failed with following > message. > > > > # selftests: mqueue: mq_perf_tests > > # > > # Initial system state: > > # Using queue path: /mq_perf_tests > > # RLIMIT_MSGQUEUE(soft): 819200 > > # RLIMIT_MSGQUEUE(hard): 819200 > > # Maximum Message Size: 8192 > > # Maximum Queue Size: 10 > > # Nice value: 0 > > # > > # Adjusted system state for testing: > > # RLIMIT_MSGQUEUE(soft): (unlimited) > > # RLIMIT_MSGQUEUE(hard): (unlimited) > > # Maximum Message Size: 16777216 > > # Maximum Queue Size: 65530 > > # Nice value: -20 > > # Continuous mode: (disabled) > > # CPUs to pin: 3 > > # ./mq_perf_tests: mq_open() at 296: Too many open files not ok 2 > > selftests: mqueue: mq_perf_tests # exit=1 ``` > > > > Test env: > > rootfs: debian-10 > > gcc version: 9 > > After investigation the problem turned out to be that ucount_max for the > rlimits in init_user_ns was being set to the initial rlimit value. > The practical problem is that ucount_max provides a limit that applications > inside the user namespace can not exceed. Which means in practice that > rlimits that have been converted to use the ucount infrastructure were not > able to exceend their initial rlimits. > > Solve this by setting the relevant values of ucount_max to RLIM_INIFINITY. A > limit in init_user_ns is pointless so the code should allow the values to grow > as large as possible without riscking an underflow or an overflow. > > As the ltp test case was a bit of a pain I have reproduced the rlimit failure and > tested the fix with the following little C program: > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > int main(int argc, char **argv) > > { > > struct mq_attr mq_attr; > > struct rlimit rlim; > > mqd_t mqd; > > int ret; > > > > ret = getrlimit(RLIMIT_MSGQUEUE, &rlim); > > if (ret != 0) { > > fprintf(stderr, "getrlimit(RLIMIT_MSGQUEUE) failed: %s\n", > strerror(errno)); > > exit(EXIT_FAILURE); > > } > > printf("RLIMIT_MSGQUEUE %lu %lu\n", > > rlim.rlim_cur, rlim.rlim_max); > > rlim.rlim_cur = RLIM_INFINITY; > > rlim.rlim_max = RLIM_INFINITY; > > ret = setrlimit(RLIMIT_MSGQUEUE, &rlim); > > if (ret != 0) { > > fprintf(stderr, "setrlimit(RLIMIT_MSGQUEUE, RLIM_INFINITY) > failed: %s\n", strerror(errno)); > > exit(EXIT_FAILURE); > > } > > > > memset(&mq_attr, 0, sizeof(struct mq_attr)); > > mq_attr.mq_maxmsg = 65536 - 1; > > mq_attr.mq_msgsize = 16*1024*1024 - 1; > > > > mqd = mq_open("/mq_rlimit_test", O_RDONLY|O_CREAT, 0600, > &mq_attr); > > if (mqd == (mqd_t)-1) { > > fprintf(stderr, "mq_open failed: %s\n", strerror(errno)); > > exit(EXIT_FAILURE); > > } > > ret = mq_close(mqd); > > if (ret) { > > fprintf(stderr, "mq_close failed; %s\n", strerror(errno)); > > exit(EXIT_FAILURE); > > } > > > > return EXIT_SUCCESS; > > } > > Fixes: 6e52a9f0532f ("Reimplement RLIMIT_MSGQUEUE on top of ucounts") > Fixes: d7c9e99aee48 ("Reimplement RLIMIT_MEMLOCK on top of ucounts") > Fixes: d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") > Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts") > Reported-by: kernel test robot lkp@intel.com Sorry, but <> around email address is needed Reported-by: kernel test robot > Acked-by: Alexey Gladkov > Signed-off-by: "Eric W. Biederman" > --- > > This is a simplified version of my previous change that I have tested and will > push out to linux-next and then to Linus shortly. > > kernel/fork.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/kernel/fork.c b/kernel/fork.c index bc94b2cc5995..44f4c2d83763 > 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -828,10 +828,10 @@ void __init fork_init(void) > for (i = 0; i < MAX_PER_NAMESPACE_UCOUNTS; i++) > init_user_ns.ucount_max[i] = max_threads/2; > > - set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_NPROC, > task_rlimit(&init_task, RLIMIT_NPROC)); > - set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MSGQUEUE, > task_rlimit(&init_task, RLIMIT_MSGQUEUE)); > - set_rlimit_ucount_max(&init_user_ns, > UCOUNT_RLIMIT_SIGPENDING, task_rlimit(&init_task, RLIMIT_SIGPENDING)); > - set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MEMLOCK, > task_rlimit(&init_task, RLIMIT_MEMLOCK)); > + set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_NPROC, > RLIM_INFINITY); > + set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MSGQUEUE, > RLIM_INFINITY); > + set_rlimit_ucount_max(&init_user_ns, > UCOUNT_RLIMIT_SIGPENDING, RLIM_INFINITY); > + set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MEMLOCK, > RLIM_INFINITY); > > #ifdef CONFIG_VMAP_STACK > cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, > "fork:vm_stack_cache", > -- > 2.20.1 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=-13.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 B3916C4338F for ; Tue, 24 Aug 2021 01:20:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4B69F613A7 for ; Tue, 24 Aug 2021 01:20:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4B69F613A7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B35756B006C; Mon, 23 Aug 2021 21:19:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE50D8D0001; Mon, 23 Aug 2021 21:19:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9AC7B6B0072; Mon, 23 Aug 2021 21:19:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id 7EC4C6B006C for ; Mon, 23 Aug 2021 21:19:59 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 32EEA8249980 for ; Tue, 24 Aug 2021 01:19:59 +0000 (UTC) X-FDA: 78508217718.20.4037569 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf12.hostedemail.com (Postfix) with ESMTP id 389D510000B9 for ; Tue, 24 Aug 2021 01:19:57 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10085"; a="196784775" X-IronPort-AV: E=Sophos;i="5.84,346,1620716400"; d="scan'208";a="196784775" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Aug 2021 18:19:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,346,1620716400"; d="scan'208";a="443630247" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga002.jf.intel.com with ESMTP; 23 Aug 2021 18:19:55 -0700 Received: from shsmsx602.ccr.corp.intel.com (10.109.6.142) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 18:19:54 -0700 Received: from shsmsx605.ccr.corp.intel.com (10.109.6.215) by SHSMSX602.ccr.corp.intel.com (10.109.6.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 24 Aug 2021 09:19:53 +0800 Received: from shsmsx605.ccr.corp.intel.com ([10.109.6.215]) by SHSMSX605.ccr.corp.intel.com ([10.109.6.215]) with mapi id 15.01.2242.010; Tue, 24 Aug 2021 09:19:53 +0800 From: "Ma, XinjianX" To: "Eric W. Biederman" , Alexey Gladkov CC: "linux-kselftest@vger.kernel.org" , lkp , "akpm@linux-foundation.org" , "axboe@kernel.dk" , "christian.brauner@ubuntu.com" , "containers@lists.linux-foundation.org" , "jannh@google.com" , "keescook@chromium.org" , "kernel-hardening@lists.openwall.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "oleg@redhat.com" , "torvalds@linux-foundation.org" Subject: RE: [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns Thread-Topic: [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns Thread-Index: AQHXmGLx+8SQcsWA7kykjkjhccpFyquB2fCQ Date: Tue, 24 Aug 2021 01:19:52 +0000 Message-ID: <06bb27f1d79243febf9ddc4633c4e084@intel.com> References: <87a6lgysxp.fsf@disp2133> <20210818131117.x7omzb2wkjq7le3s@example.org> <87o89ttqql.fsf@disp2133> <20210819172618.qwrrw4m7wt33wfmz@example.org> <87eeajswfc.fsf_-_@disp2133> In-Reply-To: <87eeajswfc.fsf_-_@disp2133> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.1.3 dlp-reaction: no-action x-originating-ip: [10.108.32.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Authentication-Results: imf12.hostedemail.com; dkim=none; spf=none (imf12.hostedemail.com: domain of xinjianx.ma@intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=xinjianx.ma@intel.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 389D510000B9 X-Stat-Signature: w83gde5ix1qurp943ja6zjrzohcgi7cx X-HE-Tag: 1629767997-821685 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: > -----Original Message----- > From: Eric W. Biederman > Sent: Tuesday, August 24, 2021 5:07 AM > To: Alexey Gladkov > Cc: Ma, XinjianX ; linux-kselftest@vger.kernel.org= ; > lkp ; akpm@linux-foundation.org; axboe@kernel.dk; > christian.brauner@ubuntu.com; containers@lists.linux-foundation.org; > jannh@google.com; keescook@chromium.org; kernel- > hardening@lists.openwall.com; linux-kernel@vger.kernel.org; linux- > mm@kvack.org; oleg@redhat.com; torvalds@linux-foundation.org > Subject: [PATCH] ucounts: Fix regression preventing increasing of rlimits= in > init_user_ns >=20 >=20 > "Ma, XinjianX" reported: >=20 > > When lkp team run kernel selftests, we found after these series of > > patches, testcase mqueue: mq_perf_tests in kselftest failed with follow= ing > message. > > > > # selftests: mqueue: mq_perf_tests > > # > > # Initial system state: > > # Using queue path: /mq_perf_tests > > # RLIMIT_MSGQUEUE(soft): 819200 > > # RLIMIT_MSGQUEUE(hard): 819200 > > # Maximum Message Size: 8192 > > # Maximum Queue Size: 10 > > # Nice value: 0 > > # > > # Adjusted system state for testing: > > # RLIMIT_MSGQUEUE(soft): (unlimited) > > # RLIMIT_MSGQUEUE(hard): (unlimited) > > # Maximum Message Size: 16777216 > > # Maximum Queue Size: 65530 > > # Nice value: -20 > > # Continuous mode: (disabled) > > # CPUs to pin: 3 > > # ./mq_perf_tests: mq_open() at 296: Too many open files not ok 2 > > selftests: mqueue: mq_perf_tests # exit=3D1 ``` > > > > Test env: > > rootfs: debian-10 > > gcc version: 9 >=20 > After investigation the problem turned out to be that ucount_max for the > rlimits in init_user_ns was being set to the initial rlimit value. > The practical problem is that ucount_max provides a limit that applicatio= ns > inside the user namespace can not exceed. Which means in practice that > rlimits that have been converted to use the ucount infrastructure were no= t > able to exceend their initial rlimits. >=20 > Solve this by setting the relevant values of ucount_max to RLIM_INIFINITY= . A > limit in init_user_ns is pointless so the code should allow the values to= grow > as large as possible without riscking an underflow or an overflow. >=20 > As the ltp test case was a bit of a pain I have reproduced the rlimit fai= lure and > tested the fix with the following little C program: > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > int main(int argc, char **argv) > > { > > struct mq_attr mq_attr; > > struct rlimit rlim; > > mqd_t mqd; > > int ret; > > > > ret =3D getrlimit(RLIMIT_MSGQUEUE, &rlim); > > if (ret !=3D 0) { > > fprintf(stderr, "getrlimit(RLIMIT_MSGQUEUE) failed: %s\n", > strerror(errno)); > > exit(EXIT_FAILURE); > > } > > printf("RLIMIT_MSGQUEUE %lu %lu\n", > > rlim.rlim_cur, rlim.rlim_max); > > rlim.rlim_cur =3D RLIM_INFINITY; > > rlim.rlim_max =3D RLIM_INFINITY; > > ret =3D setrlimit(RLIMIT_MSGQUEUE, &rlim); > > if (ret !=3D 0) { > > fprintf(stderr, "setrlimit(RLIMIT_MSGQUEUE, RLIM_INFINITY) > failed: %s\n", strerror(errno)); > > exit(EXIT_FAILURE); > > } > > > > memset(&mq_attr, 0, sizeof(struct mq_attr)); > > mq_attr.mq_maxmsg =3D 65536 - 1; > > mq_attr.mq_msgsize =3D 16*1024*1024 - 1; > > > > mqd =3D mq_open("/mq_rlimit_test", O_RDONLY|O_CREAT, 0600, > &mq_attr); > > if (mqd =3D=3D (mqd_t)-1) { > > fprintf(stderr, "mq_open failed: %s\n", strerror(errno)); > > exit(EXIT_FAILURE); > > } > > ret =3D mq_close(mqd); > > if (ret) { > > fprintf(stderr, "mq_close failed; %s\n", strerror(errno)); > > exit(EXIT_FAILURE); > > } > > > > return EXIT_SUCCESS; > > } >=20 > Fixes: 6e52a9f0532f ("Reimplement RLIMIT_MSGQUEUE on top of ucounts") > Fixes: d7c9e99aee48 ("Reimplement RLIMIT_MEMLOCK on top of ucounts") > Fixes: d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") > Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts") > Reported-by: kernel test robot lkp@intel.com Sorry, but <> around email address is needed=20 Reported-by: kernel test robot > Acked-by: Alexey Gladkov > Signed-off-by: "Eric W. Biederman" > --- >=20 > This is a simplified version of my previous change that I have tested and= will > push out to linux-next and then to Linus shortly. >=20 > kernel/fork.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) >=20 > diff --git a/kernel/fork.c b/kernel/fork.c index bc94b2cc5995..44f4c2d837= 63 > 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -828,10 +828,10 @@ void __init fork_init(void) > for (i =3D 0; i < MAX_PER_NAMESPACE_UCOUNTS; i++) > init_user_ns.ucount_max[i] =3D max_threads/2; >=20 > - set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_NPROC, > task_rlimit(&init_task, RLIMIT_NPROC)); > - set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MSGQUEUE, > task_rlimit(&init_task, RLIMIT_MSGQUEUE)); > - set_rlimit_ucount_max(&init_user_ns, > UCOUNT_RLIMIT_SIGPENDING, task_rlimit(&init_task, RLIMIT_SIGPENDING)); > - set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MEMLOCK, > task_rlimit(&init_task, RLIMIT_MEMLOCK)); > + set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_NPROC, > RLIM_INFINITY); > + set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MSGQUEUE, > RLIM_INFINITY); > + set_rlimit_ucount_max(&init_user_ns, > UCOUNT_RLIMIT_SIGPENDING, RLIM_INFINITY); > + set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MEMLOCK, > RLIM_INFINITY); >=20 > #ifdef CONFIG_VMAP_STACK > cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, > "fork:vm_stack_cache", > -- > 2.20.1