linux-kernel - Re: lockdep splat ("possible circular locking dependency detected") with PL011 on 5.8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200811111713.GA7203@willie-the-truck>
Date:   Tue, 11 Aug 2020 12:17:13 +0100
From:   Will Deacon <will@...nel.org>
To:     peterz@...radead.org
Cc:     linux@...linux.org.uk, gregkh@...uxfoundation.org,
        andre.przywara@....com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: lockdep splat ("possible circular locking dependency detected")
 with PL011 on 5.8

On Tue, Aug 11, 2020 at 12:38:41PM +0200, peterz@...radead.org wrote:
> On Tue, Aug 11, 2020 at 11:13:13AM +0100, Will Deacon wrote:
> > Using magic-sysrq via a keyboard interrupt over the serial console results in
> > the following lockdep splat with the PL011 UART driver on v5.8. I can reproduce
> > the issue under QEMU with arm64 defconfig + PROVE_LOCKING.
> > 
> > Any chance somebody could take a look, please? It's a little annoying,
> > because it means when I uses magic-sysrq to increase the loglevel prior
> > to testing something else, lockdep gets disabled as a result.
> > 
> 
> Going by msm_serial, the thing to do is something like this:
> 
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 8efd7c2a34fe..1717790ece2b 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -308,8 +308,9 @@ static void pl011_write(unsigned int val, const struct uart_amba_port *uap,
>   */
>  static int pl011_fifo_to_tty(struct uart_amba_port *uap)
>  {
> -	u16 status;
>  	unsigned int ch, flag, fifotaken;
> +	int sysrq;
> +	u16 status;
>  
>  	for (fifotaken = 0; fifotaken != 256; fifotaken++) {
>  		status = pl011_read(uap, REG_FR);
> @@ -344,10 +345,12 @@ static int pl011_fifo_to_tty(struct uart_amba_port *uap)
>  				flag = TTY_FRAME;
>  		}
>  
> -		if (uart_handle_sysrq_char(&uap->port, ch & 255))
> -			continue;
> +		spin_unlock(&uap->port.lock);
> +		sysrq = uart_handle_sysrq_char(&uap->port, ch & 255);
> +		spin_lock(&uap->port.lock);
>  
> -		uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag);
> +		if (!sysrq)
> +			uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag);
>  	}
>  
>  	return fifotaken;

Cheers, that seems to do the trick:

Tested-by: Will Deacon <will@...nel.org>

but what I don't understand is why I haven't run into this before, and why
nobody else seems to be reporting it!

I'll try some older kernels to see if it ever worked.

Will