Received: by 2002:ab2:3350:0:b0:1f4:6588:b3a7 with SMTP id o16csp1712361lqe; Mon, 8 Apr 2024 19:06:41 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUR8Gs/eVHVwouFBlsOIv3UeEDCnZFZAy+v67KZsYI8kDai2V45P9E1qB0szoJ+I8sb2lqbmie0E+M0wpyS3fE6SueOxYV8R1ltrjctIw== X-Google-Smtp-Source: AGHT+IFQ5wntPR2+NDsseK4thwosfpRsLvFXTM59V6BId2Jg910jsT1Eaoc1zSASqf40F0DCWoS0 X-Received: by 2002:a05:6102:26cb:b0:47a:1931:92ec with SMTP id m11-20020a05610226cb00b0047a193192ecmr208844vss.8.1712628401299; Mon, 08 Apr 2024 19:06:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712628401; cv=pass; d=google.com; s=arc-20160816; b=PodLcoW9Mx7FdWvJqDXIqnRQ8Wknmh73FfJHzY9M5nOGBMCteYtLl8UOcxuM8Qu6Ma 4ipgXjmDyTrEk/SD/6ekVcnrlT21X+K1wbxzJUh8MZTdow73wKnO+X7lR2ivoUCgzD7M CalAnz5+qfG1Ifw5lfYYop+qYf8u3CNVp88gRQrmV3YOcSwLVYQQjN1ISn6EI1dpumsX lHbSPzBEm7zVYjeCnfQIkBOgdpsya+tIVMgjbSGJ6Ny92vl1XgXAKdA6De7VJEQrypB/ v3TaMt83VKEiAbi5U1O3LkjIdOdChcsFNK1MWjlSaNvCi62/qaKlbp2M9UUOJK4irvpw w3zw== 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:from; bh=4w8p4+YEadN74jeCgqG5oj0oFct9TmfDEBw7HbUk4Og=; fh=HDegUYitSpcn/t3lFk3IgR8jfd56x3aV1D2tuj6Y7Pk=; b=pMU5eIqC74ZtPOsIabvOKvb+vVEE5XtDdMDrJKdoqSl6bNeE4Dh9KKYtUBTUIdcRcU 3/ah9Or/rjdZu26JiZQLmImKY02DQ5NyGP5HTtmQLTKzStbxgTy441l+KgDgN3VIDZb/ Op0oSIUVpxHpPFJIpUeMIwunih6Dz9nEN4z5L2CYdyBf5qGCZIcgbx/tZdnBCv2Mt/Dt Q0N/BOGsZ/nMsaJNlMEZoRHDsJR8QjgvfxR9jzrsCi/qmAm1cwCcPqjyEkrBsAWgkniA gY3R0x2/6o6xXqgMkfuB6Gb7sb6rQtcicdDASyRrw9B0vo3w7foXpFd8HPpOT1sWhiUX hkKA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=h3c.com); spf=pass (google.com: domain of linux-kernel+bounces-136122-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-136122-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id s12-20020ad4438c000000b0069b22177e9csi2041934qvr.45.2024.04.08.19.06.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Apr 2024 19:06:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-136122-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=h3c.com); spf=pass (google.com: domain of linux-kernel+bounces-136122-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-136122-linux.lists.archive=gmail.com@vger.kernel.org" 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 0976C1C2396B for ; Tue, 9 Apr 2024 02:06:41 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2C29C4EB58; Tue, 9 Apr 2024 02:06:36 +0000 (UTC) Received: from h3cspam02-ex.h3c.com (smtp.h3c.com [60.191.123.50]) (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 0B58F4F881; Tue, 9 Apr 2024 02:06:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=60.191.123.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712628395; cv=none; b=UZGVs9r9SJEnKYSL08DIiSUh1dRifd9f1cOHdl947cG58IUM0g1sciypdhKW0sdSANy+ozigEAD4snmI5GO+5sb9/mC1RgFRoLJ+jDOc+EIigS+/X4jIV6wR4+CtlserTZWHOJuXqNnYnCKM8CzEvkek0HeknwnmMBY5lHfijEY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712628395; c=relaxed/simple; bh=N1zfWbtGo+CYFCJzwpSzSJlqNbgg2Q++/6k0vPNgPD0=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Lg/jQkaAlLAKqiEAyLZeUo24CPEhhxgbPrw+eN26g5c7+pEjWo6Xv0nNFedAgwG13whZReBT+hFOEPlB6fvT+NXtAzfzZcfGSlCmX4o7L9U1BH9krgUUjAp2z0siTaOjMqmQZxOBbSBGKzFhmneluLx0YG4FNH8MElWnHhtBHRw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=h3c.com; spf=pass smtp.mailfrom=h3c.com; arc=none smtp.client-ip=60.191.123.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=h3c.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=h3c.com Received: from mail.maildlp.com ([172.25.15.154]) by h3cspam02-ex.h3c.com with ESMTP id 43923xpo075028; Tue, 9 Apr 2024 10:03:59 +0800 (GMT-8) (envelope-from liu.yeC@h3c.com) Received: from DAG6EX02-IMDC.srv.huawei-3com.com (unknown [10.62.14.11]) by mail.maildlp.com (Postfix) with ESMTP id D12482004C43; Tue, 9 Apr 2024 10:06:05 +0800 (CST) Received: from localhost.localdomain (10.114.186.34) by DAG6EX02-IMDC.srv.huawei-3com.com (10.62.14.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1258.27; Tue, 9 Apr 2024 10:03:58 +0800 From: To: , CC: , , , , , , , Subject: [PATCH V9] kdb: Fix the deadlock issue in KDB debugging. Date: Tue, 9 Apr 2024 10:03:26 +0800 Message-ID: <20240409020326.2125332-1-liu.yec@h3c.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BJSMTP01-EX.srv.huawei-3com.com (10.63.20.132) To DAG6EX02-IMDC.srv.huawei-3com.com (10.62.14.11) X-DNSRBL: X-SPAM-SOURCE-CHECK: pass X-MAIL:h3cspam02-ex.h3c.com 43923xpo075028 From: LiuYe Currently, if CONFIG_KDB_KEYBOARD is enabled, then kgdboc will attempt to use schedule_work() to provoke a keyboard reset when transitioning out of the debugger and back to normal operation. This can cause deadlock because schedule_work() is not NMI-safe. The stack trace below shows an example of the problem. In this case the master cpu is not running from NMI but it has parked the slave CPUs using an NMI and the parked CPUs is holding spinlocks needed by schedule_work(). Example: BUG: spinlock lockup suspected on CPU#0. owner_cpu: 1 CPU1: Call Trace: __schedule schedule schedule_hrtimeout_range_clock mutex_unlock ep_scan_ready_list schedule_hrtimeout_range ep_poll wake_up_q SyS_epoll_wait entry_SYSCALL_64_fastpath CPU0: Call Trace: dump_stack spin_dump do_raw_spin_lock _raw_spin_lock try_to_wake_up wake_up_process insert_work __queue_work queue_work_on kgdboc_post_exp_handler kgdb_cpu_enter kgdb_handle_exception __kgdb_notify kgdb_notify notifier_call_chain notify_die do_int3 int3 We fix the problem by using irq_work to call schedule_work() instead of calling it directly. This is because we cannot resynchronize the keyboard state from the hardirq context provided by irq_work. This must be done from the task context in order to call the input subsystem. Therefore, we have to defer the work twice. First, safely switch from the debug trap context (similar to NMI) to the hardirq, and then switch from the hardirq to the system work queue. Signed-off-by: LiuYe Co-developed-by: Daniel Thompson Signed-off-by: Daniel Thompson --- V8 -> V9: Modify call trace format and move irq_work.h before module.h V7 -> V8: Update the description information and comments in the code. : Submit this patch based on version linux-6.9-rc2. V6 -> V7: Add comments in the code. V5 -> V6: Replace with a more professional and accurate answer. V4 -> V5: Answer why schedule another work in the irq_work and not do the job directly. V3 -> V4: Add changelogs V2 -> V3: Add description information V1 -> V2: using irq_work to solve this properly. --- --- drivers/tty/serial/kgdboc.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c index 7ce7bb164..32410fec7 100644 --- a/drivers/tty/serial/kgdboc.c +++ b/drivers/tty/serial/kgdboc.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -82,6 +83,19 @@ static struct input_handler kgdboc_reset_handler = { static DEFINE_MUTEX(kgdboc_reset_mutex); +/* + * This code ensures that the keyboard state, which is changed during kdb + * execution, is resynchronized when we leave the debug trap. The resync + * logic calls into the input subsystem to force a reset. The calls into + * the input subsystem must be executed from normal task context. + * + * We need to trigger the resync from the debug trap, which executes in an + * NMI (or similar) context. To make it safe to call into the input + * subsystem we end up having use two deferred execution techniques. + * Firstly, we use irq_work, which is NMI-safe, to provoke a callback from + * hardirq context. Then, from the hardirq callback we use the system + * workqueue to provoke the callback that actually performs the resync. + */ static void kgdboc_restore_input_helper(struct work_struct *dummy) { /* @@ -99,10 +113,17 @@ static void kgdboc_restore_input_helper(struct work_struct *dummy) static DECLARE_WORK(kgdboc_restore_input_work, kgdboc_restore_input_helper); +static void kgdboc_queue_restore_input_helper(struct irq_work *unused) +{ + schedule_work(&kgdboc_restore_input_work); +} + +static DEFINE_IRQ_WORK(kgdboc_restore_input_irq_work, kgdboc_queue_restore_input_helper); + static void kgdboc_restore_input(void) { if (likely(system_state == SYSTEM_RUNNING)) - schedule_work(&kgdboc_restore_input_work); + irq_work_queue(&kgdboc_restore_input_irq_work); } static int kgdboc_register_kbd(char **cptr) @@ -133,6 +154,7 @@ static void kgdboc_unregister_kbd(void) i--; } } + irq_work_sync(&kgdboc_restore_input_irq_work); flush_work(&kgdboc_restore_input_work); } #else /* ! CONFIG_KDB_KEYBOARD */ -- 2.25.1