From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S966359AbcKKCYa (ORCPT <rfc822;w@1wt.eu>);
        Thu, 10 Nov 2016 21:24:30 -0500
Received: from mga05.intel.com ([192.55.52.43]:55883 "EHLO mga05.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S935237AbcKKCY3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 10 Nov 2016 21:24:29 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.31,620,1473145200"; 
   d="scan'208";a="29969547"
Subject: Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability
To: Thomas Gleixner <tglx@linutronix.de>
References: <1477976354-13291-1-git-send-email-baolu.lu@linux.intel.com>
 <1477976354-13291-2-git-send-email-baolu.lu@linux.intel.com>
 <alpine.DEB.2.20.1611091030171.3501@nanos> <5823CB63.7090603@linux.intel.com>
 <alpine.DEB.2.20.1611100946190.3501@nanos>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Mathias Nyman <mathias.nyman@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>, linux-usb@vger.kernel.org,
        x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>
From: Lu Baolu <baolu.lu@linux.intel.com>
Message-ID: <58252BDB.1020005@linux.intel.com>
Date: Fri, 11 Nov 2016 10:24:27 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1611100946190.3501@nanos>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi,

On 11/10/2016 04:56 PM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Lu Baolu wrote:
>> On 11/09/2016 05:37 PM, Thomas Gleixner wrote:
>>> On Tue, 1 Nov 2016, Lu Baolu wrote:
>>>> +static void early_xdbc_write(struct console *con, const char *str, u32 n)
>>>> +{
>>>> +	int chunk, ret;
>>>> +	static char buf[XDBC_MAX_PACKET];
>>>> +	int use_cr = 0;
>>>> +
>>>> +	if (!xdbc.xdbc_reg)
>>>> +		return;
>>>> +	memset(buf, 0, XDBC_MAX_PACKET);
>>> How is that dealing with reentrancy?
>>>
>>> early_printk() does not protect against it. Peter has a patch to prevent
>>> concurrent access from different cpus, but it cannot and will never prevent
>>> reentrancy on the same cpu (interrupt, nmi).
>> I can use a spinlock_irq to protect reentrancy of interrupt on the same
>> cpu. But I have no idea about the nmi one.
> spinlock wont work due to NMIs.

Yes, of course.

>
>> This seems to be a common issue for all early printk drivers.
> No. The other early printk drivers like serial do not have that problem as
> they simply do:
>
>    while (*buf) {
>       while (inb(UART) & TX_BUSY)
>    	 cpu_relax();
>       outb(*buf++, UART);
>    }
>
> The wait for the UART to become ready is independent of the context as it
> solely depends on the hardware.
>
> As a result you can see the output from irq/nmi intermingled with the one
> from thread context, but that's the only problem they have.

Yes, you are right.

>
> The only thing you can do to make this work is to prevent printing in NMI
> context:
>
> write()
> {
> 	if (in_nmi())
> 		return;
> 	
> 	raw_spinlock_irqsave(&lock, flags);
> 	....
>
> That fully serializes the writes and just ignores NMI context printks. Not
> optimal, but I fear that's all you can do.

Yes. But I want to add a bit more.

write()
{
	if (in_nmi() && raw_spin_is_locked(&lock)) {
		trace("... ...");
		return;
	}

	raw_spinlock_irqsave(&lock, flags);
	....


Best regards,
Lu Baolu