RFC: Proposed cgroup v2 and openat2 test case contributions for LTP

[priyama2]

Hi all,

Following recent discussions on the mailing list and suggestions to improve cgroup coverage in LTP, I reviewed the existing tests and kernel selftests and came up with a set of potential test cases that I believe could strengthen LTP's coverage.

Before I start implementing them, I would appreciate feedback from the community to avoid duplicating existing work and to understand which areas would be the most valuable to prioritize.

Candidate test cases
cgroup v2

• |cgroupv2_no_internal_process01| – Validate enforcement of the "no
  internal process" rule.

• |cgroupv2_controller_propagation01| – Verify controller propagation
  across nested hierarchies.

• |cgroup2_mem_psi01| – Validate memory PSI accounting within cgroups.

• |cgroup2_cpu_burst01| – Verify CPU burst quota behaviour.

• |cgroup2_delegation01| – Test delegation boundaries and permission
  enforcement.

• |cgroup2_io_cost01| – Validate I/O cost controller accounting.

PSI

• |psi_memory_pressure01|

• |psi_io_pressure01|

• |psi_cpu_pressure01|

cpuset

• |cpuset_partition_root01|

• |cpuset_partition_hotplug01|

openat2

• |openat2_symlink01| – Validate |RESOLVE_NO_SYMLINKS| behaviour and
  expected |ELOOP| handling.

Potential enhancements to existing coverage

I am also considering tests that complement existing functionality by focusing on edge cases and error handling, such as:

• Invalid |subtree_control| state transitions and rollback verification
• Threaded mode transition races
• Thread migration rule enforcement
• Hierarchical resource limit validation
• Invalid hierarchy operations and permission boundary checks
• NUMA policy and migration validation

My intention is to focus on deterministic error paths, corner cases, concurrency, and integration scenarios that may complement existing LTP tests and kernel selftests, rather than duplicating current coverage.

Could the maintainers and community please share:

1. Which of these ideas would be most valuable to implement first?

2. Whether any of these overlap with ongoing work or planned patches?

3. Whether there are other areas in cgroup v2 or related subsystems
   where additional LTP coverage would be more beneficial?

I'd be happy to refine the proposals based on the feedback before starting implementation.

Thanks in advance for your guidance.

Best regards,
Priya A

[schlad]

Thanks for opening this issue.

I agree that these are interesting areas. At the same time, cgroup coverage is
already fairly broad across kernel selftests, LTP, and some subsystem-specific
test suites.

For example, the kernel selftests under tools/testing/selftests/cgroup already
cover a lot of cgroup v2 core behaviour, including the no-internal-process
constraint, top-down controller constraints, threaded mode, invalid domains,
process/thread migration, and permission checks. There is also existing coverage
for cpu, cpuset, memory, pids, freezer, zswap, hugetlb/memcg, and cgroup.kill.

LTP also has existing controller coverage, including cgroup_core01-03,
memcontrol01-04, the older memcg/cpuset/freezer/cpu/pids suites, and
io_control01. Some of these are ports or complements of kernel selftests.

A few specific overlaps I noticed:

• openat2 RESOLVE_NO_SYMLINKS / ELOOP is already covered by LTP openat202.
• cpuset partition root state is covered extensively by the kernel selftest
  test_cpuset_prs.sh.
• cpuset hotplug is already covered by LTP cpuset_hotplug_test.sh.
• cgroup delegation / permission boundary checks are partly covered by cgroup
  selftests and by LTP cgroup_core01/cgroup_core02.
• cgroup io / throttling related behaviour is also covered in blktests, for
  example tests/throtl, including io.max and iocost coverage.

That does not mean new LTP tests would not be welcome. It just means that each
new test should identify a concrete gap in the existing coverage and explain why
it belongs in LTP rather than in kselftest or a subsystem-specific suite.

My suggestion would be to pick one small, deterministic case first, compare it
against the existing kselftest/LTP/blktests coverage, and send it as an RFC.
That will be much easier to review than trying to agree on a large test roadmap
up front.

In my opinion, possible candidates might be small PSI interface/trigger tests or
a narrowly scoped cpu.max.burst test, provided the expected behaviour can be made
stable enough for LTP. I would avoid tests that try to validate exact
PSI/accounting accuracy or broad race scenarios unless they can be made
deterministic.

My main message is: cgroup coverage is already quite good. Let's not try to
solve everything at once or lock in a roadmap months ahead. Instead, let's look
at what exists, identify a specific gap, and send a focused patch for that. Once
one thing is merged, the process itself will likely surface ideas for what to
improve next. Short cycles work better here than broad upfront planning.

I also plan to look at some of the existing controller tests over the summer and
gradually clean up or modernize pieces where it makes sense, for example some of
the older memctl code (like memctl_test01.c.). Long term, it would be good if new
or touched tests moved towards a more uniform style using the newer LTP C and
shell APIs. Help with that would be very welcome.

[priyama2]

Hi Sebastian,

Thank you for the detailed feedback and for pointing me to the existing coverage across kselftests, LTP, and blktests.

I completely agree that avoiding duplication is important. Based on the comments, I'll narrow the scope and focus on identifying a single deterministic gap rather than proposing a broad roadmap.

I'll review the existing coverage in more detail and prepare a focused RFC or patch in an area that genuinely complements the current test suites. I also noticed the suggestion about modernizing some of the older controller tests, and I'd be happy to help with that as well.

If there are other areas within LTP that you feel are currently under-tested or would benefit from additional contributors, I'd greatly appreciate any suggestions. I'm open to working on subsystems beyond cgroups if there are specific gaps or modernization efforts where help would be valuable.

Thanks again for the guidance. I look forward to contributing.

Best regards,
Priya A

[schlad]

I'm looking forward to reviewing your patches.
Thanks!

[priyama2]

Starting with the following testcases

Proposed   Test             | Purpose
----------------------------|------------------------------------------------------------
cpu_max_burst01             | Validate cpu.max.burst   semantics and boundary conditions
psi_trigger_interface01     | Verify PSI trigger registration, polling, and cleanup
psi_proc_format01           | Validate /proc/pressure/{cpu,memory,io} file format and parsing
psi_invalid_trigger01       | Verify invalid PSI trigger writes return the expected errors
psi_multiple_trigger01      | Exercise multiple PSI triggers on the same resource
cpu_max_burst_invalid01     | Validate invalid cpu.max.burst values and expected failures
memctl_test01 modernization | Convert older code to newer LTP APIs and improve maintainability
memctl_test02 modernization | Refactor and standardize existing controller tests
cgroup_core01 modernization | Adopt newer helper APIs and simplify code
cgroup_core02 modernization | Cleanup and API modernization
cgroup_core03 modernization | Refactor to current LTP style
memcontrol01-04 cleanup.    | Improve diagnostics and helper usage