From patchwork Mon Oct 24 10:44:22 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Wagner X-Patchwork-Id: 8328 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp376099wru; Mon, 24 Oct 2022 03:57:24 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6khfwv4rw0n7YjgzxPZDtvxRKmtZfF8W4IMxswwtPRgWik5q8cX7mMiEI8dLcPDiya6YCQ X-Received: by 2002:a17:906:cc5a:b0:78d:c3cf:6ff7 with SMTP id mm26-20020a170906cc5a00b0078dc3cf6ff7mr27374347ejb.383.1666609033813; Mon, 24 Oct 2022 03:57:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666609033; cv=none; d=google.com; s=arc-20160816; b=PlDsaxupgcayCfsdFOUJPxxBWlGjlJ5P0O9qgVlyzcdBdUBbIRN0WQPaxWsFaC5xFc omaOlR3XwlnSw2m7YcZnWHYEdNkatTKMQq41Rkky4xJ1UbpZZtYHebHbZ1y1p5TUa23R QjMv0ZfkpXrMAkakmxGW5rMegjYufStFTWT7YWR6D0jV+5NKyRmhoJqN7G0GvJ8L4gIQ v0ab4Yf7p/5EufPEAOmEfgtDGOoW40rFWnjmMQvBuXWRYZ3pm+H8762k424jDsgU+z8P v6t6oMAmTL6aSA7eWdg8UFzEJI1dAFpuFvYWdSrrJerPp+yZ4lsr8FXoDnnE5hsMGLBS eJCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=BOoIY9WJFmBt1PSHlkPpnZQdqGiT4O4onH5CW/obUpI=; b=L0kpBhHQJfQ3MSu+TqjSrAOFYcR5rNMjMeEVm6VoaJ7HIfXYsb5R9jhbL0PeADGntO r/y9MmmJWq9x+f1+4I85beex2QkjiSgv8gY4p+MrKors36iaD3qgzQQcxRruxkkLBUsn 65zmMdqwSGkRsd2yRPBaAhwb/tdATbym08jBz7RbyFnR9pbbMi6N903OyufurHL09uLR AOj9yP5SWs19eGu88cNXu1OOdxS0t51aSRhTlPlPOx4iUG3NyrIcnWAW+aJeaT4pU0tZ 0DUFCLDxmURTi97SSiqSsy4veySUum+mmAQJR8NkKhuuR1yoAWOw6Gjy3MjgGFDvIgnG ysPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@monom.org header.s=dkim header.b=aO0uZ3v9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=monom.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q15-20020a056402032f00b00461606e36dbsi7006423edw.131.2022.10.24.03.56.48; Mon, 24 Oct 2022 03:57:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@monom.org header.s=dkim header.b=aO0uZ3v9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=monom.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229773AbiJXKyk (ORCPT + 99 others); Mon, 24 Oct 2022 06:54:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229865AbiJXKyg (ORCPT ); Mon, 24 Oct 2022 06:54:36 -0400 Received: from mail.nearlyone.de (mail.nearlyone.de [46.163.114.145]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7378C65D5; Mon, 24 Oct 2022 03:54:31 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 4C9E561D80; Mon, 24 Oct 2022 12:44:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monom.org; s=dkim; t=1666608273; h=from:subject:date:message-id:to:cc:mime-version: content-transfer-encoding:in-reply-to:references; bh=BOoIY9WJFmBt1PSHlkPpnZQdqGiT4O4onH5CW/obUpI=; b=aO0uZ3v90bbg6mi3ImXFlkzhdHX/g0FQCi0pycvauxRpctXYkmPO+cOdvY0LbEcCXZLkUr N1k7H6QO3ImFEEKEkU5ghTkU6tbR/35k1X9QQV1e84adehoMye5oeTX9kxZoatKYbcSGNm D4teRsHUUeE7lzcA4nVfOSJwEisS1Qz3AqbJCYaF6Q43b6E2GoKjcAKa7V1/7/0DsSlxad moM8HgLNk2F63w+h80FgwXG66xSu15BqOxhktjyb7sqhBwJRh0bhvDo+skJfp4vPMKhQHS jsVBy+gfqOonqQGMg8wexjfk+tMuWi7380sqd13iw/QmD5V8OBf8yecVVUYhuQ== From: Daniel Wagner To: LKML , linux-rt-users , Steven Rostedt , Thomas Gleixner , Carsten Emde , John Kacur , Sebastian Andrzej Siewior , Tom Zanussi , Clark Williams , Pavel Machek Cc: Mike Galbraith , Daniel Wagner Subject: [PATCH RT 6/9] timers: Don't block on ->expiry_lock for TIMER_IRQSAFE timers Date: Mon, 24 Oct 2022 12:44:22 +0200 Message-Id: <20221024104425.16423-7-wagi@monom.org> In-Reply-To: <20221024104425.16423-1-wagi@monom.org> References: <20221024104425.16423-1-wagi@monom.org> MIME-Version: 1.0 X-Last-TLS-Session-Version: TLSv1.3 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747566234440585172?= X-GMAIL-MSGID: =?utf-8?q?1747566234440585172?= From: Sebastian Andrzej Siewior v4.19.255-rt114-rc1 stable review patch. If anyone has any objections, please let me know. ----------- Upstream commit c725dafc95f1b37027840aaeaa8b7e4e9cd20516 PREEMPT_RT does not spin and wait until a running timer completes its callback but instead it blocks on a sleeping lock to prevent a livelock in the case that the task waiting for the callback completion preempted the callback. This cannot be done for timers flagged with TIMER_IRQSAFE. These timers can be canceled from an interrupt disabled context even on RT kernels. The expiry callback of such timers is invoked with interrupts disabled so there is no need to use the expiry lock mechanism because obviously the callback cannot be preempted even on RT kernels. Do not use the timer_base::expiry_lock mechanism when waiting for a running callback to complete if the timer is flagged with TIMER_IRQSAFE. Also add a lockdep assertion for RT kernels to validate that the expiry lock mechanism is always invoked in preemptible context. Reported-by: Mike Galbraith Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20201103190937.hga67rqhvknki3tp@linutronix.de [bigeasy: The logic in v4.19 is slightly different but the outcome is the same as we must not sleep while waiting for the irqsafe timer to complete. The IRQSAFE timer can not be preempted. The "lockdep annotation" is not available and has been replaced with might_sleep()] Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Daniel Wagner --- kernel/time/timer.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 3e2c0bd03004..0a6d60b3e67c 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1272,6 +1272,9 @@ static int __del_timer_sync(struct timer_list *timer) if (ret >= 0) return ret; + if (READ_ONCE(timer->flags) & TIMER_IRQSAFE) + continue; + /* * When accessing the lock, timers of base are no longer expired * and so timer is no longer running. @@ -1336,6 +1339,12 @@ int del_timer_sync(struct timer_list *timer) * could lead to deadlock. */ WARN_ON(in_irq() && !(timer->flags & TIMER_IRQSAFE)); + /* + * Must be able to sleep on PREEMPT_RT because of the slowpath in + * __del_timer_sync(). + */ + if (IS_ENABLED(CONFIG_PREEMPT_RT) && !(timer->flags & TIMER_IRQSAFE)) + might_sleep(); return __del_timer_sync(timer); }