Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp320017ybg; Wed, 3 Jun 2020 01:28:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz88rHXzz2h4NKZfXPT/TYoL9ZT+xs8Oh9k9T9uICtHj3i/oS7gh6F+IJOhREqp/ecsXMO+ X-Received: by 2002:a05:6402:1481:: with SMTP id e1mr28240888edv.113.1591172886997; Wed, 03 Jun 2020 01:28:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591172886; cv=none; d=google.com; s=arc-20160816; b=FTVmD1wzB0keNYjXDmJRyQYUOUWClKvK+YydfTL9WZfqT3EveyG5kRPWV9XT5Olp06 Cz7G/EjlK4sRgb/Yk7iFKN1t/XKSXmTTbrr4aso2nrQjKtfFYTV3Egd2MgJKqzZjRPmO Aoy/+yUyx4GSNOGTvaT3MoSNfWgbrBpb1jreXowMEruprrod10D6ozn4/r0/97nyW67J w7Gfjm954nUSOXfr7UBSiTuQBOaYH7grJuxIH3zo9DGpHDF90Sm2Dyf+y1VlW8ebrjx8 U1RHE5m5mMZPY9ErFY2Ns1IU24GMMLTI+a3SzAO2dpt6yOS/Xv19suGrfQTnIDDyJhME AYpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=cq3ukgG4sL7CE6kkLJ84KXg2j91fMR/Sj+cvcaSKhPU=; b=dejlU3X8FIvi3m0DzmC/pcYoKtJIutFSkcWqJlMegRz+MWRn/rHuqpUXK+8+TGYPNX tN694MIfeXyMtvEWiZVbT5jUBqJGDSQZ2TtW7KuSaMvLtk4NEhVmJcQQS1ensiq1E4Cq U/gZGWG/8BrmuYGo7ZZn5oglBz3vqwusTTfdpmyWMdnS+fP+xImoPaQ9ET8BeAuy3YEA ydzO2fMPLkix9ZSH6lMwuq+uo6fI0cXZg9UrNQr26+s1kooSE5/PzrnKetHi6umrI4/L zta1d5JFh4pAjElX0otAr9uL8MwFiQw0L6IvCq0QCRMwMM5TiMHY6DofgcEh7VyaR7bU qW7w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk10si707604edb.73.2020.06.03.01.27.44; Wed, 03 Jun 2020 01:28:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726383AbgFCIZP (ORCPT + 99 others); Wed, 3 Jun 2020 04:25:15 -0400 Received: from mx2.suse.de ([195.135.220.15]:35930 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725854AbgFCIZP (ORCPT ); Wed, 3 Jun 2020 04:25:15 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 63D3AB13B; Wed, 3 Jun 2020 08:25:15 +0000 (UTC) Date: Wed, 3 Jun 2020 10:25:04 +0200 From: Petr Mladek To: Sumit Garg Cc: daniel.thompson@linaro.org, kgdb-bugreport@lists.sourceforge.net, jason.wessel@windriver.com, dianders@chromium.org, sergey.senozhatsky@gmail.com, gregkh@linuxfoundation.org, jslaby@suse.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 4/4] kdb: Switch to use safer dbg_io_ops over console APIs Message-ID: <20200603082503.GD14855@linux-b0ei> References: <1591168935-6382-1-git-send-email-sumit.garg@linaro.org> <1591168935-6382-5-git-send-email-sumit.garg@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1591168935-6382-5-git-send-email-sumit.garg@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2020-06-03 12:52:15, Sumit Garg wrote: > In kgdb context, calling console handlers aren't safe due to locks used > in those handlers which could in turn lead to a deadlock. Although, using > oops_in_progress increases the chance to bypass locks in most console > handlers but it might not be sufficient enough in case a console uses > more locks (VT/TTY is good example). > > Currently when a driver provides both polling I/O and a console then kdb > will output using the console. We can increase robustness by using the > currently active polling I/O driver (which should be lockless) instead > of the corresponding console. For several common cases (e.g. an > embedded system with a single serial port that is used both for console > output and debugger I/O) this will result in no console handler being > used. > > In order to achieve this we need to reverse the order of preference to > use dbg_io_ops (uses polling I/O mode) over console APIs. So we just > store "struct console" that represents debugger I/O in dbg_io_ops and > while emitting kdb messages, skip console that matches dbg_io_ops > console in order to avoid duplicate messages. After this change, > "is_console" param becomes redundant and hence removed. > > diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c > index 4139698..6e182aa 100644 > --- a/drivers/tty/serial/kgdboc.c > +++ b/drivers/tty/serial/kgdboc.c > @@ -558,6 +557,7 @@ static int __init kgdboc_earlycon_init(char *opt) > } > > earlycon = con; > + kgdboc_earlycon_io_ops.cons = con; > pr_info("Going to register kgdb with earlycon '%s'\n", con->name); > if (kgdb_register_io_module(&kgdboc_earlycon_io_ops) != 0) { > earlycon = NULL; Should we clear kgdboc_earlycon_io_ops.cons here when kgdb_register_io_module() failed? > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h > index c62d764..529116b 100644 > --- a/include/linux/kgdb.h > +++ b/include/linux/kgdb.h > @@ -276,8 +276,7 @@ struct kgdb_arch { > * the I/O driver. > * @post_exception: Pointer to a function that will do any cleanup work > * for the I/O driver. > - * @is_console: 1 if the end device is a console 0 if the I/O device is > - * not a console > + * @cons: valid if the I/O device is a console; else NULL. > */ > struct kgdb_io { > const char *name; > @@ -288,7 +287,7 @@ struct kgdb_io { > void (*deinit) (void); > void (*pre_exception) (void); > void (*post_exception) (void); > - int is_console; > + struct console *cons; Nit: I would call it "con". The trailing 's' makes me feel that that the variable points to an array or list of consoles. > }; > Otherwise, it looks pretty straightforward. Best Regards, Petr