From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67C4FC43387 for ; Fri, 28 Dec 2018 12:18:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 35CF320675 for ; Fri, 28 Dec 2018 12:18:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1545999538; bh=ShAB/C/RKQjqa7v47RkxZPS2eTI397LlYvnDQoJiBSo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=QREvgVqjpTiEEH8HMTbwjVxxrNHUAR5tjzsrXH3ZUrUd+ylncmndu7ymAU7OTKdqS m8yKRgdDjZY+Nb8G58Z/pkFipGJ37qfXu5awvryNOjHtzXjSRTe5eB8pYiBHmStUo4 Ne3uMMryJBL6kLM2+h/id2m8V049d1GfjdLbbfsI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733014AbeL1MSp (ORCPT ); Fri, 28 Dec 2018 07:18:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:36836 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733017AbeL1MRp (ORCPT ); Fri, 28 Dec 2018 07:17:45 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 277B820675; Fri, 28 Dec 2018 12:17:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1545999464; bh=ShAB/C/RKQjqa7v47RkxZPS2eTI397LlYvnDQoJiBSo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pJJrjvErXLhg2V8m6nwAf95S7znzlx5ekn7V5PRgEgMDqYFXUQtQZ0le6pP2XgBZp 0CUFj2qP4xKfTkEQ2d8He5+elaw4Hgay7MOAh8/X6eBzWoF7a/yv5Tc3ohPgILvvNa Xwx6nJ68H9r0B6pxWAj8THgTy161LnBxG2OnbjRE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Steven Rostedt , Daniel Wang , Peter Zijlstra , Andrew Morton , Linus Torvalds , Alan Cox , Jiri Slaby , Peter Feiner , linux-serial@vger.kernel.org, Sergey Senozhatsky , Sergey Senozhatsky , Petr Mladek Subject: [PATCH 4.9 20/22] panic: avoid deadlocks in re-entrant console drivers Date: Fri, 28 Dec 2018 12:52:57 +0100 Message-Id: <20181228113127.547233295@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20181228113126.144310132@linuxfoundation.org> References: <20181228113126.144310132@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sergey Senozhatsky commit c7c3f05e341a9a2bd1a92993d4f996cfd6e7348e upstream. >>From printk()/serial console point of view panic() is special, because it may force CPU to re-enter printk() or/and serial console driver. Therefore, some of serial consoles drivers are re-entrant. E.g. 8250: serial8250_console_write() { if (port->sysrq) locked = 0; else if (oops_in_progress) locked = spin_trylock_irqsave(&port->lock, flags); else spin_lock_irqsave(&port->lock, flags); ... } panic() does set oops_in_progress via bust_spinlocks(1), so in theory we should be able to re-enter serial console driver from panic(): CPU0 uart_console_write() serial8250_console_write() // if (oops_in_progress) // spin_trylock_irqsave() call_console_drivers() console_unlock() console_flush_on_panic() bust_spinlocks(1) // oops_in_progress++ panic() spin_lock_irqsave(&port->lock, flags) // spin_lock_irqsave() serial8250_console_write() call_console_drivers() console_unlock() printk() ... However, this does not happen and we deadlock in serial console on port->lock spinlock. And the problem is that console_flush_on_panic() called after bust_spinlocks(0): void panic(const char *fmt, ...) { bust_spinlocks(1); ... bust_spinlocks(0); console_flush_on_panic(); ... } bust_spinlocks(0) decrements oops_in_progress, so oops_in_progress can go back to zero. Thus even re-entrant console drivers will simply spin on port->lock spinlock. Given that port->lock may already be locked either by a stopped CPU, or by the very same CPU we execute panic() on (for instance, NMI panic() on printing CPU) the system deadlocks and does not reboot. Fix this by removing bust_spinlocks(0), so oops_in_progress is always set in panic() now and, thus, re-entrant console drivers will trylock the port->lock instead of spinning on it forever, when we call them from console_flush_on_panic(). Link: http://lkml.kernel.org/r/20181025101036.6823-1-sergey.senozhatsky@gmail.com Cc: Steven Rostedt Cc: Daniel Wang Cc: Peter Zijlstra Cc: Andrew Morton Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: Alan Cox Cc: Jiri Slaby Cc: Peter Feiner Cc: linux-serial@vger.kernel.org Cc: Sergey Senozhatsky Cc: stable@vger.kernel.org Signed-off-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Signed-off-by: Greg Kroah-Hartman --- kernel/panic.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/kernel/panic.c +++ b/kernel/panic.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include #include @@ -228,7 +229,10 @@ void panic(const char *fmt, ...) if (_crash_kexec_post_notifiers) __crash_kexec(NULL); - bust_spinlocks(0); +#ifdef CONFIG_VT + unblank_screen(); +#endif + console_unblank(); /* * We may have ended up stopping the CPU holding the lock (in