linux-kernel - Re: [PATCH] selftests: sched: add sched as a default selftest target

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <CO1PR10MB470557AF5FC26790CB8FB2FE9BC72@CO1PR10MB4705.namprd10.prod.outlook.com>
Date: Fri, 21 Feb 2025 06:00:44 +0000
From: Chris Hyser <chris.hyser@...cle.com>
To: Sinadin Shan <sinadin.shan@...cle.com>,
        Shrikanth Hegde
	<sshegde@...ux.ibm.com>
CC: "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "shuah@...nel.org" <shuah@...nel.org>
Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target

From: Chris Hyser <chris.hyser@...cle.com>
Sent: Thursday, February 20, 2025 11:21 PM
To: Sinadin Shan; Shrikanth Hegde
Cc: linux-kselftest@...r.kernel.org; linux-kernel@...r.kernel.org; shuah@...nel.org
Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
>
> From: Sinadin Shan <sinadin.shan@...cle.com>
> Sent: Thursday, February 20, 2025 11:23 AM
> To: Chris Hyser; Shrikanth Hegde
> Cc: linux-kselftest@...r.kernel.org; linux-kernel@...r.kernel.org; shuah@...nel.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