casaroli opened a new pull request, #20784: URL: https://github.com/apache/nuttx/pull/20784
## Summary `setrlimit()` kept nothing and returned OK, and `getrlimit()` returned fixed values. So a limit that a program or a shell set (for example `ulimit -s` in bash) had no effect. This PR keeps the resource limits per process, in the task group, and enforces two of them: 1. `getrlimit()` and `setrlimit()` become system calls that read and write the limits of the task group, so a process cannot change them through its own memory. A new process gets the limits of its parent. `setrlimit()` fails with `EINVAL` for a resource that NuttX does not enforce (it returned OK before) and with `EPERM` when an unprivileged process raises a hard limit. `getrlimit()` reports the other resources as `RLIM_INFINITY`. `sysconf(_SC_OPEN_MAX)` returns the `RLIMIT_NOFILE` soft limit, as POSIX says. 2. `RLIMIT_NOFILE`: a new file descriptor must be below the soft limit: `open()`, `dup()` and `fcntl(F_DUPFD)` fail with `EMFILE`, `dup2()` and `dup3()` with `EBADF`. The default and the largest value is `OPEN_MAX`. 3. `RLIMIT_STACK`: when the soft limit is set, it is the default stack size of a new thread (`pthread_attr_init()` and `pthread_create()` without attributes) and the stack size of a new ELF program that does not set `nx_stacksize`, as on Linux. The value is kept between `PTHREAD_STACK_MIN` and the largest stack that a task can have (`TLS_MAXSTACK` with `CONFIG_TLS_ALIGNED`). By default there is no limit and nothing changes. 4. The task control reference describes the limits, `getrlimit()` and `setrlimit()`. ## Impact - Without a limit, stack sizes and the number of open files do not change. - `setrlimit()` now fails with `EINVAL` for `RLIMIT_CORE`, `RLIMIT_CPU`, `RLIMIT_DATA`, `RLIMIT_FSIZE`, `RLIMIT_AS`, `RLIMIT_MEMLOCK`, `RLIMIT_NICE`, `RLIMIT_RTPRIO` and `RLIMIT_RTTIME`, which it accepted and ignored before. So does `ulimit(UL_SETFSIZE)`. - `getrlimit(RLIMIT_STACK)` reports `RLIM_INFINITY` by default instead of `CONFIG_PTHREAD_STACK_DEFAULT`. - Two new system calls (`getrlimit`, `setrlimit`); the libc versions are removed. ## Testing A test program on `qemu-armv8a:knsh` (QEMU 11 with HVF on an Apple M4), with `CONFIG_TLS_LOG2_MAXSTACK=18`, 17 checks, all pass: - defaults: `RLIMIT_STACK` unlimited, `RLIMIT_NOFILE` = `OPEN_MAX` = `sysconf(_SC_OPEN_MAX)`; `RLIMIT_CORE` reported unlimited; `setrlimit(RLIMIT_CORE)`, `getrlimit(999)` and a soft limit above the hard limit give `EINVAL`; - `RLIMIT_STACK` = 64 KiB: `pthread_attr_init()` gives 65536; a thread without attributes has a 65488-byte stack; a child started with `posix_spawn()` reports the limit 65536 and a 65440-byte main stack; - `RLIMIT_NOFILE` = 8: `sysconf(_SC_OPEN_MAX)` returns 8; `open()` stops at descriptor 7 with `EMFILE`; `dup2(0, 8)` gives `EBADF`; the soft limit goes back up to the hard limit; a hard limit above `OPEN_MAX` gives `EPERM`. With the default `CONFIG_TLS_LOG2_MAXSTACK=13` the stacks are kept at 8 KiB, the largest stack of that configuration. `ostest` on `qemu-armv8a:knsh` and `qemu-armv8a:nsh` ends with `ostest_main: Exiting with status 0`. Each commit builds `qemu-armv8a:knsh`; the CMake build of `qemu-armv8a:nsh` has no compiler warning. `tools/checkpatch.sh -c -u -m -g` passes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
