Coverity scan reported CID 1575482: error handling issues; this patch
addresses this by adding error handling to u_boot_env_add_cells.
Signed-off-by: Nick Spooner <[email protected]>
---
v2:
Fix whitespace issues in previous version
drivers/nvmem/u-boot-env.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index befbab156cda..c15de5f7fd99 100644
--- a/drivers/nvmem/u-boot-env.c
+++ b/drivers/nvmem/u-boot-env.c
@@ -95,6 +95,7 @@ static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
struct device *dev = priv->dev;
char *data = buf + data_offset;
char *var, *value, *eq;
+ int rval;
for (var = data;
var < data + data_len && *var;
@@ -119,7 +120,9 @@ static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
info.read_post_process = u_boot_env_read_post_process_ethaddr;
}
- nvmem_add_one_cell(nvmem, &info);
+ rval = nvmem_add_one_cell(nvmem, &info);
+ if (rval)
+ return rval;
}
return 0;
--
2.34.1
Hi Rafał,
> I'd appreciate description why do we need this change other than
> addressing some Coverity report.
I've been looking at Coverity for bugs to fix when it was brought up on
the kernel-janitors mailing list as a way to gain experience with the
kernel tree. This issue stood out to me specifically because all other
instances of nvmem_add_one_cell (in core.c, onie-tlv.c, and sl28vpd.c) are
checked for errors. I figured I'd add a check for the one in u-boot-env.c
so that they're all covered, but I understand if this is a case where we
don't want to try to fix something that isn't necessarily broken.
> Should a single nvmem_add_one_cell() failure result in not registering
> NVMEM device at all? Why?
I see that the only place where the return value of u_boot_env_add_cells
gets checked is in the same file on line 192, where u_boot_env_parse sets
err. The only time err won't be 0 is if info.name causes u_boot_env_add_cells
to return -ENOMEM. So is that the only case where err should be set, or
should err report if any cells failed to register? I followed the logic
backwards and found that .probe is set to whatever u_boot_env_probe return,
so I'm guessing it's a matter of what .probe should include or not. Let me
know if my logic is incorrect anywhere.
Thanks,
Nick Spooner
On 30.01.2024 20:42, Nick Spooner wrote:
> Coverity scan reported CID 1575482: error handling issues; this patch
> addresses this by adding error handling to u_boot_env_add_cells.
I'd appreciate description why do we need this change other than
addressing some Coverity report.
Should a single nvmem_add_one_cell() failure result in not registering
NVMEM device at all? Why?
> Signed-off-by: Nick Spooner <[email protected]>
> ---
> v2:
> Fix whitespace issues in previous version
>
> drivers/nvmem/u-boot-env.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
> index befbab156cda..c15de5f7fd99 100644
> --- a/drivers/nvmem/u-boot-env.c
> +++ b/drivers/nvmem/u-boot-env.c
> @@ -95,6 +95,7 @@ static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
> struct device *dev = priv->dev;
> char *data = buf + data_offset;
> char *var, *value, *eq;
> + int rval;
>
> for (var = data;
> var < data + data_len && *var;
> @@ -119,7 +120,9 @@ static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
> info.read_post_process = u_boot_env_read_post_process_ethaddr;
> }
>
> - nvmem_add_one_cell(nvmem, &info);
> + rval = nvmem_add_one_cell(nvmem, &info);
> + if (rval)
> + return rval;
> }
>
> return 0;
> --
> 2.34.1