Received: by 2002:ab2:1347:0:b0:1f4:ac9d:b246 with SMTP id g7csp64295lqg; Wed, 10 Apr 2024 15:46:22 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXcZ0mafq93rscP6jlyej1JCGJkYLJYRgDr4tPxfsvUNJeSTARJgfj5Bw8iEWusFuvqRkDBva1Ey50I0/CSlOQtE+B0D4eFlPqdWofxbw== X-Google-Smtp-Source: AGHT+IFRzxDYe7cRtZXAk45wE08Wx1+EhirpdpLuygiJLGKZuATk8y0//JHk3TzE9Mo4EtGNo5oW X-Received: by 2002:a05:6214:c42:b0:69b:2446:2f0e with SMTP id r2-20020a0562140c4200b0069b24462f0emr3732146qvj.34.1712789182549; Wed, 10 Apr 2024 15:46:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712789182; cv=pass; d=google.com; s=arc-20160816; b=yQL784Gnsqr0zuHUCSt+oUaP6AeeeS+4AOau5bppWq/uUBMHv/Jfbvye0J1L7R5Gsl eB3WDncFmvJ4LyTCWfZUFZQ4LRQmsb+tmx/9gEcV5Gps4dVpPlyCD/CvAD6Dk/iczFNA kgqZ8AnZ2qHAbJFZcZSS8XIOJ3HaDOmvse4+emocnPkbcYivfdacSHk/12vJ/m08NXJL 7mWsAESK9H3S2iXiVmJ9UxJmFds3jUAP8yVE6GLKk8vtCbwWP6DSh6ifgxOulpmmIGTl aNd/IXVqvp4KHY4JYugvYFxEpRKdGRZH1QnhSiooZ3LXeFM50dz2m1HySf6mAZquULLS I94g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-id:precedence:date:subject:cc :to:from:dkim-signature:dkim-signature:message-id; bh=O7Dfk2XBW3xV635fF4z7Tq7JJbMTU+/tQLvji5B+0ek=; fh=joBs/8L+orz77ylyCy6wqNwwi35f7sYhLR+/TQjQjhI=; b=eQ1yYEbvBu9+AXr68j3Hvo2FoJpK2eWC+pZAe5m2UwhFZ4XzI9bZ56/Opqtt4m2UiB qGkPzxAGpR6r8wxYHBya5L/iRTmNppOCGKxWQrTLu2Lgq9RR0tFz97bT1ldhO+Q41w07 xSimj/qVVuRVRvvlBhPInSjS4ayhFa03pazA+UDWGH5Qzrs95StnwwLjahXCGxeZcSPL T1EGVav6jK5pqAWXHRlsoOlYJ8y7LeIis5TIA4zbhi6byITyeTEbj0zBue8PYfY/9p9B RSPJwziXl9Y/YJM8knhL7lj1efWcWaXTZB9hYxl4hlT6NozLCJnyL+LVKWl6ES7Ymdwr GMpQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=jukuL98k; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; arc=pass (i=1 spf=pass spfdomain=linutronix.de dkim=pass dkdomain=linutronix.de dmarc=pass fromdomain=linutronix.de); spf=pass (google.com: domain of linux-kernel+bounces-139452-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-139452-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id eu12-20020ad44f4c000000b0069905f21e60si200775qvb.493.2024.04.10.15.46.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Apr 2024 15:46:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-139452-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=jukuL98k; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; arc=pass (i=1 spf=pass spfdomain=linutronix.de dkim=pass dkdomain=linutronix.de dmarc=pass fromdomain=linutronix.de); spf=pass (google.com: domain of linux-kernel+bounces-139452-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-139452-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 3A7AC1C20EB7 for ; Wed, 10 Apr 2024 22:46:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 48A0A175A4; Wed, 10 Apr 2024 22:46:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="jukuL98k"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="KMnenegG" Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACCE5BA49 for ; Wed, 10 Apr 2024 22:46:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712789176; cv=none; b=Lxz0S47JgP3KFgIuGsKh2t3r9hOJsE4O1MoBTxYLDUt4/VnDYOgfVatO93m/QnGHu1hwrxrtqMSxDDz+Gp4HPi7srcyHOOl4hBrgXjMhhcRw91MQ+hTkHdnxD+6DPrKyY/P+AGEij8hSmIrChtL/vevprwndqZVRQmR+YPGlec4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712789176; c=relaxed/simple; bh=qBubWXQbBIq6P4Kw2H8EobgXNMlS2x+iH1nFOnrDOQQ=; h=Message-ID:From:To:Cc:Subject:Date; b=mM8Rj/ExWWnaFjkdTQ9w86AEMCtrFMOne5IOHGze7j5l65OvfGlAOLpKmku0LqLLOgZNeMhdgABt7PVXGODHJfmgMiqZ3mwAOL5XNOGit4FEvoFST+Gf8td3LpMGUOHCSqDGsCQ0QU/tEx33X0iCZ2AkK4/HD4+2HfPra2GfJrc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=jukuL98k; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=KMnenegG; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Message-ID: <20240410164558.316665885@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1712789172; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=O7Dfk2XBW3xV635fF4z7Tq7JJbMTU+/tQLvji5B+0ek=; b=jukuL98kzCufhpC1QVoxBcgVIHMMvgtVFXaa1nFoygzt2TliWnLYtbENaASnaBa83xZ5xI 3EPmTj+PgKR1F6PBkofY4pJNCWuhZbJJTxQLsHzf8J20IN6f95M3R78VEguo1bQhI8QTfp AhYTDm9K1L7vd6E018j0llKVlAzzRnX3BDu/bCZDF37a4OuiP1XjLEpGrr5+2b0QTO1G3+ AlAkqnpeEaXMbVTGprvxdPe8mkL/wrG9RgeIYCUsWDBIvGXityxFJ5XKKm52dIVQTOpvM5 CwnTjZK4chyDPXAzwsTQWrSqc0IHsDfbjhqRSkTLE+15weW62pBpkWNUWd7sGw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1712789172; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=O7Dfk2XBW3xV635fF4z7Tq7JJbMTU+/tQLvji5B+0ek=; b=KMnenegGN19JwKoo3AKss9kpMXWL2aDIgUuxYYIDyyO37ijEv9chuOFi5MRiY619+TRrWE h2g+TW50D69F/6Aw== From: Thomas Gleixner To: LKML Cc: Anna-Maria Behnsen , Frederic Weisbecker , John Stultz , Peter Zijlstra , Ingo Molnar , Stephen Boyd , Eric Biederman , Oleg Nesterov Subject: [patch V2 00/50] posix-timers: Cure inconsistencies and the SIG_IGN mess Date: Thu, 11 Apr 2024 00:46:12 +0200 (CEST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: This is the second attempt of cleaning this up. Version 1 can be found here: https://lore.kernel.org/lkml/20230606132949.068951363@linutronix.de/ Last year I reread a 15 years old comment about the SIG_IGN problem: "FIXME: What we really want, is to stop this timer completely and restart it in case the SIG_IGN is removed. This is a non trivial change which involves sighand locking (sigh !), which we don't want to do late in the release cycle. ... A more complex fix which solves also another related inconsistency is already in the pipeline." The embarrasing part was that I put that comment in back then. So I went back and rumaged through old notes as I completely had forgotten why our attempts to fix this back then failed. It turned out that the comment is about right: sighand locking and life time issues. So I sat down with the old notes and started to wrap my head around this again. The problem to solve: Posix interval timers are not rearmed automatically by the kernel for various reasons: 1) To prevent DoS by extremly short intervals. 2) To avoid timer overhead when a signal is pending and has not yet been delivered. This is achieved by queueing the signal at timer expiry and rearming the timer at signal delivery to user space. This puts the rearming basically under scheduler control and the work happens in context of the task which asked for the signal. There is a problem with that vs. SIG_IGN. If a signal has SIG_IGN installed as handler the related signals are discarded. So in case of posix interval timers this means that such a timer is never rearmed even when SIG_IGN is replaced later with a real handler (including SIG_DFL). To work around that the kernel self rearms those timers and throttles them when the interval is smaller than a tick to prevent a DoS. That just keeps timers ticking, which obviously has effects on power and just creates work for nothing. So ideally these timers should be stopped and rearmed when SIG_IGN is replaced, which aligns with the regular handling of posix timers. Sounds trivial, but isn't: 1) Lock ordering. The timer lock cannot be taken with sighand lock held which is problematic vs. the atomicity of sigaction(). 2) Life time rules The timer and the sigqueue are separate entities which requires a lookup of the timer ID in the signal rearm code. This can be handled, but the separate life time rules are not necessarily robust. 3) Finding the relevant timers Obviosly it is possible to walk the posix timer list under sighand lock and handle it from there. That can be expensive especially in the case that there are no affected timers as the walk would just end up doing nothing. The following series is a new and this time actually working attempt to solve this. It addresses it by: 1) Embedding the preallocated sigqueue into struct k_itimer, which makes the life time rules way simpler and just needs a trivial reference count. 2) Having a separate list in task::signal on which ignored timers are queued. This avoids walking a potentially large timer list for nothing on a SIG_IGN to handler transition. 3) Requeueing the timers signal in the relevant signal queue so the timer is rearmed when the signal is actually delivered That turned out to be the least complicated way to address the sighand lock vs. timer lock ordering issue. With that timers which have their signal ignored are not longer self rearmed and the relevant workarounds including throttling for DoS prevention are removed. Aside of the SIG_IGN issues it also addresses a few inconsistencies in posix CPU timers and the general inconsistency of signal handling vs. disarmed, reprogrammed and deleted timers. To actually validate the fixes the posix timer self test has been expanded with tests which cover not only the simple SIG IGN case but also more complex scenarios which have never been handled correctly by the current self rearming work around. The series is based on: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/urgent and is also available from git: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git timers/posix Changes vs. V1: - Dropped the timer distribution check changes as that has been handled upstream differently (it's in timers/urgent and soon in Linus tree) - Split up patch 9 for the sake of easier review - Frederic - Addressed the review comments from Frederic - Picked up Reviewed-by tags where appropriate Thanks, tglx --- arch/x86/kernel/signal_32.c | 2 arch/x86/kernel/signal_64.c | 2 drivers/power/supply/charger-manager.c | 3 fs/proc/base.c | 10 fs/signalfd.c | 4 fs/timerfd.c | 4 include/linux/alarmtimer.h | 10 include/linux/posix-timers.h | 69 ++- include/linux/sched/signal.h | 11 include/uapi/asm-generic/siginfo.h | 2 init/init_task.c | 5 kernel/fork.c | 3 kernel/signal.c | 486 +++++++++++++--------- kernel/time/alarmtimer.c | 82 --- kernel/time/itimer.c | 22 - kernel/time/posix-cpu-timers.c | 231 ++++------ kernel/time/posix-timers.c | 276 ++++++------- kernel/time/posix-timers.h | 9 net/netfilter/xt_IDLETIMER.c | 4 tools/testing/selftests/timers/posix_timers.c | 550 +++++++++++++++++++++----- 20 files changed, 1092 insertions(+), 693 deletions(-)