linux-kernel - [patch V3 0/3] posix-cpu-timers: Move expiry into task work context

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

Message-Id: <20200730101404.956367860@linutronix.de>
Date:   Thu, 30 Jul 2020 12:14:04 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     LKML <linux-kernel@...r.kernel.org>
Cc:     x86@...nel.org, Oleg Nesterov <oleg@...hat.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Frederic Weisbecker <frederic@...nel.org>,
        John Stultz <john.stultz@...aro.org>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: [patch V3 0/3] posix-cpu-timers: Move expiry into task work context

This is the 3rd installment of the series to move posix timer expiry heavy
lifting out of hard interrupt context.

Running posix CPU timers in hard interrupt context has a few downsides:

 - For PREEMPT_RT it cannot work as the expiry code needs to take
   sighand lock, which is a 'sleeping spinlock' in RT. The original RT
   approach of offloading the posix CPU timer handling into a high
   priority thread was clumsy and provided no real benefit in general.

 - For fine grained accounting it's just wrong to run this in context of
   the timer interrupt because that way a process specific cpu time is
   accounted to the timer interrupt.

 - Long running timer interrupts caused by a large amount of expiring
   timers which can be created and armed by unpriviledged user space.

There is no hard requirement to expire them in interrupt context.

If the signal is targeted at the task itself then it won't be delivered
before the task returns to user space anyway. If the signal is targeted at
a supervisor process then it might be slightly delayed, but posix CPU
timers are inaccurate anyway due to the fact that they are tied to the
tick.

This series has no code dependency on the entry/KVM work, but a functional
dependency vs. KVM handling task work before going into guest mode exists.
It applies on mainline and passes all tests - except when KVM is active and
timers are armed on the KVM threads. This particular issue is solved when
the entry changes are applied as well. See below.

The previous version can be found here:

    https://lore.kernel.org/r/20200716201923.228696399@linutronix.de

The changes versus V2 are:

    - Address the ordering issues vs. RT (Peter)
    - Move task work head into task struct (Oleg)
    - Drop the last patch which is an optimization and needs more thought
      now with the reworked state handling.

The series is standalone except for the fact that KVM does not handle task
work before entering a guest. The necessary changes for this are in

    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry

and the whole lot (entry + posix CPU timers) is available from:

    git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git timers/posixtimer

Thanks,

	tglx

---
 arch/x86/Kconfig               |    1 
 include/linux/posix-timers.h   |   17 +++
 include/linux/sched.h          |    4 
 include/linux/seccomp.h        |    3 
 kernel/entry/common.c          |    4 
 kernel/time/Kconfig            |    9 +
 kernel/time/posix-cpu-timers.c |  216 ++++++++++++++++++++++++++++++++++++-----
 kernel/time/timer.c            |    1 
 8 files changed, 227 insertions(+), 28 deletions(-)