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;
Date:   Wed, 6 Oct 2021 10:10:24 +0200
From:   Johan Hovold <johan@kernel.org>
To:     Fabio Estevam <festevam@denx.de>
Cc:     gregkh@linuxfoundation.org, michael@walle.cc,
        linux-serial@vger.kernel.org, marex@denx.de,
        u.kleine-koenig@pengutronix.de, Tejun Heo <tj@kernel.org>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        John Ogness <john.ogness@linutronix.de>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3]  serial: imx: Suppress false positive sysrq lockdep
 warning
Message-ID: <YV1Z8JslFiBSFGJF@hovoldconsulting.com>
References: <20211001101815.729648-1-festevam@denx.de>
 <YVcTluYb6XOiOXZn@hovoldconsulting.com>
 <0bbe2832eb2dc3a7c32f3d484ab42208@denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0bbe2832eb2dc3a7c32f3d484ab42208@denx.de>
Precedence: bulk

On Fri, Oct 01, 2021 at 11:15:33PM -0300, Fabio Estevam wrote:
> On 01/10/2021 10:56, Johan Hovold wrote:
> 
> > No, no, no.
> > 
> > Just replace this unlock with uart_unlock_and_check_sysrq() and do the
> > corresponding change in imx_uart_int(). The result is an even smaller
> > diff than what you're currently proposing and without any performance
> > penalty from dropping and reacquiring the lock.
> 
> Just to be clear, this is something that I have also tried:
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 8b121cd869e9..b652908f0bf1 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -803,7 +803,7 @@ static irqreturn_t __imx_uart_rxint(int irq, void 
> *dev_id)
>   				continue;
>   		}
> 
> -		if (uart_handle_sysrq_char(&sport->port, (unsigned char)rx))
> +		if (uart_prepare_sysrq_char(&sport->port, (unsigned char)rx))
>   			continue;
> 
>   		if (unlikely(rx & URXD_ERR)) {
> @@ -858,7 +858,7 @@ static irqreturn_t imx_uart_rxint(int irq, void 
> *dev_id)
> 
>   	ret = __imx_uart_rxint(irq, dev_id);
> 
> -	spin_unlock(&sport->port.lock);
> +	uart_unlock_and_check_sysrq(&sport->port);
> 
>   	return ret;
>   }
> @@ -991,7 +991,7 @@ static irqreturn_t imx_uart_int(int irq, void 
> *dev_id)
>   		ret = IRQ_HANDLED;
>   	}
> 
> -	spin_unlock(&sport->port.lock);
> +	uart_unlock_and_check_sysrq(&sport->port);
> 
>   	return ret;
>   }

> , but still get the lockdep warning in this case.

Ok, thanks for testing. The above is what I meant and it does fix the
false-positive lockdep splat which motivated
uart_unlock_and_check_sysrq() to be added in the first place.

Looking closer at the splat you reported (which you've edited quite
heavily), it becomes apparent that you are now hitting a different
locking issue. And it's not a false positive this time.

There a problem with the workqueue debugging code, which unless fixed at
the source, would prevent any console driver from queueing work while
holding a lock also taken in their write paths. And
tty_flip_buffer_push() is just one example of many.

I can easily reproduce the splat with another serial driver, and I've
also been able to trigger the actual deadlock.

I've prepared a patch that takes care of the workqueue state dumping,
which I'll send as a reply to this mail. Would you mind giving it a spin
with the imx driver as well?

Note that you may hit the other, false-positive, lockdep splat when
running with the workqueue fix, but the above diff should then address
that.

Johan