[LTP] [PATCH v2] sched: add sched sysctl sanity test

Petr Vorel pvorel@suse.cz
Wed Jan 10 13:26:30 CET 2024


> Hi!
> > It looks like the second fix 079be8fc6309 ("sched/rt: Disallow writing invalid
> > values to sched_rt_period_us") is not in stable, shouldn't be there?

> No idea to be honest, the second fix about rejecting invalid values is a
> minor fix.

IMHO it's a fix of broken functionality. And Greg stated several times that
stable is not only for security fixes but for other fixes. Therefore I would
vote for adding it.

> > > - Fixed a few whitespaces
> > > - Added second kernel commit into metadata
> > nit: metadata of the git commit looks ugly, but we would need to agree on better
> > solution.

> Which metadata exactly? This part is after the scisors and will be cut
> when the patch is applied.

I don't like formatting after "This is a regression test for a commits:".
It formates like code block (gray background) via using <pre>...</pre> HTML
tags:

	commit c1fc6484e1fb7cc2481d169bfef129a1b0676abe
	Author: Cyril Hrubis <chrubis@suse.cz>
	Date:   Wed Aug 2 17:19:06 2023 +0200

	sched/rt: sysctl_sched_rr_timeslice show default timeslice after reset

	commit 079be8fc630943d9fc70a97807feb73d169ee3fc
	Author: Cyril Hrubis <chrubis@suse.cz>
	Date:   Mon Oct 2 13:55:51 2023 +0200

	sched/rt: Disallow writing invalid values to sched_rt_period_us

(see a real output in metadata.html)

Given we have this in the Tag table below, I found it useless. I mean, we could
have it, but not in docparse comment /*\ ... */, but in normal C comment /* ... */
(for reader of the C source, but not in docparse format). Or, if we want to have
it in docparse output, we could format it as:

 /*\
...
 * This is a regression test for a commits:

 * * c1fc6484e1fb ("sched/rt: sysctl_sched_rr_timeslice show default timeslice after reset")
 * * 079be8fc6309 ("sched/rt: Disallow writing invalid values to sched_rt_period_us")

This is not unique to this commit, we don't have to solve it now (and it's
definitely a blocker for this patch). But it would be good to find a consensus
how the output should look like.

Kind regards,
Petr


More information about the ltp mailing list