Re: [PATCH] serial: xilinx_uartps: publish console_port with release semantics

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] serial: xilinx_uartps: mixed plain and atomic accesses to console_port
--

commit 6429f77a5af6cf9c0baafae636fbc28eb10cbf3c
Author: Jaidev Shastri <jaidevshastri@vt.edu>
serial: xilinx_uartps: publish console_port with release semantics

cdns_uart_probe() assigns the first probed port to console_port with a plain
store once the port is set up, while cdns_uart_console_write() and
cdns_uart_console_setup() read it with plain loads. This commit stores it
with smp_store_release() and reads it with smp_load_acquire() to address
memory consistency issues.

> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
> index a072b75dbaf23..59e0d388d7c38 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c

[ ... ]

> @@ -1812,7 +1814,8 @@ static int cdns_uart_probe(struct platform_device *pdev)
>  	 */
>  	if (!console_port) {
        ^^^^

[Severity: Medium]
Does this plain read of console_port race with concurrent probes, violating the
patch's stated goal of using acquire/release semantics?

>  		cdns_uart_console.index = id;
> -		console_port = port;
> +		/* Pairs with the smp_load_acquire() in the console callbacks. */
> +		smp_store_release(&console_port, port);
>  	}

Are there other plain accesses to console_port that were left unfixed and could
cause regressions by breaking the strict release/acquire semantics intended by
this patch?

For example, further down in cdns_uart_probe():

	if (console_port == port &&
	    !console_is_registered(cdns_uart_uart_driver.cons)) {
		console_port = NULL;
		cdns_uart_console.index = -1;
	}

And in cdns_uart_remove():

	if (console_port == port)
		console_port = NULL;

Could these plain stores and reads race with smp_load_acquire() in the console
callbacks, violating the Linux Kernel Memory Model?

Mixing atomic barrier operations with plain C accesses can lead to data races
or compiler optimizations breaking strict memory ordering. This might happen
during concurrent asynchronous device probes or removals interacting with
console callbacks reading the global state.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921-mb-uartps-v1-1-9fc2f3d4b1a5@vt.edu?part=1