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