linux-kernel - Re: [PATCH v4] posix-timers: Prefer delivery of signals to the current thread

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: <87o7qlgjce.ffs@tglx>
Date:   Thu, 26 Jan 2023 20:57:05 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Marco Elver <elver@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>
Cc:     oleg@...hat.com, linux-kernel@...r.kernel.org,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [PATCH v4] posix-timers: Prefer delivery of signals to the
 current thread

On Thu, Jan 26 2023 at 18:51, Marco Elver wrote:
> On Thu, 26 Jan 2023 at 16:41, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>>
>> Prefer to deliver signals to the current thread if SIGEV_THREAD_ID
>> is not set. We used to prefer the main thread, but delivering
>> to the current thread is both faster, and allows to sample actual thread
>> activity for CLOCK_PROCESS_CPUTIME_ID timers, and does not change
>> the semantics (since we queue into shared_pending, all thread may
>> receive the signal in both cases).
>
> Reviewed-by: Marco Elver <elver@...gle.com>
>
> Nice - and and given the test, hopefully this behaviour won't regress in future.

The test does not tell much. It just waits until each thread got a
signal once, which can take quite a while. It does not tell about the
distribution of the signals, which can be completely randomly skewed
towards a few threads.

Also for real world use cases where you have multiple threads with
different periods and runtime per period I have a hard time to
understand how that signal measures anything useful.

The most time consuming thread might actually trigger rarely while other
short threads end up being the ones which cause the timer to fire.

What's the usefulness of this information?

Thanks,

        tglx