On Wed, Dec 21, 2022 at 05:06:06PM +0000, Teo Couprie Diaz wrote:
On 21/12/2022 16:39, Beata Michalska wrote:
On Wed, Dec 21, 2022 at 10:40:57AM +0000, Teo Couprie Diaz wrote:
On 21/12/2022 10:22, Kevin Brodsky wrote:
On 21/12/2022 10:59, Teo Couprie Diaz wrote:
> +#define CGROUPS_V2_INIT_SCOPE > "/sys/fs/cgroup/pids/init.scope/pids.max" On Arch I don't get pids/ under cgroup/, what I have is init.scope/ directly underneath, that is:
/sys/fs/cgroup/init.scope/pids.max
Not sure if that's a configuration difference? In any case the idea sounds sensible.
Interesting, thanks for pointing it out. I do have the same on my personal Arch machine, but on my Ubuntu laptop I have the same as in our Debian image. Looking at the defines with a bit more attention, it seems like it could be a cgroups v1/v2 difference. The path I added looking like a v1 thing (similar to CGRUPS_V1_SLICE_FMT), rather than a v2.
I'll try to have a look and see if I can get our image to use cgroups v2.
Would it make sense to add two paths if I don't find another solution, to cover all of our bases ?
Right I see, in that case it would make sense to have both the v1 and v2 paths, especially since the test already handles both for the user slice.
Agreed, I reached the same conclusion digging a bit deeper. I can confirm this is indeed a v1/v2 difference, so it makes sense to go that way.
Kevin
Téo
Out of curiosity: what if the LTP itself will be running under cgroup with higher restrictions that 'root' cgroup ? Wouldn't all the tests fail ?
They probably would, yes. I feel that the way it is retrieved is kind of hacky and not very reliable, as indeed it could be in a different cgroup, or not under a user slice...
Shouldn't we try to find out under which cgroup the test process is being controlled ?
Ideally yes absolutely. I have tried looking for something for a bit, but couldn't find anything readily available with systemd. I could (and probably should) delve a bit deeper. Maybe use a syscall directly to get the information (I've been working on getrlimit in parallel, it looks like it could be useful ?) would be more reliable ?
I'm afraid that rlimit and cgroup pids limit might be actually considered separately (reasoning based on having a quick look at copy_process and pids controller's callback can_fork -> pids_can_fork). Furthermore: RLIMIT_NPROC, pid_max and cgroup's pid.max seem to actually define separate limits, LTP seems to be ignoring rlimit (or maybe I have missed that one). I'll try to help in finding a way to consider all three, and to preferably not to rely of fixed path fr the proc.max limits.
Anyway, I'll abstain from sending a v2 for now as the file I suggest using in this patch is now not there anymore on my test system ! Don't really know how or why, but it surely highlights how fragile this solution is...
It is worrying indeed.
FWIW: this is a long game but it would be nicer to have some kind of a parser rather then hardcoding paths. (simple 'ls -l /sys/fs/cgroup/*/*/pids.max' gives the pids.max for top of the hierarchy)
I did have this thought while adding the v1/v2 paths : it would be quite a nice thing to have !
Thanks for the comments Beata,
Téo
BR B.
linux-morello-ltp mailing list -- linux-morello-ltp@op-lists.linaro.org To unsubscribe send an email to linux-morello-ltp-leave@op-lists.linaro.org
linux-morello-ltp mailing list -- linux-morello-ltp@op-lists.linaro.org To unsubscribe send an email to linux-morello-ltp-leave@op-lists.linaro.org