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 <et...@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 <et...@ethancedwards.com> -- Best Regards, Yan, Zi
