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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <cbc0a3c5-2ae5-439e-ae5d-7fb68ea49aec@efficios.com>
Date: Mon, 9 Dec 2024 10:33:31 -0500
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Gabriele Monaco <gmonaco@...hat.com>, Ingo Molnar <mingo@...hat.com>,
 Peter Zijlstra <peterz@...radead.org>,
 Andrew Morton <akpm@...ux-foundation.org>, Mel Gorman <mgorman@...e.de>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Cc: Juri Lelli <juri.lelli@...hat.com>,
 Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH] sched: Move task_mm_cid_work to mm delayed work

On 2024-12-09 08:45, Gabriele Monaco 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.
> 
> Been thinking about this and came up with a simple draft, I'll probably
> send it as a separate patch.
> 
> Doing this can lead to false positives: the main thread may be assigned
> the mm_cid 0 and keep it till the end, in this scenario the other
> threads (CPUs) would get different mm_cids and exit, the main thread
> will still have 0 and pass the test regardless.
> 
> I have an idea to make it a bit more robust: we can run threads as you
> described in phase 1, stop all but one (let's say the one running on
> the last core), make sure the main thread doesn't accidentally run on
> the same core by pinning to core 0 and wait until we see the 2
> remaining threads holding 0 and 1, in any order.
> Besides a special case if we have only 1 available core, this should
> work fine, sure we could get false positives but it seems to me much
> less likely.
> 
> Does it make sense to you?

A small tweak on your proposed approach: in phase 1, get each thread
to publish which mm_cid they observe, and select one thread which
has observed mm_cid > 1 (possibly the largest mm_cid) as the thread
that will keep running in phase 2 (in addition to the main thread).

All threads other than the main thread and that selected thread exit
and are joined before phase 2.

So you end up in phase 2 with:

- main (observed any mm_cid)
- selected thread (observed mm_cid > 1, possibly largest)

Then after a while, the selected thread should observe a
mm_cid <= 1.

This test should be skipped if there are less than 3 CPUs in
allowed cpumask (sched_getaffinity).

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com