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

[LTP] 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,
Priyama



-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Andrea Cervesato via ltp]

Hi Priyama,

the cgroup testing suite in LTP can be a bit unstable due to the nature
of cgroup v1 -> v2 migration. The V2 seems stable, but sometimes tests
might produce false positives, mostly related to system configurations
or system overload. We digged quite a lot into it in the past years and
we ended up with a solution which "good enough" for regression testing,
supporting both v1 and v2.

Also, kselftests already cover many cgroup testing scenarios and we are
not actively investing time on it. But you and others are welcome to try
implementing something, if you think this can be helpful.

My biggest concern is the code quality. cgroups can be a complex beast
to handle with LTP API, which are made supporting v1 and v2.

If you are willing to implement new tests, please consider test cases
scenarios that are not implemented in LTP and kselftests. Those are the
most valuable at the moment.

Regards,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Sebastian Chlad]

On Thu, 18 Jun 2026 at 13:35, Andrea Cervesato via ltp <ltp@lists.linux.it>
wrote:

> Hi Priyama,
>
> the cgroup testing suite in LTP can be a bit unstable due to the nature
> of cgroup v1 -> v2 migration. The V2 seems stable, but sometimes tests
> might produce false positives, mostly related to system configurations
> or system overload. We digged quite a lot into it in the past years and
> we ended up with a solution which "good enough" for regression testing,
> supporting both v1 and v2.
>
> Also, kselftests already cover many cgroup testing scenarios and we are
> not actively investing time on it.


I’m fully with Andrea here. There is already good and extensive cgroup test
coverage in kselftests, and this is also complemented by LTP tests that
exercise cgroups, so we are not in a bad position.

There are also good related tests in blktests, for example the blk-throttle
tests:
https://github.com/linux-blktests/blktests/tree/master/tests/throtl

Anyway, since you opened this issue:
https://github.com/linux-test-project/ltp/issues/1328

let’s continue the conversation there. I’m going to comment there shortly.


> But you and others are welcome to try
> implementing something, if you think this can be helpful.
>
> My biggest concern is the code quality. cgroups can be a complex beast
> to handle with LTP API, which are made supporting v1 and v2.
>
> If you are willing to implement new tests, please consider test cases
> scenarios that are not implemented in LTP and kselftests. Those are the
> most valuable at the moment.
>
> Regards,
> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp