Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp433832ybg; Wed, 3 Jun 2020 04:45:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznGhXFgwpOtjpDy6V0wBnTPRtNSJyheZ+qyTAOc/fGWwRs/1wfGAYOq5/c8ygEib91LpnE X-Received: by 2002:aa7:cb94:: with SMTP id r20mr31447947edt.215.1591184727299; Wed, 03 Jun 2020 04:45:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591184727; cv=none; d=google.com; s=arc-20160816; b=g7QNUDN/Gz/FnUkh5ParnS/tnOXKdcqohvI8/RWuL0lJheRDmLK329IKDc25V4znKz 52tKUNMN+M6JNYOxeKSW928ZTiO9bJOK21YqGuY7FV+oo/BK3Hm5Vf+tIcWGcYNaQl7g ZwQ92w6ZlafvDZEMsLsPVW9JyWv9sR1t3RwFZKAK0lym87ijVuRtKK7unscKBVonoBxs Ryn4PP+KFOHgG8SoUdmWr63eGazOg7hWVLgaSz+snqhexyjORNSLFQDGdFR2Kn2sZeAv jEMTJhUrH5g5Xq4rhwHdpShCaJhv7PLHfFtbiDGUMDlpJ9Ipl31kiscApZrk0Wv9xu5x 5Jlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=L3uwm8GKhOaqpoZ0YGgbFzd1wKVWSSHIAlOR+KHduXk=; b=ld5firqZh/CwEdue51AIiQwrZUFzHOfOT+mVWug/ZrPO6iOQpOvs6sqAmDrBmoYYw3 KZyGGqfm7yqwE4YXGSHa13zB/0Q/otGY4gQQit9KO84ttIqtLaMWRmF5I/lgk+LSLRJT 8jpr5ojxKqtDcqYUX5B/NG/1cIUQPYn78tJZFgYAh4JkGEZpI9iH37k7ed5LPxuW24n5 HTWWtSKrdcBy8xFJMBjtIgtOogs5C2NTaYwPmF9XwcLflX3TVcIJQ8TcxDd7BWZqHFSu wxxoiKiYlWQqMndw9mykznowCfHktObxQSXCnx308i4pQqlWB0cIjWCdjoRAwuEi0M2Z irrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=qHwY0sL6; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dr16si1258422ejc.320.2020.06.03.04.45.03; Wed, 03 Jun 2020 04:45:27 -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; dkim=pass header.i=@linaro.org header.s=google header.b=qHwY0sL6; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726316AbgFCLmx (ORCPT + 99 others); Wed, 3 Jun 2020 07:42:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726184AbgFCLmr (ORCPT ); Wed, 3 Jun 2020 07:42:47 -0400 Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B2493C08C5C4 for ; Wed, 3 Jun 2020 04:42:46 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id j10so1996155wrw.8 for ; Wed, 03 Jun 2020 04:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=L3uwm8GKhOaqpoZ0YGgbFzd1wKVWSSHIAlOR+KHduXk=; b=qHwY0sL6MjgOfAS8/Jg15PLIDIl+0xDJXebfzbSeGl77uFAAkGwTrhJGvtoEV8yCFQ uQqYKe/hGqiHMVUhvdCS3WbLDa0ruXpuTd5G1VDg2QXRE4RbDOPBSAP/znisL0NU4zVa BpCMGAzPFeBcOdesoja9rolr5FvYCsuXbks6gt7Vif890nJvHG8zyqo78y4/Ohp6c5ye d8uM42cunpL2/No9RMeiKejypbM/ZnJh1svSxrMypFsb+9OrscztyeEl5mDS1o0BOnL7 9XZz3UDbVkN1FJBYJuTs0JweChbdtwClFLsWZbOrQlE92+n3nnT5ZCsYTALnBez9RcUl oJww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=L3uwm8GKhOaqpoZ0YGgbFzd1wKVWSSHIAlOR+KHduXk=; b=muOzciUBlCTBRrweUDATTBHjxbJ7FRSrL/M8+YVCNUVDmxInjWy4ZxylS+hQJPoCqi H1ESpiMVUJxATsi+uHHJw5J1JFKnMrCs3IciHZd5WvUnsO7wnueo2uoos+mpkSu1MY7v Dg9im4ov/ATHQSsI6WkK7DL1hbj0XVIRuK54WGwVZZ4HfhVSB9WHTEu8eZv5nThQI1Rw Z1vP7SJ5xMknIIQpK3OPYTEqTHZC9TFKuhncvqShAL8OotzDwQ7jCyYnaew9u/RZuYLd aou0sk8Ir5H0rEZ6Nkso12zA763ZsQ+CWqg/0JH9mFUH0ng17sM5vKaLb22KvmnfssNQ r8mg== X-Gm-Message-State: AOAM533Y16sK9fuPy5+5mPrLEn6LVDku2mty64t225VHfz+c/gaUqP4R JII49r6Pfx7f0FboRpw8mvnXGg== X-Received: by 2002:a05:6000:1192:: with SMTP id g18mr32264160wrx.326.1591184565225; Wed, 03 Jun 2020 04:42:45 -0700 (PDT) Received: from holly.lan (cpc141214-aztw34-2-0-cust773.18-1.cable.virginm.net. [86.9.19.6]) by smtp.gmail.com with ESMTPSA id c206sm2137559wmf.36.2020.06.03.04.42.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 04:42:44 -0700 (PDT) Date: Wed, 3 Jun 2020 12:42:42 +0100 From: Daniel Thompson To: Sumit Garg Cc: Petr Mladek , kgdb-bugreport@lists.sourceforge.net, Jason Wessel , Douglas Anderson , Sergey Senozhatsky , Greg Kroah-Hartman , Jiri Slaby , Linux Kernel Mailing List Subject: Re: [PATCH v5 4/4] kdb: Switch to use safer dbg_io_ops over console APIs Message-ID: <20200603114242.khv5yi5yweq3e2jz@holly.lan> References: <1591168935-6382-1-git-send-email-sumit.garg@linaro.org> <1591168935-6382-5-git-send-email-sumit.garg@linaro.org> <20200603082503.GD14855@linux-b0ei> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 03, 2020 at 03:02:02PM +0530, Sumit Garg wrote: > On Wed, 3 Jun 2020 at 13:55, Petr Mladek wrote: > > > > 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? > > > > AFAIK, kgdboc_earlycon_io_ops won't be used at any later stage in case > registration fails. So IMO, it would be a redundant assignment unless > I missed something. Or, putting it another way, earlycon is a redundant (albeit better maintained) copy of kgdboc_earlycon_io_ops.cons. So I think the best thing to do is entirely replace earlycon with kgdboc_earlycon_io_ops.cons and then properly set it to NULL! Daniel.