linux-kernel - Re: timer

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]

Date:   Fri, 26 May 2017 09:13:35 +0200
From:   John Ogness <john.ogness@...utronix.de>
To:     Nicolae Rosia <nicolae.rosia.oss@...il.com>
Cc:     linux-rt-users@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org
Subject: Re: timer_create affinity

On 2017-05-25, Nicolae Rosia <nicolae.rosia.oss@...il.com> wrote:
> I'm working on a real-time application using POSIX timers running on a
> QorIQ PowerPC platform with a 4.1 PREEMPT RT kernel and I'm trying to
> understand whether the following can happen:
>
> 1. A thread with a core affinity #0 creates a timer which will invoke
> a callback.
> 2. The kernel will setup the timer using a local timer running on a
> different core, core #1
> 3. The ISR will fire, and could be dispatched by core #2
> 4. The scheduler will run the callback on core #3.
>
> Is there a way to make sure this whole chain will be executed on a
> single core, the core of the caller?

Avoid POSIX timers if you can. POSIX timers not only have the issue that
you mentioned, but also are generally bad for realtime applications.

The realtime wiki has an example[0] of running a cyclic task. With that
simple example you have complete control over the context of your
task. This is necessary to avoid things like priority inversion and
page-faults, and gives you control over things like affinity or cgroups.

John Ogness

[0] https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/cyclic