linux-kernel - Re: [PATCH] sched: Move task_mm_cid

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

Message-ID: <94c05164fe0bc0b0f52fec3a1d21e0b836fbdf54.camel@redhat.com>
Date: Mon, 09 Dec 2024 09:12:30 +0100
From: Gabriele Monaco <gmonaco@...hat.com>
To: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched: Move task_mm_cid_work to mm delayed work


On Fri, 2024-12-06 at 09:06 -0500, Mathieu Desnoyers wrote:
>
> Thinking back on this, you'll want a program that does the following
> on a system with N CPUs:
>
> - Phase 1: run one thread per cpu, pinned on each cpu. Print the
>    mm_cid from each thread with the cpu number every second or so.
>
> - Exit all threads except the main thread, join them from the main
>    thread,
>
> - Phase 2: the program is now single-threaded. We'd expect the
>    mm_cid value to converge towards 0 as the periodic task clears
>    unused CIDs.
>
> So I think in phase 2 we can have an actual automated test: If after
> an order of magnitude more time than the 100ms delay between periodic
> tasks we still observe mm_cid > 0 in phase 2, then something is
> wrong.
>
> Thoughts ?

Nice idea, that looks neat and fairly simple. Also by printing every
second we would get the threads running in short bursts and, probably,
the test would fail with the current implementation, depending how long
we wait, of course.
I can try to draft something to test my implementation.

Thanks,
Gabriele