Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1996349ybg; Fri, 5 Jun 2020 02:56:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxnDHrwuh9v0uLe0Ue/AWBS6SJlgEkd13zOyBQv/YN+SnKDpKpKQd7U4Z+qA8DCUcsv/bFs X-Received: by 2002:a17:906:2dc7:: with SMTP id h7mr763024eji.15.1591351007037; Fri, 05 Jun 2020 02:56:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591351007; cv=none; d=google.com; s=arc-20160816; b=Zv9alz+mODjLYJXhZyqi6n59hT4pWpKscLCaPOL0zNGk1RDqmnHgjmwz0kBxZR8iXz M5i8wwmYRso41wcZdoXABnXgyQzom2S6+qxq2OXaJP4n+/nEWT3zdRwAPWSw2oHqbHtt nEGI6XtaCP/yW2r9p5aDxN4+2q1fFav8oX9VV1ptdHo50D92fFbUOwmFmyDskHzjQxOd 43fwmNaKURiDl5fZKTthudq8+ukzX/F3zz9cnYJS8oSGP36kQiBxsxho80QHaeHZp7Ns UPuYd3Pg2pn6u5pBGD8VhRtaIt4RiURFxBFUTPpefkXuH588tkqan8SDeFjx/GeBek9X gh4w== 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=jUJkC/SuRr838AEeaw5WbV9wUNr+Qv/thQfLDRdjjfs=; b=UdKKrDTUMNtr4nutNt/h+cwe9LNaAva07Y/Er0uNCG/Iib50P1a34GcO0RVyJWtM31 hVvXqnNuWmvC/jJo3IWbCewpwfoUVFCUMc/tEEpml7xBPjoT0UoPA12S+idyIDVv+A5R 3SNwiGYIIi1ZJL+5A6NYVUCDcGdYtUnSacRuHS4cg64xXuQwuqUL9dMAAIqx4W/zWEnG BGhM8DyMjoPt3odFmznEFOQZFF8ZM3mbZgnPJ09JEsSLiI4rLl2VJb3/lT0QpB16RU6W sOC777kzQzK1Sv6FMQ9h27a9YJ0HUt2XQqbs2TxapY8tEAk17Q08BFxL1jWuRl+hyv9X Thgw== 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 27si4371837eja.567.2020.06.05.02.56.24; Fri, 05 Jun 2020 02:56:47 -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 S1726302AbgFEJx7 (ORCPT + 99 others); Fri, 5 Jun 2020 05:53:59 -0400 Received: from mx2.suse.de ([195.135.220.15]:58760 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726270AbgFEJx7 (ORCPT ); Fri, 5 Jun 2020 05:53:59 -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 34AA6ACCC; Fri, 5 Jun 2020 09:54:01 +0000 (UTC) Date: Fri, 5 Jun 2020 11:53:56 +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 v6 4/4] kdb: Switch to use safer dbg_io_ops over console APIs Message-ID: <20200605095356.GK22497@linux-b0ei> References: <1591264879-25920-1-git-send-email-sumit.garg@linaro.org> <1591264879-25920-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: <1591264879-25920-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 Thu 2020-06-04 15:31:19, 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. > > Suggested-by: Daniel Thompson > Signed-off-by: Sumit Garg Looks good to me now: Reviewed-by: Petr Mladek Best Regards, Petr