linux-kernel - Re: [PATCH v4 19/22] rv: Add rtapp

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] [day] [month] [year] [list]

Message-ID: <20250424034005.B71HTlCE@linutronix.de>
Date: Thu, 24 Apr 2025 05:40:05 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org,
	john.ogness@...utronix.de
Subject: Re: [PATCH v4 19/22] rv: Add rtapp_pagefault monitor

On Wed, Apr 23, 2025 at 12:37:53PM +0200, Gabriele Monaco wrote:
> On Wed, 2025-04-23 at 08:50 +0200, Nam Cao wrote:
> > +static void ltl_atoms_fetch(struct task_struct *task, struct
> > ltl_monitor *mon)
> > +{
> > +	ltl_atom_set(mon, LTL_RT, rt_or_dl_task(task));
> > +}
> 
> Mmh, you probably already considered that, so ignore my comment in that case.
> 
> I just realised this function would tell you a PI boosted task is an RT task,
> is that acceptable in your model?

Yes, that is intentional. A task being PI boosted means an "actual"
real-time task is waiting for it. Therefore the PI boosted task shouldn't
be delayed, otherwise the "actual" real-time task is delayed.

> It's probably a configuration mistake on its own if an RT task following those
> rules shares resources with non-RT tasks not following them,

non-RT tasks do not have to follow the rules all the time. But while
accessing resources shared with RT tasks, then yes the rules should be
obeyed.

> but if that's something allowed, you may see this atom change more often
> than you'd like, not sure if that can be something worth noting.
>
> Perhaps you could add a comment saying that this is not a problem and why (e.g.
> instead of using rt_or_dl_task_policy for the job).

Sure, a comment doesn't hurt.

> What do you think?
> 
> Besides this detail, the monitor looks good to me
> Reviewed-by: Gabriele Monaco <gmonaco@...hat.com>

Thanks so much for the review!

Nam