Re: [PATCH tty v6 2/2] serial: 8250: Revert "drop lockdep annotation from serial8250_clear_IER()"

[John Ogness <john.ogness@linutronix.de>]

On 2026-07-20, Sashiko wrote:
>> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
>> index 3e623b71dadbc..ca736b1bd0726 100644
>> --- a/drivers/tty/serial/8250/8250_port.c
>> +++ b/drivers/tty/serial/8250/8250_port.c
>> @@ -719,6 +719,9 @@ static void __serial8250_clear_IER(struct uart_8250_port *up)
>>  
>>  static inline void serial8250_clear_IER(struct uart_8250_port *up)
>>  {
>> +	/* Port locked to synchronize UART_IER access against the console */
>> +	lockdep_assert_held_once(&up->port.lock);
>> +
>>  	__serial8250_clear_IER(up);
>>  }
>
> Will restoring this lockdep assertion cause a false-positive warning
> during KGDB polling?
>
> Looking at serial8250_put_poll_char(), it explicitly avoids taking the
> port lock because CPUs are quiesced during KDB/KGDB use:
>
>     /*
>      * Normally the port is locked to synchronize UART_IER access
>      * against the console. However, this function is only used by
>      * KDB/KGDB, where it may not be possible to acquire the port
>      * lock because all other CPUs are quiesced. The quiescence
>      * should allow safe lockless usage here.
>      */
>
> However, it then calls serial8250_clear_IER():
>
>     ier = serial_port_in(port, UART_IER);
>     serial8250_clear_IER(up);
>
> Should serial8250_put_poll_char() be updated to use
> __serial8250_clear_IER() instead to avoid triggering this lockdep
> splat?

Sashiko is correct. For v7 this will be changed to call
__serial8250_clear_IER().

John