controllers/cpuset: Make mount failure TCONF

It appears that if the subsystem is available under V2 then mounting
the V1 can fail. Probably when the V2 has processes assigned to a
group it controls.

The test should scan the system and find the existing CGroup
hierarchies and work with those. This can be done by converting the
test to tst_cgctl or rewriting it in C. It's not clear what the best
course of action would be.

For now, this commit just changes the result to TCONF.

Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
---
 testcases/kernel/controllers/cpuset/cpuset_funcs.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Hi Richie,

> It appears that if the subsystem is available under V2 then mounting
> the V1 can fail. Probably when the V2 has processes assigned to a
> group it controls.

Sounds likely, but it would be good to check this in the kernel code or with
kernel cgroup developers.

> The test should scan the system and find the existing CGroup
> hierarchies and work with those. This can be done by converting the
> test to tst_cgctl or rewriting it in C. It's not clear what the best
> course of action would be.

> For now, this commit just changes the result to TCONF.

+1 (suppose it's the case of already mounted under v2)

Reviewed-by: Petr Vorel <pvorel@suse.cz>

> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
> ---
>  testcases/kernel/controllers/cpuset/cpuset_funcs.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/testcases/kernel/controllers/cpuset/cpuset_funcs.sh b/testcases/kernel/controllers/cpuset/cpuset_funcs.sh
> index 0cfa0c17e..312654a9d 100755
> --- a/testcases/kernel/controllers/cpuset/cpuset_funcs.sh
> +++ b/testcases/kernel/controllers/cpuset/cpuset_funcs.sh
> @@ -165,7 +165,7 @@ setup()
>  	mount -t cgroup -o cpuset cpuset "$CPUSET" 2> /dev/null
>  	if [ $? -ne 0 ]; then
>  		cleanup
> -		tst_brkm TFAIL "Could not mount cgroup filesystem with"\
> +		tst_brkm TCONF "Could not mount cgroup filesystem with"\
>  					" cpuset on $CPUSET..Exiting test"

nit: I'd cleanup the message.

		tst_brkm TCONF "Could not mount cgroup filesystem with cpuset on $CPUSET"

Kind regards,
Petr

>  	fi

Hi!
> > It appears that if the subsystem is available under V2 then mounting
> > the V1 can fail. Probably when the V2 has processes assigned to a
> > group it controls.
> 
> Sounds likely, but it would be good to check this in the kernel code or with
> kernel cgroup developers.

I'm pretty sure that controller can be used either in v1, or in v2 but
not from both at the same time by choice. Some of the changes between v1
and v2 are incompatible so this couldn't work either way.

I think that once the controller name is written to
/sys/fs/cgroup/unified/cgroup.subtree_controll mounting it to v1 should
fail, so maybe we should just try to grep the fail instead and exit the
test with TCONF if we found the controller bound to v2 already.

> Hi!
> > > It appears that if the subsystem is available under V2 then mounting
> > > the V1 can fail. Probably when the V2 has processes assigned to a
> > > group it controls.

> > Sounds likely, but it would be good to check this in the kernel code or with
> > kernel cgroup developers.

> I'm pretty sure that controller can be used either in v1, or in v2 but
> not from both at the same time by choice. Some of the changes between v1
> and v2 are incompatible so this couldn't work either way.

> I think that once the controller name is written to
> /sys/fs/cgroup/unified/cgroup.subtree_controll mounting it to v1 should
> fail, so maybe we should just try to grep the fail instead and exit the
> test with TCONF if we found the controller bound to v2 already.

Sounds like a good idea.

Kind regards,
Petr

Hello,

Petr Vorel <pvorel@suse.cz> writes:

>> Hi!
>> > > It appears that if the subsystem is available under V2 then mounting
>> > > the V1 can fail. Probably when the V2 has processes assigned to a
>> > > group it controls.
>
>> > Sounds likely, but it would be good to check this in the kernel code or with
>> > kernel cgroup developers.
>
>> I'm pretty sure that controller can be used either in v1, or in v2 but
>> not from both at the same time by choice. Some of the changes between v1
>> and v2 are incompatible so this couldn't work either way.
>
>> I think that once the controller name is written to
>> /sys/fs/cgroup/unified/cgroup.subtree_controll mounting it to v1 should
>> fail, so maybe we should just try to grep the fail instead and exit the
>> test with TCONF if we found the controller bound to v2 already.
>
> Sounds like a good idea.

I tried a quick experiment. Adding it to cgroup.subtree_control is not
enough. However adding a process to a cgroup where the controller is
enabled causes mount to fail with EBUSY. There could be other ways. I
would assume that sort of thing can change as well between kernel versions.

If we want to avoid attempting the mount then maybe even just scanning
cgroup.controllers is best. This is practically what we do in tst_cgroup
lib. However there is also just the option of not running the test on
systems where only V2 will be used. So this is just a minimal fix to
keep the test limping along until they are obsolete or rewritten
entirely.

Another option would be to split the tests into V1 only and everything
else. That would work for us if distros are practically stopping support for
V1 on newer versions. Then there is no need to make these tests detect
V2, we just don't run them on those systems.