Message ID | 20240218185726.1994771-27-john.ogness@linutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-70520-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp913114dyc; Sun, 18 Feb 2024 11:02:31 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVhqp6mpLegzwHw6Xik2x5q9hqaV2g0n49IRPmRnRkicX5x3QTnUfnAReB17W2EyqM4ZVONs3NnRa7nrw8nnvfxUTeu9A== X-Google-Smtp-Source: AGHT+IGfv9sW/UNivJ+eOruT7EVmgqJn3lbYMtczkv/iY6yUJjAOM1C1MyIzHpE2FHAlExVTQS/m X-Received: by 2002:a0c:e38e:0:b0:68f:3ecd:840b with SMTP id a14-20020a0ce38e000000b0068f3ecd840bmr7249866qvl.23.1708282951362; Sun, 18 Feb 2024 11:02:31 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708282951; cv=pass; d=google.com; s=arc-20160816; b=Jh3H+IdANlGgfHbNDPRKKFR+6/9HQ4A5avjmBNL0VF/DSbEQ8fSx2FUFxWFON4iQIr zRFVFKtzVmtbQ4T00R7gc3t04669BVK/s98p7p5tsrcQSl2Z+e12ADEU9808t+V2Q1M7 JWf0qzm52P1Msbqz819b2HN/ncdDsNC164HkLc1yIcH69FsTvLkXzwQfI6eLi/IXS0Y1 YBc01yYftqRMzi+I1HwdvfSegmai0VWIUi8QxSgYpe+OVzTKtd1EunAZWHb0NcmpUwmy zKZHwJWHQEuvfvswIoilvN0ueCBxgPavZDMmsiB85WHSSB92BOLMWFq3G6Jmu3Ex6Hpo GMOQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:dkim-signature:dkim-signature:from; bh=0lPBki68mVE7PCw7W4jrgk0lCFhQvBUvfvhYmuWjIeY=; fh=baLZk4VyAx6eqLoRrdDbCsrkF3EpnrHuPZYH860mNkA=; b=s8QHATmrJvnyCDQQVyp/+LC6BOI86kiP5TJn0JyrcYAGKoyYtQus2/3MljfVR/1Ute BxA8h52/79wnefjoQiIzIUIMp1Kgg/qxHJPAXHUHPdyR4MyaixkMLx2hiZFW7u8qZV1O Kk8E9rMNF03Y6qTRXGHNAIMJtRR+b6H8CjROx7WKNpMO0lZj/mLU0efOnsxw49QggeO4 fAAdK5hIWnejyvBwQQuWDooGzUWehNFXoCoyXlbdAhvXSaFuNInGp9dgf+D/CYzhb5+H dtVhESDnT548KD0xvcunFGyVvlOaz2R15AQ3cOQ9auF0OolfsMB+wWK1l4K8D3+ogTSC oxeg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=16iOEDIe; 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-70520-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-70520-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id a6-20020ad45c46000000b0068f6bcd2108si951114qva.172.2024.02.18.11.02.31 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Feb 2024 11:02:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-70520-ouuuleilei=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=16iOEDIe; 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-70520-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-70520-ouuuleilei=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 29BCF1C20327 for <ouuuleilei@gmail.com>; Sun, 18 Feb 2024 19:02:31 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7640076C92; Sun, 18 Feb 2024 18:58:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="16iOEDIe"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="iHynVoQd" 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 1473B745D7 for <linux-kernel@vger.kernel.org>; Sun, 18 Feb 2024 18:57:59 +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=1708282680; cv=none; b=WFMpaxFt1JabkoBdfexDfTXiArKZQHl59pkHzwhBZJuB96EYGwDNFgcJRLXgxZjsWiNLHP9+goifnC71nJegZ36nMjSO0tEaKIwbmOOprF6poOx5iUWHRU2pg6fMJGPil3hXZLwPB0EKKh09aqFsqARmjIpj+nV/qL6BrViKzbo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708282680; c=relaxed/simple; bh=OagJvzD8CITXGM05wrJdLFbnK8R3FnQZlKkDZ7ArXY0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=tl+0ejlRmOjX/bpbMvekIMokL61zLSwCbpniIimvTW1ZpBQOai65e4a3Gu35+4SJZLoJjEVOOAiG7OHIHvoV08BhGtJGsr/2hLL7DuC+4+qLZZ6xCMh6Qmjo9PvWk0tES2fUVRTeNtv9IwIUrmSrrgCnyZbjYtwk9SVWJ0OIwwg= 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=16iOEDIe; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=iHynVoQd; 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 From: John Ogness <john.ogness@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1708282677; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0lPBki68mVE7PCw7W4jrgk0lCFhQvBUvfvhYmuWjIeY=; b=16iOEDIef9bfi8hm5YKwdXMo0KA3BGTQYHPoFj515WihwX2bbE+vwFUVFaE5Du1RD7Y5W2 RPwwTqoL6dA2GLDE1UyNa3DkBrV1y2AT9dUZM10gr2IQ6QTaEIKAOA9R1vYmwRH7v5i/LW hBXv3pVUwSCOxaDFMsCTnMSJrRE+ezEIBTczVi/gszaGneoixpcpGkWyW361N2KLds8b9E T1VuopLugS5WomPG7SWkvrlSVJ/kiI4l4ux3mRbLXZo7iqt/NUSd2lWWwWiVtaTjb6MluE tD99NTIR2S1ylI9Jywrwdx9LaxGtztzqu6YDkz54DL0f/6KRyFckh8LM/JeqyQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1708282677; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0lPBki68mVE7PCw7W4jrgk0lCFhQvBUvfvhYmuWjIeY=; b=iHynVoQdMqQvQ5UY9zDTHbYAg0fKIK48nfTCXAbx3zmnVvmiXaZF3CIrbiq4IENzpgm/Yp wGM0dChF7tn7OlDQ== To: Petr Mladek <pmladek@suse.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org>, Steven Rostedt <rostedt@goodmis.org>, Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>, Waiman Long <longman@redhat.com>, Boqun Feng <boqun.feng@gmail.com> Subject: [PATCH printk v2 26/26] lockdep: Mark emergency section in lockdep splats Date: Sun, 18 Feb 2024 20:03:26 +0106 Message-Id: <20240218185726.1994771-27-john.ogness@linutronix.de> In-Reply-To: <20240218185726.1994771-1-john.ogness@linutronix.de> References: <20240218185726.1994771-1-john.ogness@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791264504175917283 X-GMAIL-MSGID: 1791264504175917283 |
Series |
wire up write_atomic() printing
|
|
Commit Message
John Ogness
Feb. 18, 2024, 6:57 p.m. UTC
Mark an emergency section within print_usage_bug(), where
lockdep bugs are printed. In this section, the CPU will not
perform console output for the printk() calls. Instead, a
flushing of the console output is triggered when exiting
the emergency section.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
kernel/locking/lockdep.c | 5 +++++
1 file changed, 5 insertions(+)
Comments
On 2/18/24 13:57, John Ogness wrote: > Mark an emergency section within print_usage_bug(), where > lockdep bugs are printed. In this section, the CPU will not > perform console output for the printk() calls. Instead, a > flushing of the console output is triggered when exiting > the emergency section. > > Signed-off-by: John Ogness <john.ogness@linutronix.de> > --- > kernel/locking/lockdep.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index e85b5ad3e206..00465373d358 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -56,6 +56,7 @@ > #include <linux/kprobes.h> > #include <linux/lockdep.h> > #include <linux/context_tracking.h> > +#include <linux/console.h> > > #include <asm/sections.h> > > @@ -3970,6 +3971,8 @@ print_usage_bug(struct task_struct *curr, struct held_lock *this, > if (!debug_locks_off() || debug_locks_silent) > return; > > + nbcon_cpu_emergency_enter(); > + > pr_warn("\n"); > pr_warn("================================\n"); > pr_warn("WARNING: inconsistent lock state\n"); > @@ -3998,6 +4001,8 @@ print_usage_bug(struct task_struct *curr, struct held_lock *this, > > pr_warn("\nstack backtrace:\n"); > dump_stack(); > + > + nbcon_cpu_emergency_exit(); > } > > /* lockdep.c has multiple functions that print stuff to the console, like - print_circular_bug_header() - print_bad_irq_dependency() - print_deadlock_bug() - print_collision() - print_usage_bug() - print_irq_inversion_bug() - print_lock_invalid_wait_context() - print_lock_nested_lock_not_held() - print_unlock_imbalance_bug() - print_lock_contention_bug() - print_freed_lock_bug() - print_held_locks_bug() - lockdep_rcu_suspicious() So what is special about print_usage_bug() that it needs this emergency treatment but not the other ones? Cheers, Longman
On 2024-02-18, Waiman Long <longman@redhat.com> wrote: > On 2/18/24 13:57, John Ogness wrote: > lockdep.c has multiple functions that print stuff to the console, like > > - print_circular_bug_header() > - print_bad_irq_dependency() > - print_deadlock_bug() > - print_collision() > - print_usage_bug() > - print_irq_inversion_bug() > - print_lock_invalid_wait_context() > - print_lock_nested_lock_not_held() > - print_unlock_imbalance_bug() > - print_lock_contention_bug() > - print_freed_lock_bug() > - print_held_locks_bug() > - lockdep_rcu_suspicious() > > So what is special about print_usage_bug() that it needs this > emergency treatment but not the other ones? I do not expect to be able to identify all "emergency printing" paths in the kernel from the beginning. This series initially marks some sections that are IMHO interesting for the feature. As you are implying, for lockdep probably all printing should be considered emergency. Is it preferred to place the markers outside the high-level print functions, for example: diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 00465373d358..7a4e4f4a9156 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -2182,10 +2182,12 @@ check_noncircular(struct held_lock *src, struct held_lock *target, *trace = save_trace(); } + nbcon_cpu_emergency_enter(); if (src->class_idx == target->class_idx) print_deadlock_bug(current, src, target); else print_circular_bug(&src_entry, target_entry, src, target); + nbcon_cpu_emergency_exit(); } return ret; Or is it preferred to put them directly around the various pr_warn() blocks (as the patch in this series is doing)? John Ogness
On 2/19/24 06:11, John Ogness wrote: > On 2024-02-18, Waiman Long <longman@redhat.com> wrote: >> On 2/18/24 13:57, John Ogness wrote: >> lockdep.c has multiple functions that print stuff to the console, like >> >> - print_circular_bug_header() >> - print_bad_irq_dependency() >> - print_deadlock_bug() >> - print_collision() >> - print_usage_bug() >> - print_irq_inversion_bug() >> - print_lock_invalid_wait_context() >> - print_lock_nested_lock_not_held() >> - print_unlock_imbalance_bug() >> - print_lock_contention_bug() >> - print_freed_lock_bug() >> - print_held_locks_bug() >> - lockdep_rcu_suspicious() >> >> So what is special about print_usage_bug() that it needs this >> emergency treatment but not the other ones? > I do not expect to be able to identify all "emergency printing" paths in > the kernel from the beginning. This series initially marks some sections > that are IMHO interesting for the feature. That is what I like to see in the changelog. I am aware that this patch is probably not complete, but you need to set the right expectation that similar changes will have to be done elsewhere in lockdep to complete the change. We can make the other necessary changes after this patch series have been merged. It also helps if you can document what undesirable thing may happen if printk() is called without setting the emergency mode. > > > As you are implying, for lockdep probably all printing should be > considered emergency. Is it preferred to place the markers outside the > high-level print functions, for example: > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index 00465373d358..7a4e4f4a9156 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -2182,10 +2182,12 @@ check_noncircular(struct held_lock *src, struct held_lock *target, > *trace = save_trace(); > } > > + nbcon_cpu_emergency_enter(); > if (src->class_idx == target->class_idx) > print_deadlock_bug(current, src, target); > else > print_circular_bug(&src_entry, target_entry, src, target); > + nbcon_cpu_emergency_exit(); > } > > return ret; > > Or is it preferred to put them directly around the various pr_warn() > blocks (as the patch in this series is doing)? There are pros and cons for both. It will depend on how expensive is the nbcon_cpu_emergency_{enter|exit}() call as printing won't happen if lockdep is turned off somehow. Since lockdep is for debugging and efficiency isn't that important, putting the emergency enter/exit markers outside the high level print functions will make it a bit easier to read. My 2 cents. Cheers, Longman > > John Ogness >
On Sun 2024-02-18 20:03:26, John Ogness wrote: > Mark an emergency section within print_usage_bug(), where > lockdep bugs are printed. In this section, the CPU will not > perform console output for the printk() calls. Instead, a > flushing of the console output is triggered when exiting > the emergency section. > > Signed-off-by: John Ogness <john.ogness@linutronix.de> The patch looks fine from my POV. Well, I expect that you will send another version addressing Waiman's concerns. Best Regards, Petr
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index e85b5ad3e206..00465373d358 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -56,6 +56,7 @@ #include <linux/kprobes.h> #include <linux/lockdep.h> #include <linux/context_tracking.h> +#include <linux/console.h> #include <asm/sections.h> @@ -3970,6 +3971,8 @@ print_usage_bug(struct task_struct *curr, struct held_lock *this, if (!debug_locks_off() || debug_locks_silent) return; + nbcon_cpu_emergency_enter(); + pr_warn("\n"); pr_warn("================================\n"); pr_warn("WARNING: inconsistent lock state\n"); @@ -3998,6 +4001,8 @@ print_usage_bug(struct task_struct *curr, struct held_lock *this, pr_warn("\nstack backtrace:\n"); dump_stack(); + + nbcon_cpu_emergency_exit(); } /*