[LTP] [PATCH 0/3] lib/tst_pid: Find session PID limit more reliably
Teo Couprie Diaz
teo.coupriediaz@arm.com
Wed Feb 15 15:54:37 CET 2023
Hello LTP maintainers,
This patch series heavily reworks the logic to find the session PID limit,
which makes it work on a lot more cases than covered by the current paths.
This was motivated by failures I observed with msgstress03 and msgstress04
which weren't able to retrieve the correct PID limit on a minimal debian image
created with debootstrab.
I believe this could help with other failures I found online[0][1][2].
Indeed, the current paths used to find the session pids.max relies on systemd
to set up cgroups for the user sesssions.
This is not always the case: even if systemd is running, there might not be a
systemd user instance. cgroups might be enabled without the use of systemd, or
manually, which wouldn't match with the current paths. The process might be
controlled by another service's cgroup (for example, the sshd PID limits).
This is addressed by the first patch which uses the information in /proc/self/
to find both the cgroup sysfs mount point and the path to the active cgroup.
Further, currently when "max" is encountered in "pids.max" LTP assumes this
means the kernel "pid_max". This is fine if the cgroup is the only one
imposing a pid limit in its hierarchy, but is invalid if there's any parent
cgroup that restricts the PID count, "max" meaning this restricted value.
The second patch addresses this by going up the cgroup hierarchy until a limit
other than "max" is found, falling back to the kernel "pid_max" if it doesn't.
With our system this wasn't enough to fix the msgstress03 failures as it used
more PIDs than the limit it retrieved. Comparing it to msgstress04, msgstress03
is quite agressive in its PID limit and seems to assume tasks will complete
fast enough to not hit the limit.
Indeed, it will fork nprocs times, which is set to the pid limit if the later
is smaller, but then each forked process will fork again.
Fix that by pessimistically assuming that every fork will be alive at the same
time.
This series has been tested with cgroup v1 and v2, on Alpine Linux, Arch Linux
and Debian.
Thanks very much in advance for your time !
CI build:
https://github.com/Teo-CD/ltp/actions/runs/4184905549
[0]: https://lore.kernel.org/ltp/Yep6yovcY2qJkXSR@yuki/T/#t
[1]: https://forums.sifive.com/t/ltp-message-queue-stress-testcase-failure/4601
[2]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1783881
Teo Couprie Diaz (3):
lib/tst_pid: Find cgroup pid.max programmatically
lib/tst_pid: Go to parent cgroups for max value
ipc/msgstress03: Assume all forks will run concurently
lib/tst_pid.c | 133 ++++++++++++------
.../syscalls/ipc/msgstress/msgstress03.c | 2 +-
2 files changed, 90 insertions(+), 45 deletions(-)
--
2.25.1
More information about the ltp
mailing list