Re: [PATCH] mm/shmem: fix uninitialized scalar variable

[Zi Yan <ziy@nvidia.com>]

On 1 Mar 2025, at 11:57, Ethan Carter Edwards wrote:

> int entry_order has the possibility of being uninitialized when
> returning. Initializing it to zero at declaration appeases coverity and
> reduces risk of returning nonsense.

How come?

After entry_order is declared, for (;;) begins. The first branch
is "if (!xa_is_value(old) || swp_to_radix_entry(swap) != old)", in
the then case, xas_set_err(&xas, -EEXIST), which makes
"if (!xas_nomem(&xas, gfp))" at the end of the for loop to break.
Then "if (xas_error(&xas))" will return -EEXIST. If the first then branch
is not taken, entry_order is assigned to xas_get_order(&xas).

Which code path would make entry_order uninitialized?

Thanks.

>
> Closes: https://scan7.scan.coverity.com/#/project-view/53698/11354?selectedIssue=1637878
> Fixes: 6dbc440b79b6 ("mm/shmem: use xas_try_split() in shmem_split_large_entry()")
> Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
> ---
>  mm/shmem.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index d19d33e98320d5e0ccbc86616bb3ea30d29f0cc1..3718c71aba9304dd3ca8df137a19e0564b8aadb2 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -2153,7 +2153,8 @@ static int shmem_split_large_entry(struct inode *inode, pgoff_t index,
>  {
>  	struct address_space *mapping = inode->i_mapping;
>  	XA_STATE_ORDER(xas, &mapping->i_pages, index, 0);
> -	int split_order = 0, entry_order;
> +	int split_order = 0;
> +	int entry_order = 0;
>  	int i;
>
>  	/* Convert user data gfp flags to xarray node gfp flags */
>
> ---
> base-commit: c0eb65494e59d9834af7cbad983629e9017b25a1
> change-id: 20250301-entry_order_uninit-129251b1ac9f
>
> Best regards,
> -- 
> Ethan Carter Edwards <ethan@ethancedwards.com>

--
Best Regards,
Yan, Zi