linux-kernel - Re: [PATCH 2/2] rseq/selftests: Add test for mm

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 for Android: free password hash cracker in your pocket

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

Message-ID: <8c5cdd12a0ec80d43fe737f5d2c4600d5933ba87.camel@redhat.com>
Date: Tue, 18 Feb 2025 14:49:32 +0100
From: Gabriele Monaco <gmonaco@...hat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
	linux-kernel@...r.kernel.org
Cc: Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.org>, 
 "Paul E. McKenney"
	 <paulmck@...nel.org>
Subject: Re: [PATCH 2/2] rseq/selftests: Add test for mm_cid compaction

On Tue, 2025-02-18 at 09:13 +0100, Gabriele Monaco wrote:
> 
> However, I'm still not particularly fond of running stuff there at
> all.
> If a periodic task needs to run now, it preempts everything else and
> should be on its way as soon as possible. A task work is always going
> to delay this, although by a tiny bit.
> 
> Again, for now I cannot think of a better way without bringing
> workqueues into the picture, and in this specific case we have a
> valid
> workaround to reduce the latency.
> 

Been thinking about this for a while, what about getting the best from
both worlds?
MMs already have a dependency on workqueues (async_put_work) they
simply don't wildly schedule them like I was doing, essentially, the
whole periodic delayed_work thing was the issue.
Substituting what is currently a task_work with a plain work_struct (on
the mm) doesn't look too bad to me.

We still keep the mechanism to trigger and regulate its frequency and,
instead of doing it from a tick, we do it from
__rseq_handle_notify_resume.
This way we won't have it scheduled for sleeping, never running or
whatever exotic threads (which was a potential issue with the
delayed_work) but we also keep it in a preemptible context with
frequency comparable to the task_work.

Running it in a work_struct would probably make the batch scan
superfluous, since we are talking about some 30us which can run
perfectly fine in a kworker.

What do you think?

Thanks,
Gabriele