* Re: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts @ 2021-08-17 4:03 Ma, XinjianX 2021-08-17 15:47 ` Eric W. Biederman 0 siblings, 1 reply; 9+ messages in thread From: Ma, XinjianX @ 2021-08-17 4:03 UTC (permalink / raw) To: legion, linux-kselftest Cc: lkp, linux-kselftest, akpm, axboe, christian.brauner, containers, ebiederm, jannh, keescook, kernel-hardening, linux-kernel, linux-mm, oleg, torvalds Hi Alexey, When lkp team run kernel selftests, we found after these series of patches, testcase mqueue: mq_perf_tests in kselftest failed with following message. If you confirm and fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot lkp@intel.com ``` # 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 ------ Thanks Ma Xinjian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts 2021-08-17 4:03 [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts Ma, XinjianX @ 2021-08-17 15:47 ` Eric W. Biederman 2021-08-18 13:11 ` Alexey Gladkov 0 siblings, 1 reply; 9+ messages in thread From: Eric W. Biederman @ 2021-08-17 15:47 UTC (permalink / raw) To: Ma, XinjianX Cc: legion, linux-kselftest, lkp, akpm, axboe, christian.brauner, containers, jannh, keescook, kernel-hardening, linux-kernel, linux-mm, oleg, torvalds "Ma, XinjianX" <xinjianx.ma@intel.com> writes: > Hi Alexey, > > When lkp team run kernel selftests, we found after these series of patches, testcase mqueue: mq_perf_tests > in kselftest failed with following message. Which kernel was this run against? Where can the mq_perf_tests that you ran and had problems with be found? During your run were you using user namespaces as part of your test environment? The error message too many files corresponds to the error code EMFILES which is the error code that is returned when the rlimit is reached. One possibility is that your test environment was run in a user namespace and so you wound up limited by rlimit of the user who created the user namespace at the point of user namespace creation. At this point if you can give us enough information to look into this and attempt to reproduce it that would be appreciated. > If you confirm and fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot lkp@intel.com > > ``` > # 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 > > ------ > Thanks > Ma Xinjian Eric ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts 2021-08-17 15:47 ` Eric W. Biederman @ 2021-08-18 13:11 ` Alexey Gladkov 2021-08-19 1:50 ` Ma, XinjianX 2021-08-19 15:10 ` Eric W. Biederman 0 siblings, 2 replies; 9+ messages in thread From: Alexey Gladkov @ 2021-08-18 13:11 UTC (permalink / raw) To: Eric W. Biederman Cc: Ma, XinjianX, linux-kselftest, lkp, akpm, axboe, christian.brauner, containers, jannh, keescook, kernel-hardening, linux-kernel, linux-mm, oleg, torvalds On Tue, Aug 17, 2021 at 10:47:14AM -0500, Eric W. Biederman wrote: > "Ma, XinjianX" <xinjianx.ma@intel.com> writes: > > > Hi Alexey, > > > > When lkp team run kernel selftests, we found after these series of patches, testcase mqueue: mq_perf_tests > > in kselftest failed with following message. > > Which kernel was this run against? > > Where can the mq_perf_tests that you ran and had problems with be found? > > During your run were you using user namespaces as part of your test > environment? > > The error message too many files corresponds to the error code EMFILES > which is the error code that is returned when the rlimit is reached. > > One possibility is that your test environment was run in a user > namespace and so you wound up limited by rlimit of the user who created > the user namespace at the point of user namespace creation. > > At this point if you can give us enough information to look into this > and attempt to reproduce it that would be appreciated. I was able to reproduce it on master without using user namespace. I suspect that the maximum value is not assigned here [1]: set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MSGQUEUE, task_rlimit(&init_task, RLIMIT_MSGQUEUE)); [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/fork.c#n832 > > If you confirm and fix the issue, kindly add following tag as appropriate > > Reported-by: kernel test robot lkp@intel.com > > > > ``` > > # 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 > > > > ------ > > Thanks > > Ma Xinjian > > Eric > -- Rgrds, legion ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts 2021-08-18 13:11 ` Alexey Gladkov @ 2021-08-19 1:50 ` Ma, XinjianX 2021-08-19 15:10 ` Eric W. Biederman 1 sibling, 0 replies; 9+ messages in thread From: Ma, XinjianX @ 2021-08-19 1:50 UTC (permalink / raw) To: Alexey Gladkov, Eric W. Biederman Cc: linux-kselftest, lkp, akpm, axboe, christian.brauner, containers, jannh, keescook, kernel-hardening, linux-kernel, linux-mm, oleg, torvalds > -----Original Message----- > From: Alexey Gladkov <legion@kernel.org> > Sent: Wednesday, August 18, 2021 9:11 PM > To: Eric W. Biederman <ebiederm@xmission.com> > Cc: Ma, XinjianX <xinjianx.ma@intel.com>; linux-kselftest@vger.kernel.org; > lkp <lkp@intel.com>; 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 v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of > ucounts > > On Tue, Aug 17, 2021 at 10:47:14AM -0500, Eric W. Biederman wrote: > > "Ma, XinjianX" <xinjianx.ma@intel.com> writes: > > > > > Hi Alexey, > > > > > > When lkp team run kernel selftests, we found after these series of > > > patches, testcase mqueue: mq_perf_tests in kselftest failed with > following message. > > > > Which kernel was this run against? > > > > Where can the mq_perf_tests that you ran and had problems with be > found? > > > > During your run were you using user namespaces as part of your test > > environment? > > > > The error message too many files corresponds to the error code EMFILES > > which is the error code that is returned when the rlimit is reached. > > > > One possibility is that your test environment was run in a user > > namespace and so you wound up limited by rlimit of the user who > > created the user namespace at the point of user namespace creation. > > > > At this point if you can give us enough information to look into this > > and attempt to reproduce it that would be appreciated. > > I was able to reproduce it on master without using user namespace. > I suspect that the maximum value is not assigned here [1]: > > set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MSGQUEUE, > task_rlimit(&init_task, RLIMIT_MSGQUEUE)); > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kerne > l/fork.c#n832 Thank you for confirming the issue. And will you plan to fix this issue? If it's your plan, kindly add following tag as appropriate Reported-by: kernel test robot <xinjianx.ma@intel.com> > > > > If you confirm and fix the issue, kindly add following tag as > > > appropriate > > > Reported-by: kernel test robot lkp@intel.com > > > > > > ``` > > > # 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 > > > > > > ------ > > > Thanks > > > Ma Xinjian > > > > Eric > > > > -- > Rgrds, legion ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts 2021-08-18 13:11 ` Alexey Gladkov 2021-08-19 1:50 ` Ma, XinjianX @ 2021-08-19 15:10 ` Eric W. Biederman 2021-08-19 17:26 ` Alexey Gladkov 1 sibling, 1 reply; 9+ messages in thread From: Eric W. Biederman @ 2021-08-19 15:10 UTC (permalink / raw) To: Alexey Gladkov Cc: Ma, XinjianX, linux-kselftest, lkp, akpm, axboe, christian.brauner, containers, jannh, keescook, kernel-hardening, linux-kernel, linux-mm, oleg, torvalds Alexey Gladkov <legion@kernel.org> writes: > On Tue, Aug 17, 2021 at 10:47:14AM -0500, Eric W. Biederman wrote: >> "Ma, XinjianX" <xinjianx.ma@intel.com> writes: >> >> > Hi Alexey, >> > >> > When lkp team run kernel selftests, we found after these series of patches, testcase mqueue: mq_perf_tests >> > in kselftest failed with following message. >> >> Which kernel was this run against? >> >> Where can the mq_perf_tests that you ran and had problems with be found? >> >> During your run were you using user namespaces as part of your test >> environment? >> >> The error message too many files corresponds to the error code EMFILES >> which is the error code that is returned when the rlimit is reached. >> >> One possibility is that your test environment was run in a user >> namespace and so you wound up limited by rlimit of the user who created >> the user namespace at the point of user namespace creation. >> >> At this point if you can give us enough information to look into this >> and attempt to reproduce it that would be appreciated. > > I was able to reproduce it on master without using user namespace. > I suspect that the maximum value is not assigned here [1]: > > set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MSGQUEUE, task_rlimit(&init_task, RLIMIT_MSGQUEUE)); > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/fork.c#n832 The rlimits for init_task are set to INIT_RLIMITS. In INIT_RLIMITS RLIMIT_MSGQUEUE is set to MQ_MAX_BYTES So that definitely means that as the code is current constructed the rlimit can not be effectively raised. So it looks like we are just silly and preventing the initial rlimits from being raised. So we probably want to do something like: diff --git a/kernel/fork.c b/kernel/fork.c index bc94b2cc5995..557ce0083ba3 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -825,13 +825,13 @@ void __init fork_init(void) init_task.signal->rlim[RLIMIT_SIGPENDING] = init_task.signal->rlim[RLIMIT_NPROC]; + /* For non-rlimit ucounts make their default limit max_threads/2 */ 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)); + /* In init_user_ns default rlimit to be the only limit */ + for (; i < UCOUNT_COUNTS; i++) + set_rlimit_ucount_max(&init_user_ns, i, RLIMIT_INFINITY); #ifdef CONFIG_VMAP_STACK cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "fork:vm_stack_cache", Eric ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts 2021-08-19 15:10 ` Eric W. Biederman @ 2021-08-19 17:26 ` Alexey Gladkov 2021-08-23 21:06 ` [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns Eric W. Biederman 0 siblings, 1 reply; 9+ messages in thread From: Alexey Gladkov @ 2021-08-19 17:26 UTC (permalink / raw) To: Eric W. Biederman Cc: Ma, XinjianX, linux-kselftest, lkp, akpm, axboe, christian.brauner, containers, jannh, keescook, kernel-hardening, linux-kernel, linux-mm, oleg, torvalds On Thu, Aug 19, 2021 at 10:10:26AM -0500, Eric W. Biederman wrote: > Alexey Gladkov <legion@kernel.org> writes: > > > On Tue, Aug 17, 2021 at 10:47:14AM -0500, Eric W. Biederman wrote: > >> "Ma, XinjianX" <xinjianx.ma@intel.com> writes: > >> > >> > Hi Alexey, > >> > > >> > When lkp team run kernel selftests, we found after these series of patches, testcase mqueue: mq_perf_tests > >> > in kselftest failed with following message. > >> > >> Which kernel was this run against? > >> > >> Where can the mq_perf_tests that you ran and had problems with be found? > >> > >> During your run were you using user namespaces as part of your test > >> environment? > >> > >> The error message too many files corresponds to the error code EMFILES > >> which is the error code that is returned when the rlimit is reached. > >> > >> One possibility is that your test environment was run in a user > >> namespace and so you wound up limited by rlimit of the user who created > >> the user namespace at the point of user namespace creation. > >> > >> At this point if you can give us enough information to look into this > >> and attempt to reproduce it that would be appreciated. > > > > I was able to reproduce it on master without using user namespace. > > I suspect that the maximum value is not assigned here [1]: > > > > set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MSGQUEUE, task_rlimit(&init_task, RLIMIT_MSGQUEUE)); > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/fork.c#n832 > > The rlimits for init_task are set to INIT_RLIMITS. > In INIT_RLIMITS RLIMIT_MSGQUEUE is set to MQ_MAX_BYTES > > So that definitely means that as the code is current constructed the > rlimit can not be effectively raised. > > So it looks like we are just silly and preventing the initial rlimits > from being raised. > > So we probably want to do something like: Damn, you are faster than me! :) > diff --git a/kernel/fork.c b/kernel/fork.c > index bc94b2cc5995..557ce0083ba3 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -825,13 +825,13 @@ void __init fork_init(void) > init_task.signal->rlim[RLIMIT_SIGPENDING] = > init_task.signal->rlim[RLIMIT_NPROC]; > > + /* For non-rlimit ucounts make their default limit max_threads/2 */ > 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)); > + /* In init_user_ns default rlimit to be the only limit */ > + for (; i < UCOUNT_COUNTS; i++) > + set_rlimit_ucount_max(&init_user_ns, i, RLIMIT_INFINITY); s/RLIMIT_INFINITY/RLIM_INFINITY/ > > #ifdef CONFIG_VMAP_STACK > cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "fork:vm_stack_cache", > Acked-by: Alexey Gladkov <legion@kernel.org> I cannot complete this test on my laptop. On 4Gb, the test ends with oom-killer. But with this patch, the test definitely passes the moment of the previous fall. -- Rgrds, legion ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns 2021-08-19 17:26 ` Alexey Gladkov @ 2021-08-23 21:06 ` Eric W. Biederman 2021-08-24 1:19 ` Ma, XinjianX 0 siblings, 1 reply; 9+ messages in thread From: Eric W. Biederman @ 2021-08-23 21:06 UTC (permalink / raw) To: Alexey Gladkov Cc: Ma, XinjianX, linux-kselftest, lkp, akpm, axboe, christian.brauner, containers, jannh, keescook, kernel-hardening, linux-kernel, linux-mm, oleg, torvalds "Ma, XinjianX" <xinjianx.ma@intel.com> 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 <stdio.h> > #include <fcntl.h> > #include <sys/stat.h> > #include <mqueue.h> > #include <sys/time.h> > #include <sys/resource.h> > #include <errno.h> > #include <string.h> > #include <stdlib.h> > #include <limits.h> > #include <unistd.h> > > 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 Acked-by: Alexey Gladkov <legion@kernel.org> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> --- 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* RE: [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns 2021-08-23 21:06 ` [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns Eric W. Biederman @ 2021-08-24 1:19 ` Ma, XinjianX 2021-08-24 3:24 ` Eric W. Biederman 0 siblings, 1 reply; 9+ messages in thread From: Ma, XinjianX @ 2021-08-24 1:19 UTC (permalink / raw) To: Eric W. Biederman, Alexey Gladkov Cc: linux-kselftest, lkp, akpm, axboe, christian.brauner, containers, jannh, keescook, kernel-hardening, linux-kernel, linux-mm, oleg, torvalds > -----Original Message----- > From: Eric W. Biederman <ebiederm@xmission.com> > Sent: Tuesday, August 24, 2021 5:07 AM > To: Alexey Gladkov <legion@kernel.org> > Cc: Ma, XinjianX <xinjianx.ma@intel.com>; linux-kselftest@vger.kernel.org; > lkp <lkp@intel.com>; 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" <xinjianx.ma@intel.com> 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 <stdio.h> > > #include <fcntl.h> > > #include <sys/stat.h> > > #include <mqueue.h> > > #include <sys/time.h> > > #include <sys/resource.h> > > #include <errno.h> > > #include <string.h> > > #include <stdlib.h> > > #include <limits.h> > > #include <unistd.h> > > > > 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 <lkp@intel.com> > Acked-by: Alexey Gladkov <legion@kernel.org> > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > --- > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns 2021-08-24 1:19 ` Ma, XinjianX @ 2021-08-24 3:24 ` Eric W. Biederman 0 siblings, 0 replies; 9+ messages in thread From: Eric W. Biederman @ 2021-08-24 3:24 UTC (permalink / raw) To: Ma, XinjianX Cc: Alexey Gladkov, linux-kselftest, lkp, akpm, axboe, christian.brauner, containers, jannh, keescook, kernel-hardening, linux-kernel, linux-mm, oleg, torvalds "Ma, XinjianX" <xinjianx.ma@intel.com> writes: >> -----Original Message----- >> From: Eric W. Biederman <ebiederm@xmission.com> >> ... >> Reported-by: kernel test robot lkp@intel.com > Sorry, but <> around email address is needed > Reported-by: kernel test robot <lkp@intel.com> The change is already tested and pushed out so I really don't want to mess with it. Especially as I am aiming to send it to Linus on Wednesday after it has had a chance to pass through linux-next and whatever automated tests are there. What does copying and pasting the Reported-by: tag as included in your original report cause to break? At this point I suspect that the danger of fat fingering something far outweighs whatever benefits might be gained by surrounding the email address with <> marks. Eric ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-08-24 3:25 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-17 4:03 [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts Ma, XinjianX 2021-08-17 15:47 ` Eric W. Biederman 2021-08-18 13:11 ` Alexey Gladkov 2021-08-19 1:50 ` Ma, XinjianX 2021-08-19 15:10 ` Eric W. Biederman 2021-08-19 17:26 ` Alexey Gladkov 2021-08-23 21:06 ` [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns Eric W. Biederman 2021-08-24 1:19 ` Ma, XinjianX 2021-08-24 3:24 ` Eric W. Biederman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).