linux-kernel - Re: [PATCH] timer: document 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 27 Jun 2019 00:43:03 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Peter Xu <peterx@...hat.com>
cc:     linux-kernel@...r.kernel.org,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Luiz Capitulino <lcapitulino@...hat.com>
Subject: Re: [PATCH] timer: document TIMER_PINNED

Peter,

On Tue, 18 Jun 2019, Peter Xu wrote:
> -/*
> - * A deferrable timer will work normally when the system is busy, but
> - * will not cause a CPU to come out of idle just to service it; instead,
> - * the timer will be serviced when the CPU eventually wakes up with a
> - * subsequent non-deferrable timer.
> +/**
> + * @TIMER_DEFERRABLE: A deferrable timer will work normally when the
> + * system is busy, but will not cause a CPU to come out of idle just
> + * to service it; instead, the timer will be serviced when the CPU
> + * eventually wakes up with a subsequent non-deferrable timer.
>   *
> - * An irqsafe timer is executed with IRQ disabled and it's safe to wait for
> - * the completion of the running instance from IRQ handlers, for example,
> - * by calling del_timer_sync().
> + * @TIMER_IRQSAFE: An irqsafe timer is executed with IRQ disabled and
> + * it's safe to wait for the completion of the running instance from
> + * IRQ handlers, for example, by calling del_timer_sync().
>   *
>   * Note: The irq disabled callback execution is a special case for
>   * workqueue locking issues. It's not meant for executing random crap
>   * with interrupts disabled. Abuse is monitored!
> + *
> + * @TIMER_PINNED: A pinned timer will not be affected by timer
> + * migration so it will always be run on a static cpu that was
> + * specified.

That's a bit misleading.

The timer pinned flag prevents the MOHZ timer placement heuristics to take
effect. That means that the timer is enqueued on the CPU on which the
enqueue function is invoked. 

> + * Note: neither timer_setup() nor mod_timer() will
> + * guarantee correct pinning of timers.  One should always use
> + * add_timer_on() when arm the timer to guarantee that the timer will
> + * be pinned to the target CPU correctly.

I'd rather say:

    That means that pinned timers are not guaranteed to stay on the
    initialy selected CPU. They move to the CPU on which the enqueue
    function is invoked via mod_timer() or add_timer().

    If the timer should be placed on a particular CPU then add_timer_on()
    has to be used.

Or something like that. Too tired to think about it right now, but you get
the idea.

Thanks,

	tglx