linux-kernel - Re: [PATCH v2 20/20] rv: Add deadline monitors

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: <646db9e9d956f009d53bfabf8b8287c034279066.camel@redhat.com>
Date: Mon, 13 Oct 2025 09:30:24 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Nam Cao <namcao@...utronix.de>, linux-kernel@...r.kernel.org, Steven
 Rostedt <rostedt@...dmis.org>, Jonathan Corbet <corbet@....net>, Masami
 Hiramatsu	 <mhiramat@...nel.org>, linux-trace-kernel@...r.kernel.org, 
	linux-doc@...r.kernel.org
Cc: Tomas Glozar <tglozar@...hat.com>, Juri Lelli <jlelli@...hat.com>, Clark
 Williams <williams@...hat.com>, John Kacur <jkacur@...hat.com>
Subject: Re: [PATCH v2 20/20] rv: Add deadline monitors

On Fri, 2025-10-10 at 17:04 +0200, Nam Cao wrote:
> Gabriele Monaco <gmonaco@...hat.com> writes:
> > +/*
> > + * Dummy values if not available
> > + */
> > +#ifndef __NR_sched_setscheduler
> > +#define __NR_sched_setscheduler -1
> > +#endif
> > +#ifndef __NR_sched_setattr
> > +#define __NR_sched_setattr -2
> > +#endif
> 
> You can use __COUNTER__ intead, would make it easier to add to or remove
> from this list later on.

Right, good point.

> > +static void handle_syscall(void *data, struct pt_regs *regs, long id)
> > +{
> > +	struct task_struct *p;
> > +	int new_policy = -1;
> > +
> > +	new_policy = extract_params(regs, id, &p);
> > +	if (new_policy < 0 || new_policy == p->policy)
> > +		return;
> > +	if (p->policy == SCHED_DEADLINE)
> > +		da_reset(EXPAND_ID(&p->dl, DL_TASK));
> > +	else if (new_policy == SCHED_DEADLINE)
> > +		da_create_conditional(EXPAND_ID(&p->dl, DL_TASK),
> > GFP_NOWAIT);
> > +}
> 
> What if the syscall fails for any reason? Wouldn't the monitor stores
> incorrect information?

Yes, that could happen, this seems an issue only in the throttle monitor when
failing a DEADLINE->NORMAL, other cases are at most resetting the monitor.

In this case, the monitor is really saying: a deadline task is no longer
deadline, so its runtime should be counted as fair server. If the syscall does
fail, we are assuming the fair server as armed (not running) for a bit more.

Here I couldn't find a nice way to handle this: if I attach only to the syscall
return, I see if it succeeded but I lost the previous policy, attaching to both
(and keep a per-cpu storage just for this process) seems a bit overcomplicated.
I see this can potentially lead to errors in the monitor, but I'm not sure the
extra complexity is worth it here, considering this failure might only happen if
a user really makes wrong calls.
I tried to avoid creating a new tracepoint on a successful policy change.

What do you think?

Thanks,
Gabriele