Re: [PATCH] nvmet: fix the CSTS state iteration in debugfs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] nvmet: data race in nvmet_ctrl_kato_show() [1]
--

commit 7730565aae4019e36ef00daab9fa6f3d654b6597
Author: Shao Mingyin <shao.mingyin@zte.com.cn>

nvmet: fix the CSTS state iteration in debugfs

This commit fixes nvmet_ctrl_state_show() to iterate over the 32 bits of
csts instead of the size of csts_state_names[], checking array bounds and
printing unknown bits as unsigned values.

> diff --git a/drivers/nvme/target/debugfs.c b/drivers/nvme/target/debugfs.c
> index e85fe1d4c9f8d..905a08c63669e 100644
> --- a/drivers/nvme/target/debugfs.c
> +++ b/drivers/nvme/target/debugfs.c
> @@ -78,18 +78,19 @@ static int nvmet_ctrl_state_show(struct seq_file *m, void *p)
>  	bool sep = false;
>  	int i;
>  
> -	for (i = 0; i < ARRAY_SIZE(csts_state_names); i++) {
> -		int state = BIT(i);
> +	for (i = 0; i < BITS_PER_TYPE(u32); i++) {
> +		u32 state = BIT(i);
>  
>  		if (!(ctrl->csts & state))
>  			continue;

[Severity: Medium]
This problem wasn't introduced by this patch, but can reading ctrl->csts
across loop iterations in nvmet_ctrl_state_show() (as well as ctrl->kato
in nvmet_ctrl_kato_show()) without synchronization or READ_ONCE() cause a
data race [1] when administrative commands or state transitions
concurrently update the controller state, resulting in inconsistent or
torn debugfs output?

[1] https://sashiko.dev/#/bug/linux-2b037cd9-c44c-44de-95f8-41de5f514a0b

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261115012806699yIujDZo6TywlxuhhSIktO@zte.com.cn?part=1