The sched tests are missing a target entry and hence out-of-tree build support.
For instance: make -C tools/testing/selftests install INSTALL_LOCATION=/foo/bar
is expected to build the sched tests and place them at /foo/bar. But this is not observed since a TARGET entry is not present for sched.
This was suggested by Shuah in this conversation Link: https://lore.kernel.org/linux-kselftest/60dd0240-8e45-4958-acf2-7eeee917785b...
Add support for sched selftests by adding sched as a default TARGET
Signed-off-by: Sinadin Shan sinadin.shan@oracle.com --- tools/testing/selftests/Makefile | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile index 8daac70c2f9d2..e2d0d389ad912 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -91,6 +91,7 @@ TARGETS += rlimits TARGETS += rseq TARGETS += rtc TARGETS += rust +TARGETS += sched TARGETS += sched_ext TARGETS += seccomp TARGETS += sgx
From: Sinadin Shan sinadin.shan@oracle.com Sent: Wednesday, February 19, 2025 1:46 AM To: shuah@kernel.org Cc: linux-kselftest@vger.kernel.org; linux-kernel@vger.kernel.org; Chris Hyser; Sinadin Shan Subject: [PATCH] selftests: sched: add sched as a default selftest target
The sched tests are missing a target entry and hence out-of-tree build support.
For instance: make -C tools/testing/selftests install INSTALL_LOCATION=/foo/bar
is expected to build the sched tests and place them at /foo/bar. But this is not observed since a TARGET entry is not present for sched.
This was suggested by Shuah in this conversation Link: https://lore.kernel.org/linux-kselftest/60dd0240-8e45-4958-acf2-7eeee917785b...
Add support for sched selftests by adding sched as a default TARGET
Signed-off-by: Sinadin Shan sinadin.shan@oracle.com
Reviewed-by: Chris Hyser chris.hyser@oracle.com
On 2/19/25 12:16, Sinadin Shan wrote:
The sched tests are missing a target entry and hence out-of-tree build support.
For instance: make -C tools/testing/selftests install INSTALL_LOCATION=/foo/bar
is expected to build the sched tests and place them at /foo/bar. But this is not observed since a TARGET entry is not present for sched.
This was suggested by Shuah in this conversation Link: https://lore.kernel.org/linux-kselftest/60dd0240-8e45-4958-acf2-7eeee917785b...
Add support for sched selftests by adding sched as a default TARGET
Signed-off-by: Sinadin Shan sinadin.shan@oracle.com
tools/testing/selftests/Makefile | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile index 8daac70c2f9d2..e2d0d389ad912 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -91,6 +91,7 @@ TARGETS += rlimits TARGETS += rseq TARGETS += rtc TARGETS += rust +TARGETS += sched TARGETS += sched_ext TARGETS += seccomp TARGETS += sgx
There is only one test currently in sched: i.e cs_prctl_test.c. to see the cookies validation when core scheduling is in effect.
If CONFIG_SCHED_CORE=n, the test fails. So you might end up seeing default selftests failing on such systems? or this is only compiling?
Likely the selftests/sched needs to modified for CONFIG_SCHED_CORE=n
When CONFIG_SCHED_CORE=n ./cs_prctl_test
## Create a thread/process/process group hierarchy Not a core sched system ... Not a core sched system (283) FAILED: get_cs_cookie(0) == 0
On 20-02-2025 01:15 pm, Shrikanth Hegde wrote:
On 2/19/25 12:16, Sinadin Shan wrote:
The sched tests are missing a target entry and hence out-of-tree build support.
For instance: make -C tools/testing/selftests install INSTALL_LOCATION=/foo/bar
is expected to build the sched tests and place them at /foo/bar. But this is not observed since a TARGET entry is not present for sched.
This was suggested by Shuah in this conversation Link: https://lore.kernel.org/linux-kselftest/60dd0240-8e45-4958- acf2-7eeee917785b@linuxfoundation.org/
Add support for sched selftests by adding sched as a default TARGET
Signed-off-by: Sinadin Shan sinadin.shan@oracle.com
tools/testing/selftests/Makefile | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/ selftests/Makefile index 8daac70c2f9d2..e2d0d389ad912 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -91,6 +91,7 @@ TARGETS += rlimits TARGETS += rseq TARGETS += rtc TARGETS += rust +TARGETS += sched TARGETS += sched_ext TARGETS += seccomp TARGETS += sgx
There is only one test currently in sched: i.e cs_prctl_test.c. to see the cookies validation when core scheduling is in effect.
If CONFIG_SCHED_CORE=n, the test fails. So you might end up seeing default selftests failing on such systems? or this is only compiling?>
Yes, this patch would enable the test to be compiled and run by default.
Likely the selftests/sched needs to modified for CONFIG_SCHED_CORE=n
Agree. Chris, I suppose then a graceful skip would be a more right option for kernels with core scheduling disabled?
Regards, Shan
When CONFIG_SCHED_CORE=n ./cs_prctl_test
## Create a thread/process/process group hierarchy Not a core sched system ... Not a core sched system (283) FAILED: get_cs_cookie(0) == 0
From: Sinadin Shan sinadin.shan@oracle.com Sent: Thursday, February 20, 2025 9:52 AM To: Shrikanth Hegde; Chris Hyser Cc: linux-kselftest@vger.kernel.org; linux-kernel@vger.kernel.org; shuah@kernel.org Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
On 20-02-2025 01:15 pm, Shrikanth Hegde wrote:
If CONFIG_SCHED_CORE=n, the test fails. So you might end up seeing default selftests failing on such systems? or this is only compiling?>
Yes, this patch would enable the test to be compiled and run by default.
Likely the selftests/sched needs to modified for CONFIG_SCHED_CORE=n
Agree. Chris, I suppose then a graceful skip would be a more right option for kernels with core scheduling disabled?
By graceful skip, do you mean a 0 return code and not printing failure? I confess, I originally wrote the test as stand-alone for me to get the prctl code right and it got shoved in here.
I guess my question is what if SCHED_CORE was supposed to be configed into the test kernel? Silently burying the error might be bad. I'm not strongly tied to that, just looking for opinions. At the same time, if you put the orig change in, people w/o SCHED_CORE on will start seeing "failures" they didn't see before, yes? and that seems bad.
I'm happy to make this better behaved. I'm the reason it is the way it is.
-chrish
On 20-02-2025 09:26 pm, Chris Hyser wrote:
From: Sinadin Shan sinadin.shan@oracle.com Sent: Thursday, February 20, 2025 9:52 AM To: Shrikanth Hegde; Chris Hyser Cc: linux-kselftest@vger.kernel.org; linux-kernel@vger.kernel.org; shuah@kernel.org Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
On 20-02-2025 01:15 pm, Shrikanth Hegde wrote:
If CONFIG_SCHED_CORE=n, the test fails. So you might end up seeing default selftests failing on such systems? or this is only compiling?>
Yes, this patch would enable the test to be compiled and run by default.
Likely the selftests/sched needs to modified for CONFIG_SCHED_CORE=n
Agree. Chris, I suppose then a graceful skip would be a more right option for kernels with core scheduling disabled?
By graceful skip, do you mean a 0 return code and not printing failure? I confess, I originally wrote the test as stand-alone for me to get the prctl code right and it got shoved in here.
By graceful skip, I meant printing that SCHED_CORE is disabled for the kernel and exiting with a return code 4 on such kernels. This would also make the kselftest framework pick up the skip, say when compiled tests are run through run_kselftest.sh
I guess my question is what if SCHED_CORE was supposed to be configed into the test kernel? Silently burying the error might be bad. I'm not strongly tied to that, just looking for opinions. At the same time, if you put the orig change in, people w/o SCHED_CORE on will start seeing "failures" they didn't see before, yes? and that seems bad.
Yes, that seems bad as rightly pointed out by Shrikant. I have a patch that does the above mentioned skip, and if skipping is a right option to take here I can send it in the next version.
Regards, Shan
I'm happy to make this better behaved. I'm the reason it is the way it is.
-chrish
From: Sinadin Shan sinadin.shan@oracle.com Sent: Thursday, February 20, 2025 11:23 AM To: Chris Hyser; Shrikanth Hegde Cc: linux-kselftest@vger.kernel.org; linux-kernel@vger.kernel.org; shuah@kernel.org Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
I guess my question is what if SCHED_CORE was supposed to be configed into the test kernel? Silently burying the error might be bad. I'm not strongly tied to that, just looking for opinions. At the same time, if you put the orig change in, people w/o SCHED_CORE on will start seeing "failures" they didn't see before, yes? and that seems bad.
Yes, that seems bad as rightly pointed out by Shrikant. I have a patch that does the above mentioned skip, and if skipping is a right option to take here I can send it in the next version.
If that is the plan, I prefer to fix it myself.
-chrish
From: Chris Hyser chris.hyser@oracle.com Sent: Thursday, February 20, 2025 11:21 PM To: Sinadin Shan; Shrikanth Hegde Cc: linux-kselftest@vger.kernel.org; linux-kernel@vger.kernel.org; shuah@kernel.org Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
From: Sinadin Shan sinadin.shan@oracle.com Sent: Thursday, February 20, 2025 11:23 AM To: Chris Hyser; Shrikanth Hegde Cc: linux-kselftest@vger.kernel.org; linux-kernel@vger.kernel.org; shuah@kernel.org Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
I guess my question is what if SCHED_CORE was supposed to be configed into the test kernel? Silently burying the error might be bad. I'm not strongly tied to that, just looking for opinions. At the same time, if you put the orig change in, people w/o SCHED_CORE on will start seeing "failures" they didn't see before, yes? and that seems bad.
Yes, that seems bad as rightly pointed out by Shrikant. I have a patch that does the above mentioned skip, and if skipping is a right option to take here I can send it in the next version.
If that is the plan, I prefer to fix it myself.
Ok. Here is a better plan. I suspected there must be some convention for all these tests (that you are obviously familiar with), I just feel bad for how this test originally got jammed in here. If you already have a patch, we should just go with that and yes adding that code seems like the exact right thing to do.
-chrish
On 21-02-2025 11:30 am, Chris Hyser wrote:
From: Chris Hyser chris.hyser@oracle.com Sent: Thursday, February 20, 2025 11:21 PM To: Sinadin Shan; Shrikanth Hegde Cc: linux-kselftest@vger.kernel.org; linux-kernel@vger.kernel.org; shuah@kernel.org Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
From: Sinadin Shan sinadin.shan@oracle.com Sent: Thursday, February 20, 2025 11:23 AM To: Chris Hyser; Shrikanth Hegde Cc: linux-kselftest@vger.kernel.org; linux-kernel@vger.kernel.org; shuah@kernel.org Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
I guess my question is what if SCHED_CORE was supposed to be configed into the test kernel? Silently burying the error might be bad. I'm not strongly tied to that, just looking for opinions. At the same time, if you put the orig change in, people w/o SCHED_CORE on will start seeing "failures" they didn't see before, yes? and that seems bad.
Yes, that seems bad as rightly pointed out by Shrikant. I have a patch that does the above mentioned skip, and if skipping is a right option to take here I can send it in the next version.
If that is the plan, I prefer to fix it myself.
Ok. Here is a better plan. I suspected there must be some convention for all these tests (that you are obviously familiar with), I just feel bad for how this test originally got jammed in here. If you already have a patch, we should just go with that and yes adding that code seems like the exact right thing to do.
Thanks Chris, I shall send the new patch.
-Shan
-chrish
linux-kselftest-mirror@lists.linaro.org