Received: by 2002:a17:90a:9307:0:0:0:0 with SMTP id p7csp5142658pjo; Tue, 11 Feb 2020 04:48:32 -0800 (PST) X-Google-Smtp-Source: APXvYqxfoRb3QgSToIgSUY70djeOrmJGaGokL6lmWyUszhKHUzhJp9tcB880Fu47eL8vYhNNbdWO X-Received: by 2002:a05:6830:c9:: with SMTP id x9mr5078986oto.345.1581425312385; Tue, 11 Feb 2020 04:48:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581425312; cv=none; d=google.com; s=arc-20160816; b=WdLUvLBFMOIOdYtpPPgpiDGsorhNCgJQHoS9/MGRTxvWZKtNJEQaAaGEYezy9XIkJl hDT4ARLr4FZK0Edc5s10j6WiEiFel5Zh8vwN68CQbuEkc7UbzkXs8nSy+sjeYBQZL8Ra 8IL2hT+69SgX43rCst4taP42Tz263pg2/3tB4BkYFtodfOtdyFxcAq4Dr1MYSex7GI6E nvKEa1nFG0zZ1bH8SEuRjQANn6cN0PGp6RsRDddYU7xTQgtnUfkT3sbiX+rCyZKAtKci PYjgG2ajhTTnGye55DM6NIn6Ee3bGkKMAMLpaIYJn0HofOee0woPgX5KprSxLK/CCt7C oRVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=q176fyOTHeCFZPwNhYi62BgfveAU8A5u2bcO5LHzBwk=; b=ROPdUjOsb0bsD14QZ36FvBGhjXNXvcZtUTsz4YnLDk0m13DZhcZft4x4iUCoCPmiub GnvsSjrdAOwxPR6J4TPL77eIQi1yxtQzrZQadgnHJjloulTjiq8IxNA9UagIs/kI0hFd 7LoQ6pAVyCkPN++0/J4qiLroOkt5nDmp9gVECht3ttq1KCFWK5d3aVvn8qTwSnYH9xIt 8KdLiImyiPG9VFY78tCICCm65Gp4R2WDc+QLWrzem/MV/2C3g+wOJlNvTo9jbweAkIjz RQ5KCHSGQ4FWJcQBYyKs+I7jxnW0Yzj/Ia0/YxJQ5qa6vTRmkTLGsYzNW2E/rKhSZO+h mp6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=BAngbQdL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y73si1588054oia.246.2020.02.11.04.48.20; Tue, 11 Feb 2020 04:48:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=BAngbQdL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728823AbgBKMgJ (ORCPT + 99 others); Tue, 11 Feb 2020 07:36:09 -0500 Received: from forwardcorp1o.mail.yandex.net ([95.108.205.193]:45284 "EHLO forwardcorp1o.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728569AbgBKMgI (ORCPT ); Tue, 11 Feb 2020 07:36:08 -0500 Received: from mxbackcorp1g.mail.yandex.net (mxbackcorp1g.mail.yandex.net [IPv6:2a02:6b8:0:1402::301]) by forwardcorp1o.mail.yandex.net (Yandex) with ESMTP id 95ECF2E1571; Tue, 11 Feb 2020 15:36:05 +0300 (MSK) Received: from iva4-7c3d9abce76c.qloud-c.yandex.net (iva4-7c3d9abce76c.qloud-c.yandex.net [2a02:6b8:c0c:4e8e:0:640:7c3d:9abc]) by mxbackcorp1g.mail.yandex.net (mxbackcorp/Yandex) with ESMTP id 3X5JnAeaY3-a2SSqjcG; Tue, 11 Feb 2020 15:36:05 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1581424565; bh=q176fyOTHeCFZPwNhYi62BgfveAU8A5u2bcO5LHzBwk=; h=In-Reply-To:Message-ID:From:Date:References:To:Subject:Cc; b=BAngbQdLiuYRw5IQMumFj5q/9+g6/v5o4Jcc3xp1GJdXUa8P59HI76GcHQzSoeH8X at+V/KvDEb88lcyZTA8G4MsgqVWg0wqQS/hFnxGa7Oo7k1V0VClVA/oEgWy6CofH5v QnDPf5t7FOL6rJXVrOvnNw9PalshFBQ/BsmsxjNg= Authentication-Results: mxbackcorp1g.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from dynamic-red.dhcp.yndx.net (dynamic-red.dhcp.yndx.net [2a02:6b8:0:40c:8448:fbcc:1dac:c863]) by iva4-7c3d9abce76c.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id mevy9sDSpZ-a2WObhD5; Tue, 11 Feb 2020 15:36:02 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: [PATCH] kernel/watchdog: flush all printk nmi buffers when hardlockup detected To: Kirill Tkhai , Petr Mladek , Peter Zijlstra , linux-kernel@vger.kernel.org, Steven Rostedt , Sergey Senozhatsky , Andrew Morton Cc: Dmitry Monakhov References: <158132813726.1980.17382047082627699898.stgit@buzz> From: Konstantin Khlebnikov Message-ID: Date: Tue, 11 Feb 2020 15:36:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/02/2020 11.14, Kirill Tkhai wrote: > Hi, Konstantin, > > On 10.02.2020 12:48, Konstantin Khlebnikov wrote: >> In NMI context printk() could save messages into per-cpu buffers and >> schedule flush by irq_work when IRQ are unblocked. This means message >> about hardlockup appears in kernel log only when/if lockup is gone. >> >> Comment in irq_work_queue_on() states that remote IPI aren't NMI safe >> thus printk() cannot schedule flush work to another cpu. >> >> This patch adds simple atomic counter of detected hardlockups and >> flushes all per-cpu printk buffers in context softlockup watchdog >> at any other cpu when it sees changes of this counter. >> >> Signed-off-by: Konstantin Khlebnikov >> --- >> include/linux/nmi.h | 1 + >> kernel/watchdog.c | 22 ++++++++++++++++++++++ >> kernel/watchdog_hld.c | 1 + >> 3 files changed, 24 insertions(+) >> >> diff --git a/include/linux/nmi.h b/include/linux/nmi.h >> index 9003e29cde46..8406df72ae5a 100644 >> --- a/include/linux/nmi.h >> +++ b/include/linux/nmi.h >> @@ -84,6 +84,7 @@ static inline void reset_hung_task_detector(void) { } >> #if defined(CONFIG_HARDLOCKUP_DETECTOR) >> extern void hardlockup_detector_disable(void); >> extern unsigned int hardlockup_panic; >> +extern atomic_t hardlockup_detected; >> #else >> static inline void hardlockup_detector_disable(void) {} >> #endif >> diff --git a/kernel/watchdog.c b/kernel/watchdog.c >> index b6b1f54a7837..9f5c68fababe 100644 >> --- a/kernel/watchdog.c >> +++ b/kernel/watchdog.c >> @@ -92,6 +92,26 @@ static int __init hardlockup_all_cpu_backtrace_setup(char *str) >> } >> __setup("hardlockup_all_cpu_backtrace=", hardlockup_all_cpu_backtrace_setup); >> # endif /* CONFIG_SMP */ >> + >> +atomic_t hardlockup_detected = ATOMIC_INIT(0); >> + >> +static inline void flush_hardlockup_messages(void) >> +{ >> + static atomic_t flushed = ATOMIC_INIT(0); >> + >> + /* flush messages from hard lockup detector */ >> + if (atomic_read(&hardlockup_detected) != atomic_read(&flushed)) { >> + atomic_set(&flushed, atomic_read(&hardlockup_detected)); >> + printk_safe_flush(); >> + } >> +} > > Do we really need two variables here? They may come into two different > cache lines, and there will be double cache pollution just because of > this simple check. Why not the below? I don't think anybody could notice read-only access to second variable. This executes once in several seconds. Watchdogs already use same pattern (monotonic counter + snapshot) in couple places. So code looks more clean in this way. > > if (atomic_read(&hardlockup_detected)) { > atomic_set(&hardlockup_detected, 0); > printk_safe_flush(); > } > > Or even, since atomic is not needed here, as it does not give any ordering guarantees. > static inline void flush_hardlockup_messages(void) > { > if (READ_ONCE(&hardlockup_detected)) { > WRITE_ONCE(&hardlockup_detected, 0); > printk_safe_flush(); > } > } > > watchdog_timer_fn() > { > ... > WRITE_ONCE(&hardlockup_detected, 1); > ... > } > > Kirill >